Ce que nous faisons · Données et web: Réplication de bases de données et réplicas hors site
Une copie de votre base de données de production, en lecture seule et mise à jour en continu, qui tourne sur un autre site, où les rapports peuvent s'exécuter sans toucher la production et où vous pouvez basculer si le site principal est un jour perdu. Construite pour que le réplica aille chercher les changements, et que la production n'ait jamais de chemin vers lui.
De quoi il s'agit
Une réplication asynchrone MySQL ou MariaDB, le réplica étant placé là où une panne différente ne peut pas l'atteindre : un autre datacenter, une autre baie de stockage, un autre chemin réseau. Le réplica suit le primaire quasiment en temps réel et remplit trois rôles à la fois :
- Une copie de disaster recovery des données, à jour à quelques secondes près.
- Une cible de reporting et d'intégration, pour que les lectures lourdes cessent de concurrencer vos clients.
- Une source propre pour les backups, pris sans verrouiller ni ralentir le primaire.
Comment nous le construisons
Le réplica tire. Les connexions de réplication sont ouvertes par le réplica, jamais dans l'autre sens. La production n'a aucun chemin réseau vers le côté réplica, et cela est appliqué sur les appliances firewall, pas par une règle d'hôte que quelqu'un peut désactiver. Si un serveur de production est un jour compromis, l'attaquant n'a aucune route vers la copie à partir de laquelle vous repartiriez.
Sur notre maillage privé. Les réplicas hors site transitent par notre backbone privé chiffré entre nos datacenters d'Athènes, d'Amsterdam et de Toronto, jamais en clair sur l'internet public.
Basé sur GTID. Nous utilisons des identifiants de transaction globaux, de sorte qu'un réplica peut être repointé, promu ou réensemencé sans que personne n'ait à chercher des coordonnées de binary log à trois heures du matin.
Surveillé sur l'état, pas sur le bruit. Un contrôle tourne toutes les cinq minutes et publie une seule alerte lorsque l'état change : retard au-delà du seuil, rupture, ou retour à la normale. Les ingénieurs reçoivent un signal sur lequel ils agissent, pas un flux qu'ils apprennent à ignorer.
Ce dont il vous protège
- Perdre un site entier et, avec lui, l'unique copie de vos données.
- Des requêtes de reporting et des intégrations qui ralentissent la base de données que vos clients utilisent.
- Un réplica arrêté en silence depuis des semaines, découvert le jour où vous en avez besoin.
- Un attaquant sur un serveur de production qui atteint la copie à partir de laquelle vous restaureriez.
- Des backups qui verrouillent des tables ou bloquent le primaire pendant leur exécution.
En pratique
La sortie de VMware d'un diffuseur. Lorsque nous avons reconstruit la plateforme web d'un diffuseur national sur notre private cloud OLVM, la base de données était le seul tier portant un état qui valait la peine d'être déplacé. Elle a voyagé par réplication GTID de l'ancienne plateforme vers la nouvelle, de sorte que la bascule (cutover) elle-même a été une promotion avec quelques secondes de delta. La bascule s'est achevée il y a des mois et la plateforme tourne chez nous depuis.
Des réplicas qui servent de nouvelles applications. Un réplica en lecture est aussi la façon la plus propre de poser une nouvelle interface de recherche, de reporting ou de portail sur un système existant : la nouvelle application lit à la vitesse du réseau local et ne touche jamais le primaire pendant le chargement des pages. Nous les construisons à l'initiative du réplica, de sorte que l'hôte qui porte le réplica n'a besoin d'aucune règle firewall entrante.
Pourquoi EuroVPS
- Les réplicas vivent sur un site réellement différent, relié par notre propre backbone chiffré.
- Pull uniquement, appliqué par le firewall : la production ne peut jamais atteindre le côté réplica.
- Alertes sur changement d'état toutes les cinq minutes, lues par des ingénieurs 24h/24.
- GTID partout, de sorte que promotion et réensemencement sont des procédures répétées.
- La même équipe construit le réplica, les backups et le plan de failover, pour qu'ils s'emboîtent.
Questions fréquentes
- Quel sera le retard du réplica ? En charge normale, quelques secondes ou moins. Nous alertons lorsque le retard dépasse un seuil convenu avec vous, et le RPO que vous obtenez suit le service que vous commandez.
- Pouvons-nous basculer sur le réplica ? Oui. La promotion est une procédure documentée. La vitesse à laquelle les applications suivent dépend de la conception du service, d'une promotion manuelle pour un service basique à un basculement automatisé et répété pour les services à couverture mondiale.
- Notre outil de reporting peut-il s'y connecter ? Oui, avec un compte en lecture seule. C'est l'une des principales raisons de l'avoir.
- Remplace-t-il les backups ? Non. Un réplica copie les erreurs aussi fidèlement que les données. Les backups sont pris à côté et tirés vers une infrastructure distincte.
- MySQL ou MariaDB ? Les deux. Nous alignons le moteur et les réglages du réplica sur ceux du primaire.
Vous voulez une copie de vos données qu'une mauvaise journée ne peut pas atteindre ? Parler à un ingénieur.
Votre prochain partenaire d'infrastructure
Examinons votre environnement.
Dites-nous ce que vous faites tourner aujourd'hui et ce qui doit s'améliorer. Un ingénieur examinera votre demande et vous aidera à planifier la suite.
+357 222 32280
Commençons par votre environnement.
Un peu de contexte nous aide à démarrer la bonne conversation.