Mise à l'échelle d'une instance EC2 à deux lorsque votre application et votre base de données sont sur la même instance

Question

Si une instance EC2 héberge mon application Web et ma base de données MariaDB, je souhaite la redimensionner à un moment donné en séparant l'application Web et la base de données dans des instances distinctes, quelle est la pratique standard pour le faire sans encourir aucune temps d'arrêt? Cela me semble être un problème compliqué, mais tous les articles que j'ai vus sur les avantages de séparer le web et les données du lancement parlent essentiellement des avantages en termes de sécurité et ne semblent pas mettre en avant les avantages de l'évolutivité. Je pense que ce n'est pas un problème aussi complexe que cela puisse paraître.

De même, dans ce même scénario, si la mise à l'échelle et le maintien de l'application et de la base de données couplées étaient moins complexes, comment cela fonctionnerait-il? - en gardant à l'esprit l'exigence 0 temps d'arrêt.

Answer 1

Familiarisez-vous avec la manière dont la réplication fonctionne dans MariaDB et la solution devient intuitivement évidente.

Vous créez un serveur de base de données réplica en copiant la base de données existante sur un nouveau serveur en utilisant mysqldump avec une attention particulière aux options --master-data et --single-transaction pour effectuer une sauvegarde. Le chargement des résultats sur votre nouveau serveur de base de données crée une réplique de la base de données d'origine telle qu'elle existait au moment où vous avez commencé à effectuer la sauvegarde. InnoDB MVCC assure que la version de chaque ligne de chaque table, telle qu'elle existait au début de la sauvegarde, correspond à ce qui apparaît sur le nouveau serveur suite au chargement de cette sauvegarde. (Oui, vous devez utiliser InnoDB, comme vous le feriez de toute façon.)

Vous connectez ensuite la nouvelle base de données (en tant qu'esclave) à l'ancienne base de données (en tant que maître), en lui demandant de commencer à la répliquer à partir de cette même base point dans le temps - le point dans le temps identifié par les coordonnées du journal principal contenues dans la sauvegarde - l'heure à laquelle la sauvegarde a été démarrée.

Vous attendez que l'esclave soit synchronisé avec le maître.

Surveillance de l'état de la réplication à l'aide de SHOW MASTER STATUS; sur le maître et de SHOW SLAVE STATUS; sur l'esclave, il est trivial de déterminer si l'esclave est bien «courant» avec le maître. La réplication MariaDB est "asynchrone" dans le sens où les changements sur le maître sont effectués avant les changements sur l'esclave, mais avec un serveur esclave de capacité appropriée, le retard de réplication typique est de l'ordre ou millisecondes ... et, encore une fois, est facilement déterminé. Dans le temps nécessaire pour arrêter/démarrer votre application, il peut être confirmé que toutes les données persistantes ont fini de se répliquer. Rendre l'esclave accessible en écriture (généralement, un esclave est en mode lecture seule, la seule source de modifications étant le thread SQL de réplication, qui peut bien sûr toujours y écrire) ... puis surveiller la réplication pour vérifier la synchronisation , arrêtez l'application, pointez l'application sur la nouvelle base de données, vérifiez que la réplication est toujours synchronisée, démarrez l'application ... terminée. Maintenant, déconnectez l'esclave de la base de données master et abandonnez l'ancien maître. Bien sûr, une durée d'indisponibilité nulle est impossible, car l'application doit être reconfigurée pour se connecter à une base de données différente ... mais le temps d'arrêt total dépend essentiellement de la vitesse à laquelle vous pouvez taper ou automatiser les tâches nécessaires. étapes pour interroger les deux serveurs de base de données et comparer les coordonnées de réplication, et effectuer la transition. Au risque d'indiquer l'évidence, ne mettez jamais autre chose que la base de données sur le serveur de base de données, et ne la colocatez jamais avec l'application

Aucune exception dans la production ne devrait même être ouverte à la discussion.Un problème qui revient trop souvent, comme vu here, here, here, et here est le plus souvent imputable à des personnes qui ne tiennent pas compte de ce principe, exécutant l'application et sa base de données sur le même serveur. Les performances et la stabilité sont non seulement à risque, mais les symptômes qui en résultent donnent aussi l'impression (incorrecte) que MySQL (ou MariaDB ou Percona Server) est en faute, "crash", alors qu'en fait l'application est en faute, invitant le système d'exploitation pour forcer le crash de la base de données dans le but d'essayer de préserver la stabilité globale de la machine face à l'épuisement inévitable de la mémoire.

Answer 2

Une solution possible:

Mettez un équilibreur de charge devant votre instance EC2, intially simplement diriger le trafic vers l'instance unique que vous avez.

Spin une deuxième instance qui exécutera une copie de votre site Web, obtenir tous configurely et pointant à la DB sur la première instance, puis l'ajouter dans la équilibreur de charge de sorte qu'il commence à obtenir du trafic

Facultatif: ajoutez une troisième instance configurée de la même manière que la seconde, en exécutant également une copie du site Web uniquement. Sortez l'instance d'origine du pool LB afin que le trafic Web ne passe plus qu'aux no 2 et no 3.

Désinstallez le site Web de l'instance n ° 1, de sorte qu'il ne reste plus que le serveur db.