Puis-je renommer une instance RDS?

J'ai hérité d'une collection d'instances RDS MySQL avec des noms d' instances DB aléatoires (inutiles) .

Je dois souvent fouiller dans la section des balises pour savoir à quel projet ils appartiennent.

Un des paramètres que je peux modifier dans un RDS est le DB Instance Identifier.

Si je change cela, que se passera-t-il en plus pour le changement de nom? Cela affectera-t-il le code de quelqu'un? Ou s'agit-il d'un changement inoffensif?

Ce sont des systèmes vivants que je ne peux pas me permettre d'abattre.

Oui, vous pouvez renommer une instance RDS ... à vos risques et périls.

Lorsque vous renommez une instance de base de données, le point de terminaison [DNS] [nom d'hôte] de l'instance de base de données change, car l'URL inclut le nom que vous avez attribué à l'instance de base de données.

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

Votre code d'application nécessite que les modifications de configuration soient coordonnées, pour cette raison.

Voir le lien ci-dessus pour les autres implications. Il s'agit d'une opération prise en charge et généralement sûre, mais uniquement dans votre fenêtre de maintenance, car il y aura nécessairement une brève interruption lorsque le DNS sera modifié et votre code d'application sera recyclé avec le nouveau nom d'hôte de la base de données.

Oui, vous pouvez modifier le nom de l'instance RDS, mais il est fortement déconseillé de le faire dans l'environnement de production LIVE. Cela changerait l'EndPoint qui pourrait avoir un impact sur d'autres ressources accédant activement au serveur RDS (comme un serveur d'applications).

Cela nécessiterait probablement un changement de propriété / variable env dans votre code ou vos configurations (ce qui se retrouverait idéalement pour une version de configuration via la gestion des configurations)

Pour éviter les perturbations (à l'avenir) et les changements de déploiement avec un RTO moindre, vous pouvez créer une entrée DNS intermédiaire (CNAME) dans Route53 pour votre serveur RDS et utiliser l'URL intermédiaire dans votre application. Lorsque le nom du serveur RDS change, vous pouvez simplement modifier le DNS CNAME du nouveau point de terminaison RDS. REMARQUE: pendant le changement de nom, votre serveur RDS serait indisponible (avec l'ancien nom) pendant quelques minutes et cela pourrait provoquer une interruption

Cela étant dit, vous êtes déjà partisan d'une solution (changement de noms RDS) pour votre problème. Mais

Il existe plusieurs solutions à votre problème réel (gestion des serveurs RDS pour chaque projet)

A. Essayez d'éviter autant que possible d'utiliser AWS Console. Pourquoi ne commencez-vous pas à regarder AWS CLI (qui peut extraire les balises) et à écrire un script wrapper Python / Bash pour répertorier tous les serveurs RDS - avec les noms de projet, à partir de cette sortie, vous pouvez gérer ces serveurs, comme prendre un instantané, une sauvegarde, etc. . Vous pouvez également utiliser mysql --login-path (si vous êtes sur mysql pour l'administration DB) https://opensourcedbms.com/dbms/passwordless-authentication-using-mysql_config_editor-with-mysql-5-6/ .

B. (Approche indépendante des coûts) Si vous avez de toute façon décidé de changer les noms RDS, alors vous pouvez faire quelque chose sans aucun impact.

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)

REMARQUE Toutes les approches ci-dessus ne garantiraient pas l'intégrité des données et les mises à jour incorrectes des données en raison des transactions en vol. Il est donc toujours préférable d'arrêter toutes les transactions (en empêchant toutes les applications d'accéder et de déployer une page de maintenance et d'effectuer les opérations)