Bonjour,
Je dois migrer un serveur debian 7 (mysql 5) vers un nouveau serveur debian 10 (mariaDb 10) avec forte charge et trafic constant, les deux serveurs sont dans un vrack.
Je cherche une solution pour migrer en quelques minutes de downtime maximum.
Actuellement le dump de la base de données dure 40 minutes, le transfert environ 5 minutes et l'importation sur le nouveau serveur dure 25 minutes, ce qui fait un total de 1h10 d'arrêt, beaucoup trop long.
Je me demande quelle stratégie adopter pour la migration, ce doit être monnaie courante ici 
Peut-être activer dans un premier temps les deux bases en maitre/esclave ?
Hum, pas évident sans monter une usine à gaz qui risque de générer + de problèmes que d'apporter des solutions. Même de nuit c'est la même activité ?
Sinon faire un truc dans le genre :
- configurer les applis / sites pour utiliser l'ip du vrack pour accéder aux bdds.
- faire un transfert des datas puis déplacement IP FO sur le nouveau serveur.
- Là les données en bdd seront tjrs sur l'ancien serveur.
- Monter un master/slave mysql pour récupérer une copie à jour sur le nouveau serveur.
- Changer la config des applis / sites pour pointer en local et déclarer le serveur local comme master.
C'est probablement comme ça que je ferai.
Si trop compliqué de changer la config il faudrait faire comme ça :
- monter un master / slave pour avoir une copie à jour sur le nouveau serveur
- arrêter les services sur le serveur en prod, rsync des datas, déplacement IP FO, bascule du serveur sql sur le nouveau serveur en master.
ça éviterait une manip, mais ça implique de tt faire en même temps et j'aime pas tout faire en même temps
Ou sinon faire ça tranquillement de nuit pendant un week end avec la méthode classique du transfert de données.
Bonjour,
Hum, normalement c'est pas possible de mettre en place le système de master/slave si les BDD ne sont pas synchrone des deux côté, du coup cela ne va pas réduire le temps de transfert au finale vu que pour mettre le rôle de "slave" en place il faut transférer la BDD (et avoir aucun enregistrement lors de la configuration du master/slave) et après pour arrêter le rôle de "slave" il y aura de nouveau un down pour reconfigurer MariaDB (ou MySQL selon ce qu'il sera utilisé).
Le plus simple est de prévoir un créneau de migration, voir de passer la BDD en lecture seule (si le site arrive à fonctionne avec une BDD en lecture seule pour limiter le temps de transfère) ou de trouver une autre méthode de backup plus rapide (outils percona ?).
La BDD fait combien de Go ?
Cordialement, janus57
A 3h du mat c'est plus calme pour la france, un peu moins pour le canada, mais y'a toujours de l'activité aussi avec des API diverses, dont certaines ne doivent pas être en fail pendant plus d'une heure.
Le site ne fonctionne pas en read only.
La base fait 12Go en sql zippé.
J'imagine aussi faire un truc suivant : logger toutes les requêtes delete, insert et update avant le dump dans un modifs.sql, lancer le dump, transférer, importer la base.
Ensuite je stoppe tout. Je mets à jour la nouvelle base avec le fichier des modifs.sql qui devrait être léger, je bascule IP FO et je redémarre la bête.
Je risque de me payer de beaux doublons dans mon modifs.sql aussi…
Quoi que, si je remplace tous les INSERT INTO en REPLACE INTO, ça devrait passer.
Et pus je peux tester cette solution sans risque avant la migration…
Vous en pensez quoi ?
Reste la solution du cluster sql, là on peut ajouter un noeud qui va tt récupérer pour se mettre à jour… Mais il faut uniquement des tables innodb, et bonjour l'usine à gaz pour revenir en mode "normal" ensuite…
Clairement + ça avance + je me dis que la meilleure solution est la + simple (comme souvent) et qu'il vaut mieux prévoir un créneau de downtine en prévenant tt le monde que de se retrouver avec des tas de problèmes à gérer…
Merci à vous deux, ça me permet déjà d'oublier le master/slave qui effectivement risque de poser plus de problèmes qu'autre chose.
Bonjour,
Reste la solution du cluster sql, là on peut ajouter un noeud qui va tt récupérer pour se mettre à jour… Mais il faut uniquement des tables innodb, et bonjour l'usine à gaz pour revenir en mode "normal" ensuite…
oui et surtout il faut 3 nœuds en permanence avec une bonne latence et j'avais pensé à cette solution pour un projet (qui reçoit des données de manière régulière https://mariadb.com/kb/en/mariabackup/ minimum tte les 30secondes] des données de plusieurs milliers de capteurs aussi bien internes que externes) qui a une BDD de +/- 20Go (pour permettre un passage à Debian 10 car actuellement il est en Debian 9), et en faite c'est juste pas rentable en terme de temps et de risques (car si pour une raison X ou Y tu plante ton cluster c'est fini tu doit restaurer ton backup et tu perd plus de temps au finale que de faire une migration "classique").
A l'heure actuelle j'ai toujours pas de solution (Percona XtraBackup n'étant plus compatible MariaDB, et pas encore penché sur la solution "[Mariabackup" par manque de temps) pour migrer ce fameux projets qui vois sa BDD augmenter chaque jour, et je pense que je vais attendre la sortie de Debian 11 (et surtout il y a un manque de temps avec les confinements et les projets qui s'accumulent).
Par exemple dans ce cas précis un backup incrémental (Cf : https://mariadb.com/kb/en/incremental-backup-and-restore-with-mariabackup/) pourrais drastiquement réduire le temps de migration si on considère le fait qu'un premier import a été effectué sur le nouveau serveur pour la phase de tests de fonctionnement.
Cordialement, janus57
Par exemple dans ce cas précis un backup incrémental (Cf : https://mariadb.com/kb/en/incremental-backup-and-restore-with-mariabackup/) pourrais drastiquement réduire le temps de migration si on considère le fait qu'un premier import a été effectué sur le nouveau serveur pour la phase de tests de fonctionnement.
Intéressante cette doc merci :)
Et oui les clusters j'en ai géré un par le passé sur un site à très grosse activité.
Mais en cas de problème c'est un "bordel" à récupérer affreux...
De + quand on fait une mise à jour des données (insert/delete/update) cela doit être validé sur tous les noeuds avant la fin de la transaction... C'est vraiment indispensable d'avoir un très bon lien entre les serveurs !
J'imagine aussi faire un truc suivant : logger toutes les requêtes delete, insert et update avant le dump dans un modifs.sql, lancer le dump
J'ai testé cette solution dans le script qui lance le dump chaque nuit et ça semble fonctionner : avec l'option --single-transaction et l'enregistrement de toutes les requêtes qui démarre au moment du dump, le fichier dump + modifs.sql me donne une base à jour...
...seul souci, --single-transaction ne garantit pas des valeurs auto_increment correctes, je me suis retrouvé avec par exemple auto_increment=785210 dans le fichier dump, alors qu'il était à 785205 au lancement du dump. Les 5 enregistrements ajoutés durant le dump ne se retrouvent pas dans le fichier comme voulu, mais ont impacté tout de même l'auto_increment.
Je vais retester en exportant la structure dans un premier temps, et les données dans la foulée...
Bon, je valide ma méthode, elle fonctionne parfaitement.
Il faudra simplement arrêter le serveur web et cronjobs une minute pour transférer les dernières données qui arrivent totalement intègres.
Le downtime total ne devrait pas durer plus de 10 minutes, le plus long sera le basculement des IP FO.
Je vais étudier mariabackup par la suite, qui devrait éviter un long dump inutile chaque nuit si j'ai bien compris.