La migration de votre base de données vers un nouveau centre de données peut être un processus long et à haut risque. Une base de données contient un état et peut être beaucoup plus difficile à migrer par rapport aux serveurs Web, aux files d'attente ou aux serveurs de cache.
Dans cet article de blog, nous vous donnerons quelques conseils pour migrer vos données d'un fournisseur de services à un autre. Le processus est quelque peu similaire à notre article précédent sur la mise à niveau de MySQL, mais il existe quelques différences importantes.
Réplication MySQL ou cluster Galera ?
Passer à un autre fournisseur de services (par exemple, passer d'AWS à Rackspace ou de serveurs colocalisés au cloud) signifie très souvent que l'on construirait une toute nouvelle infrastructure en parallèle, la synchroniserait avec l'ancienne infrastructure, puis y basculerait. Pour les connecter et les synchroniser, vous pouvez tirer parti de la réplication MySQL.
Si vous utilisez Galera Cluster, il peut être plus facile de déplacer vos nœuds Galera vers un autre centre de données. Cependant, notez que l'ensemble du cluster doit toujours être traité comme une seule base de données. Cela signifie que votre site de production peut souffrir de la latence supplémentaire introduite lors de l'extension de Galera Cluster sur le WAN. Il est possible de minimiser l'impact en ajustant les paramètres réseau dans Galera et le système d'exploitation, mais l'impact ne peut pas être entièrement éliminé. Il est également possible de configurer à la place une réplication MySQL asynchrone entre l'ancien et le nouveau cluster, si l'impact sur la latence n'est pas acceptable.
Configuration d'une connectivité sécurisée
La réplication MySQL n'est pas chiffrée et n'est donc pas sûre à utiliser sur le WAN. Il existe de nombreuses façons de garantir que vos données seront transférées en toute sécurité. Vous devez rechercher s'il est possible d'établir une connexion VPN entre votre infrastructure actuelle et votre nouveau fournisseur de services. La plupart des fournisseurs (par exemple Rackspace et AWS) fournissent un tel service - vous pouvez connecter votre partie "nuageuse" à votre centre de données existant via un réseau privé virtuel.
Si, pour une raison quelconque, cette solution ne fonctionne pas pour vous (peut-être qu'elle nécessite du matériel auquel vous n'avez pas accès), vous pouvez utiliser un logiciel pour créer un VPN - l'un d'entre eux sera OpenVPN. Cet outil fonctionnera bien pour configurer des connexions cryptées entre vos centres de données.
Si OpenVPN n'est pas une option, il existe d'autres moyens de garantir que la réplication sera cryptée. Par exemple, vous pouvez utiliser SSH pour créer un tunnel entre les anciens et les nouveaux centres de données et transférer le port 3306 de l'esclave (ou maître) MySQL actuel vers le nouveau nœud. Cela peut être fait de manière très simple tant que vous disposez d'une connectivité SSH entre les hôtes :
$ ssh -L local_port:old_dc_host:mysql_port_in_old_dc [email protected]_dc_host -N &Par exemple :
$ ssh -L 3307:10.0.0.201:3306 [email protected] -N &Maintenant, vous pouvez vous connecter au serveur distant en utilisant 127.0.0.1:3307
$ mysql -P3307 -h 127.0.0.1Cela fonctionnera de la même manière pour la réplication, n'oubliez pas d'utiliser 127.0.0.1 pour le master_host et 3307 pour le master_port
Enfin, vous pouvez crypter votre réplication à l'aide de SSL. Ce billet de blog précédent explique comment cela peut être fait et quel type d'impact cela peut avoir sur les performances de réplication.
Si vous avez décidé d'utiliser la réplication Galera dans les deux centres de données, les suggestions ci-dessus s'appliquent également ici. En ce qui concerne SSL, nous avons précédemment expliqué comment chiffrer le trafic de réplication Galera. Pour une solution plus complète, vous pouvez chiffrer toutes les connexions à la base de données des applications clientes et de toute infrastructure de gestion/surveillance.
Mise en place de la nouvelle infrastructure
Une fois que vous avez la connectivité, vous devez commencer à construire la nouvelle infrastructure. Pour cela, vous utiliserez probablement xtrabackup ou mariabackup. Il peut être tentant de combiner la migration avec la mise à niveau de MySQL, après tout, vous configurez un tout nouvel environnement dans le nouvel emplacement. Nous ne recommanderions pas de le faire. La migration vers une nouvelle infrastructure est suffisamment importante en soi pour que la combiner avec un autre changement majeur augmente la complexité et les risques. C'est également vrai pour d'autres choses - vous voulez adopter une approche étape par étape des changements. Ce n'est qu'en changeant les choses une par une que vous pouvez comprendre les résultats des changements et leur impact sur votre charge de travail - si vous avez apporté plus d'un changement à un moment donné, vous ne pouvez pas être sûr de celui qui est responsable d'un (nouveau ) comportement que vous avez observé.
Lorsqu'une nouvelle instance MySQL est opérationnelle dans le nouveau centre de données, vous devez l'asservir au nœud de l'ancien centre de données - pour vous assurer que les données des deux centres de données resteront synchronisées. Cela deviendra utile lorsque vous vous préparerez pour la transition finale. C'est également un bon moyen de s'assurer que le nouvel environnement peut gérer votre charge d'écriture.
La prochaine étape consistera à construire une infrastructure de staging complète dans le nouvel emplacement et à effectuer des tests et des benchmarks. Il s'agit d'une étape très importante qui ne doit pas être ignorée - le problème ici est que vous, en tant que DBA, devez comprendre la capacité de votre infrastructure. Lorsque vous changez de fournisseur, les choses changent également. Les nouveaux matériels/vm sont plus rapides ou plus lents. Il y a plus ou moins de mémoire par instance. Vous devez comprendre à nouveau comment votre charge de travail s'adaptera au matériel que vous allez utiliser. Pour cela, vous utiliserez probablement Percona Playback ou pt-log-player pour rejouer certaines des requêtes réelles sur le système de mise en scène. Vous voudrez tester les performances et vous assurer qu'elles sont à un niveau acceptable pour vous. Vous souhaitez également effectuer tous les tests d'acceptation standard que vous exécutez sur vos nouvelles versions - juste pour confirmer que tout est opérationnel. En général, toutes les applications doivent être construites de manière à ne pas dépendre de la configuration matérielle et d'une configuration actuelle. Mais quelque chose a peut-être échappé et votre application peut dépendre de certains ajustements de configuration ou de solutions matérielles que vous n'avez pas dans le nouvel environnement.
Enfin, une fois que vous serez satisfait de vos tests, vous souhaiterez créer une infrastructure prête pour la production. Une fois cette opération effectuée, vous souhaiterez peut-être exécuter des tests en lecture seule pour la vérification finale. Ce serait la dernière étape avant le basculement.
Basculement
Une fois tous ces tests effectués et une fois que l'infrastructure a été jugée prête pour la production, la dernière étape consiste à basculer le trafic de l'ancienne infrastructure.
Globalement, il s'agit d'un processus complexe, mais lorsque nous examinons le niveau de la base de données, c'est plus ou moins la même chose qu'un basculement standard - quelque chose que vous avez peut-être fait plusieurs fois dans le passé. Nous l'avons couvert en détail dans un article précédent, en bref, les étapes sont :arrêter le trafic, s'assurer qu'il est arrêté, attendre que l'application soit déplacée vers le nouveau centre de données (les enregistrements DNS changent ou non), faire des tests de fumée pour s'assurer tout semble bon, allez vivre, surveillez de près pendant un certain temps.
Cette transition nécessitera un certain temps d'arrêt, comme nous pouvons le voir. Le problème est de s'assurer que nous avons un état cohérent sur l'ancien site et le nouveau. Si nous voulons le faire sans temps d'arrêt, nous aurions besoin de mettre en place une réplication maître-maître. La raison en est qu'au fur et à mesure que nous actualisons le DNS et passons des sessions de l'ancien site au nouveau, les deux systèmes seront utilisés en même temps - jusqu'à ce que toutes les sessions soient redirigées vers le nouveau site. En attendant, toute modification apportée au nouveau site doit être répercutée sur l'ancien site.
L'utilisation de Galera Cluster, comme décrit dans cet article de blog, peut également être un moyen de synchroniser les données entre les deux sites.
Nous sommes conscients qu'il s'agit d'une très brève description du processus de migration des données. J'espère que cela suffira à vous orienter dans la bonne direction et à vous aider à identifier les informations supplémentaires que vous devez rechercher.
