Czy mogę zmienić nazwę instancji RDS?

Odziedziczyłem kolekcję instancji RDS MySQL z losowymi (bezużytecznymi) nazwami instancji DB .

Często muszę przekopać się do sekcji tagów, aby dowiedzieć się, do którego projektu należą.

Jednym z ustawień, które mogę modyfikować w RDS, jest DB Instance Identifier.

Jeśli to zmienię, co stanie się poza zmianą nazwy? Czy wpłynie to na czyjś kod? Czy jest to zmiana nieszkodliwa?

To są żywe systemy, których nie mogę sobie pozwolić na upadek.

Tak, możesz zmienić nazwę instancji RDS ... na własne ryzyko.

Po zmianie nazwy instancji DB, punkt końcowy [DNS] [nazwa hosta] dla instancji DB zmienia się, ponieważ adres URL zawiera nazwę przypisaną do instancji DB.

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_RenameInstance.html

Z tego powodu kod aplikacji wymaga koordynacji konfiguracji.

Zobacz powyższy link dla innych implikacji. Jest to obsługiwana i ogólnie bezpieczna operacja, ale tylko w oknie konserwacji, ponieważ koniecznie nastąpi krótkie zakłócenie, gdy DNS zostanie zmieniony, a kod aplikacji zostanie włączony z nową nazwą hosta bazy danych.

Tak, możesz zmienić nazwę instancji RDS, ale nie zaleca się tego w środowisku produkcyjnym LIVE. Zmieniłoby to EndPoint, co może wpłynąć na inne zasoby aktywnie uzyskujące dostęp do serwera RDS (np. Serwer aplikacji).

Prawdopodobnie wymagałoby to zmiany właściwości / env-zmiennej w kodzie lub konfiguracji (co idealnie skończyłoby się wydaniem konfiguracji przez zarządzanie konfiguracją)

Aby uniknąć zakłóceń (w przyszłości) i zmian związanych z wdrażaniem przy mniejszym RTO, możesz utworzyć pośredni wpis DNS (CNAME) w Route53 dla swojego serwera RDS i użyć pośredniego adresu URL w aplikacji. Gdy zmienia się nazwa serwera RDS, wystarczy zmienić nazwę DNS CNAME nowego punktu końcowego RDS. UWAGA: Podczas zmiany nazwy serwer RDS będzie niedostępny (pod starą nazwą) przez kilka minut, co może powodować zakłócenia

To powiedziawszy, jesteś już nastawiony na rozwiązanie (zmiana nazw RDS) swojego problemu. Ale

Istnieje wiele rozwiązań rzeczywistego problemu (zarządzanie serwerami RDS dla każdego projektu)

A. Staraj się unikać korzystania z Konsoli AWS w jak największym stopniu. Dlaczego nie zaczniesz przeglądać interfejsu AWS CLI (który może wyciągać tagi) i napisać wrapperowy skrypt Python / Bash, aby wyświetlić listę wszystkich serwerów RDS - dzięki nazwom projektów z tego wyjścia można zarządzać tymi serwerami, np. Zrobić migawkę, kopię zapasową itp. Można również użyć mysql --login-path (jeśli korzystasz z mysql do administracji DB) https://opensourcedbms.com/dbms/passwordless-authentication-using-mysql_config_editor-with-mysql-5-6/ .

B. (Podejście agnostyczne) Jeśli mimo wszystko zdecydowałeś się zmienić nazwy RDS, możesz coś zrobić bez żadnego wpływu.

B.1 When the next code/config release happens try to bring in the intermediate DNS change into action.

B.2 (Optional) Enable Multi AZ in RDS (HA and twice the price). This will help your application to access the secondary active slave when there is any disruption due to name change. There is an option called Reboot with failover which would reboot the master while failing over to the active secondary 

B.3 Enable replication (read-replica) (this will give you a new RDS end-point). Name the read replica properly with your project names

B.4. Once replication is complete (and during your SLA / maintenance window) promote your read replica (this will break replication) and make the intermediate DNS point to the new RDS (with your proper names)

UWAGA Wszystkie powyższe podejścia nie gwarantowałyby integralności danych i niewłaściwych aktualizacji danych z powodu transakcji w locie. Dlatego zawsze lepiej jest zatrzymać wszystkie transakcje (zatrzymując wszystkie aplikacje uzyskujące dostęp i wdrażając stronę konserwacji i wykonując operacje)