Да, вы можете изменить имя экземпляра RDS, но это крайне нежелательно делать в среде LIVE Production. Это изменит EndPoint, что может повлиять на другие ресурсы, активно обращающиеся к серверу RDS (например, сервер приложений).
Это, вероятно, потребует изменения свойства / env-variable в вашем коде или конфигах (в идеале это в конечном итоге приведет к выпуску config через управление конфигурацией)
Чтобы избежать сбоев (в будущем) и развертывания изменений с меньшим RTO, вы можете создать промежуточную запись DNS (CNAME) в Route53 для своего сервера RDS и использовать промежуточный URL-адрес в своем приложении. Когда имя сервера RDS изменится, вы можете просто изменить DNS CNAME новой конечной точки RDS. ПРИМЕЧАНИЕ. Во время смены имени ваш сервер RDS будет недоступен (со старым именем) в течение нескольких минут, и это может привести к сбою
Тем не менее, вы уже склонны к решению (изменение имен RDS) для вашей проблемы. Но
Есть несколько решений для вашей актуальной проблемы (управление серверами RDS для каждого проекта)
О. Старайтесь по возможности избегать использования консоли AWS. Почему бы вам не начать изучать интерфейс командной строки AWS (который может извлекать теги) и написать сценарий оболочки Python / Bash для отображения списка всех серверов RDS - с помощью имен проектов, из этого вывода вы можете управлять этими серверами, такими как создание снимка, резервное копирование и т. Д. Вы также можете использовать mysql --login-path (если вы используете mysql для администрирования БД)
https://opensourcedbms.com/dbms/passwordless-authentication-using-mysql_config_editor-with-mysql-5-6/ .
Б. (Независимый от затрат подход) Если вы все-таки решили изменить Имена RDS, то есть что-то, что вы можете сделать без какого-либо влияния.
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)
П р и м е ч а н и е - Все вышеперечисленные подходы не гарантируют целостность данных и неправильное обновление данных из-за транзакций в полете. Поэтому всегда лучше остановить все транзакции (остановив доступ всех приложений, развернув страницу обслуживания и выполнив операции)