Les bases de données peuvent échouer sans avertissement - soit à cause d'un plantage causé par un bogue logiciel, soit par les composants matériels sous-jacents. Le cloud apporte une autre dimension à la problématique, du fait de la nature éphémère des ressources de calcul et de stockage. Pour isoler notre infrastructure de base de données de ces défaillances, nous intégrons une redondance dans nos systèmes. Si une instance devient indisponible, un système de secours doit être en mesure de prendre la charge de travail et de continuer à partir de là. La réplication est une méthode bien connue et largement adoptée pour créer des copies redondantes d'une base de données principale.
Dans cet article, nous allons comparer la fonctionnalité de réplication dans les deux systèmes de base de données les plus populaires de la planète (selon db-engines) - Oracle et MySQL. Nous examinerons plus particulièrement la réplication logique Oracle 12c et MySQL 5.7. Les deux technologies offrent des systèmes de secours fiables pour décharger les charges de travail de production et aider en cas de sinistre. Nous examinerons leurs différentes architectures, analyserons les avantages et les inconvénients et passerons en revue les étapes de configuration de la réplication avec Oracle et MySQL.
Architecture Oracle Data Guard – Comment ça marche ?
Oracle Data Guard assure la haute disponibilité, la protection des données et la reprise après sinistre de vos données. C'est probablement le premier choix d'un DBA Oracle pour répliquer des données. La technologie a été introduite en 1990 (version 7.0) avec une application essentielle des journaux d'archivage sur les bases de données de secours. Data Guard a évolué au fil des ans et fournit désormais un ensemble complet de services qui créent, maintiennent, gèrent et surveillent des bases de données de secours.
Data Guard gère les bases de données de secours en tant que copies de la base de données de production. Si la base de données principale cesse de répondre, Data Guard peut basculer n'importe quelle base de secours vers le rôle de production, ce qui entraîne un temps d'arrêt. Data Guard peut être utilisé pour les techniques de sauvegarde, de restauration et de cluster afin de fournir un niveau élevé de protection et de disponibilité des données.
Data Guard est une technologie Ship Redo / Apply Redo, "redo" est l'information nécessaire pour récupérer les transactions. Une base de données de production appelée base de données primaire diffuse des redo vers une ou plusieurs répliques appelées bases de données de secours. Lorsqu'une insertion ou une mise à jour est effectuée dans une table, cette modification est capturée par le rédacteur de journal dans un journal d'archivage et répliquée sur le système de secours. Les bases de données de secours sont dans une phase continue de récupération, de vérification et d'application de rétablissement pour maintenir la synchronisation avec la base de données principale. Une base de données de secours se resynchronisera également automatiquement si elle est temporairement déconnectée de la base de données principale en raison de pannes de courant, de problèmes de réseau, etc.
Services Oracle Data Guard Net Les services de transport Data Guard Redo régulent la transmission de redo de la base de données principale à la base de données de secours. Le processus LGWR (enregistreur de journal) soumet les données redo à un ou plusieurs processus de serveur réseau (LNS1, LSN2, LSN3, ...LSNn). LNS lit à partir du tampon redo dans la SGA (Shared Global Area) et transmet redo à Oracle Net Services pour le transmettre à la base de données de secours. Vous pouvez choisir les attributs LGWR :synchrone (LogXptMode ='SYNC') ou mode asynchrone (LogXptMode ='ASYNC'). Avec une telle architecture, il est possible de livrer les données redo à plusieurs bases de données de secours ou de les utiliser avec Oracle RAC (Real Application Cluster). Le processus du serveur de fichiers distant (RFS) reçoit le fichier redo de LNS et l'écrit dans un fichier normal appelé fichier de journalisation de secours (SRL).
Il existe deux principaux types d'Oracle Data Guard. Physique avec redo apply et bases de données de secours logiques avec SQL apply.
Architecture de réplication logique Oracle Dataguard SQL Apply nécessite plus de traitement que redo s'applique, le processus lit d'abord le SRL et "exploite" le redo en le convertissant en enregistrements de modifications logiques, puis crée des transactions SQL avant d'appliquer le SQL à la base de données de secours. Il y a plus de pièces mobiles, donc cela nécessite plus de CPU, de mémoire et d'E/S, puis refaites l'application.
Le principal avantage de "SQL apply" est que la base de données est ouverte en lecture-écriture, tandis que le processus d'application est actif.
Vous pouvez même créer des vues et des index locaux. Cela le rend idéal pour les outils de reporting. La base de données de secours n'a pas besoin d'être une copie un à un de votre base de données principale, et peut donc ne pas être le meilleur candidat à des fins de DR.
Les principales fonctionnalités de cette solution sont :
- Une base de données de secours qui est ouverte en lecture-écriture pendant que l'application SQL est active
- Possibilité de verrou de modification des données maintenues par l'application SQL
- Capable d'exécuter des mises à jour progressives de la base de données
Il y a des inconvénients. Oracle utilise une journalisation supplémentaire de clé primaire ou de contrainte unique/d'index pour reconnaître logiquement une ligne modifiée dans la base de données de secours logique. Lorsque la journalisation supplémentaire de clé primaire et de contrainte/index unique à l'échelle de la base de données est activée, chaque instruction UPDATE écrit également les valeurs de colonne nécessaires dans le journal de rétablissement pour identifier de manière unique la ligne modifiée dans la base de données de secours logique. Oracle Data Guard prend en charge la réplication en chaîne, appelée ici "cascade", mais ce n'est pas typique en raison de la complexité de la configuration.
Oracle recommande d'ajouter une clé primaire ou un index unique non nul aux tables de la base de données primaire, dans la mesure du possible, pour garantir que SQL Apply peut appliquer efficacement les mises à jour de données redo à la base de données de secours logique. Cela signifie qu'il ne fonctionne sur aucune configuration, vous devrez peut-être modifier votre application.
Architecture du Golden Gate d'Oracle – Comment ça marche ?
Avec Data Guard, à mesure que des blocs sont modifiés dans la base de données, des enregistrements sont ajoutés au journal de rétablissement. Ensuite, en fonction du mode de réplication que vous exécutez, ces enregistrements de journal seront soit immédiatement copiés sur le serveur de secours, soit exploités pour les commandes SQL et appliqués. Golden Gate fonctionne différemment.
Golden Gate ne réplique les modifications qu'une fois la transaction validée. Par conséquent, si vous avez une transaction de longue durée, la réplication peut prendre un certain temps. Le "processus d'extraction" du Golden Gate conserve les modifications transactionnelles en mémoire.
Une autre grande différence est qu'Oracle Golden Gate permet l'échange et la manipulation de données au niveau des transactions entre plusieurs plates-formes hétérogènes. Vous n'êtes pas limité à la base de données Oracle. Il vous offre la possibilité d'extraire et de répliquer des enregistrements de données sélectionnés, des modifications transactionnelles et des modifications apportées au DDL (langage de définition de données) dans diverses topologies.
Architecture du Golden Gate d'Oracle Le flux Golden Gate typique montre que les données de base de données nouvelles et modifiées sont capturées à partir de la base de données source. Les données capturées sont écrites dans un fichier appelé le chemin source. Le suivi est ensuite lu par une pompe de données, envoyé sur le réseau et écrit dans un fichier de suivi distant par le processus Collector. La fonction de livraison lit le chemin distant et met à jour la base de données cible. Chacun des composants est géré par le processus Manager.
Réplication logique MySQL – Comment ça marche ?
La réplication dans MySQL existe depuis longtemps et a évolué au fil des ans. Il existe différentes manières d'activer la réplication MySQL, y compris la réplication de groupe, les clusters Galera, le "maître à esclave" asynchrone. Pour comparer l'architecture Oracle et MySQL, nous nous concentrerons sur les formats de réplication car c'est la base de tous les différents types de réplication.
Tout d'abord, les différents formats de réplication correspondent au format de journalisation binaire spécifié dans le fichier de configuration my.cnf. Quel que soit le format, les journaux sont toujours stockés de manière binaire, non visibles avec un éditeur standard. Il existe trois types de format :basé sur les lignes, basé sur les instructions et mixte. Mixte est la combinaison des deux premiers. Nous examinerons les instructions et les lignes.
Basé sur les déclarations - dans ce cas, ce sont les requêtes écrites. Toutes les instructions qui modifient les données (telles que les instructions INSERT DELETE, UPDATE et REPLACE) ne peuvent pas être répliquées à l'aide de la réplication basée sur les instructions. LOAD_FILE(), UUID(), UUID_SHORT(), USER(), FOUND_ROWS() etc ne seront pas répliqués.
Basé sur les lignes - dans ce cas, il s'agit de modifications apportées aux enregistrements. Toutes les modifications peuvent être répliquées. C'est la forme de réplication la plus sûre. Depuis 5.7.7, c'est l'option par défaut.
Voyons maintenant ce qui se passe sous le capot lorsque la réplication est activée.
Architecture de réplication MySQL Tout d'abord, la base de données master écrit les modifications dans un fichier appelé journal binaire ou binlog. L'écriture dans le journal binaire est généralement une activité légère car les écritures sont mises en mémoire tampon et séquentielles. Le fichier journal binaire stocke les données qu'un esclave de réplication traitera plus tard, l'activité du maître n'en dépend pas. Lorsque la réplication démarre, mysql déclenchera trois threads. Un sur le maître, deux sur l'esclave. Le maître a un thread, appelé thread de vidage, qui lit le journal binaire du maître et le transmet à l'esclave.
Sur l'esclave, un processus appelé thread IO se connecte au maître, lit les événements de journal binaire du maître au fur et à mesure qu'ils arrivent et les copie dans un fichier journal local appelé journal de relais. Le deuxième processus esclave - le thread SQL - lit les événements à partir d'un journal de relais stocké localement sur l'esclave de réplication, puis les utilise.
MySQL prend en charge la réplication en chaîne, qui est très facile à configurer. Les esclaves qui sont également des maîtres doivent s'exécuter avec les paramètres --log-bin et --log-slave-update.
Pour vérifier l'état de la réplication et obtenir des informations sur les threads, vous exécutez sur l'esclave :
MariaDB [(none)]> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: master
Master_User: rpl_user
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: binlog.000005
Read_Master_Log_Pos: 339
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 635
Relay_Master_Log_File: binlog.000005
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 339
Relay_Log_Space: 938
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: Current_Pos
Gtid_IO_Pos: 0-1-8
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: conservative
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
1 row in set (0.00 sec)Configuration de la réplication logique Data Guard dans Oracle
-
Créer une base de données de secours physique
Pour créer une base de données de secours logique, vous devez d'abord créer une base de données de secours physique, puis la faire passer à une base de données de secours logique.
-
Arrêter de refaire l'application sur la base de données de secours physique
L'arrêt de Redo Apply est nécessaire pour éviter d'appliquer les modifications.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; -
Préparer la base de données principale pour prendre en charge une base de données de secours logique
Modifiez l'attribut VALID_FOR dans le LOG_ARCHIVE_DEST_1 d'origine et ajoutez LOG_ARCHIVE_DEST_3 pour la base de données logique.
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/severalnines/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=severalnines' LOG_ARCHIVE_DEST_3= 'LOCATION=/arch2/severalnines/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=severalnines' LOG_ARCHIVE_DEST_STATE_3=ENABLECréer un dictionnaire dans les données de rétablissement
SQL> EXECUTE DBMS_LOGSTDBY.BUILD; -
Convertir en une base de données de secours logique
Pour continuer à appliquer les données de rétablissement à la base de données de secours physique jusqu'à ce qu'elle soit prête à être convertie en base de données de secours logique, émettez l'instruction SQL suivante :
SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY db_name; -
Ajuster les paramètres d'initialisation de la base de données de secours logique
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/severalnines_remote/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=severalnines_remote' LOG_ARCHIVE_DEST_2= 'SERVICE=severalnines ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=severalnines' LOG_ARCHIVE_DEST_3= 'LOCATION=/arch2/severalnines_remote/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=severalnines_remote' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE LOG_ARCHIVE_DEST_STATE_3=ENABLE -
Ouvrez la base de données de secours logique
SQL> ALTER DATABASE OPEN RESETLOGS;Vérifiez que la base de données de secours logique fonctionne correctement
vue v$data_guard_stats
SQL> COL NAME FORMAT A20 SQL> COL VALUE FORMAT A12 SQL> COL UNIT FORMAT A30 SQL> SELECT NAME, VALUE, UNIT FROM V$Data_Guard_STATS; NAME VALUE UNIT -------------------- ------------ ------------------------------ apply finish time +00 00:00:00 day(2) to second(1) interval apply lag +00 00:00:00 day(2) to second(0) interval transport lag +00 00:00:00 day(2) to second(0) intervalvue v$logstdby_process
SQL> COLUMN SERIAL# FORMAT 9999 SQL> COLUMN SID FORMAT 9999 SQL> SELECT SID, SERIAL#, SPID, TYPE, HIGH_SCN FROM V$LOGSTDBY_PROCESS; SID SERIAL# SPID TYPE HIGH_SCN ----- ------- ----------- ---------------- ---------- 48 6 11074 COORDINATOR 7178242899 56 56 10858 READER 7178243497 46 1 10860 BUILDER 7178242901 45 1 10862 PREPARER 7178243295 37 1 10864 ANALYZER 7178242900 36 1 10866 APPLIER 7178239467 35 3 10868 APPLIER 7178239463 34 7 10870 APPLIER 7178239461 33 1 10872 APPLIER 7178239472 9 rows selected.
Voici les étapes nécessaires pour créer une réplication logique Oracle Data Guard. Les actions seront légèrement différentes si vous effectuez cette opération avec un ensemble de compatibilité autre que par défaut ou des bases de données exécutées dans l'environnement Oracle RAC.
Configuration de la réplication MySQL
-
Configurez la base de données principale. Définissez un server_id unique, spécifiez différents journaux de réplication –log-basename (MariaDB) , activez le journal binaire. Modifiez le fichier my.cnf avec les informations ci-dessous.
log-bin server_id=1 log-basename=master1Connectez-vous à la base de données principale et autorisez l'utilisateur de réplication à accéder aux données principales.
GRANT REPLICATION SLAVE ON *.* TO replication_user -
Démarrez les deux serveurs avec les GTID activés.
gtid_mode=ON enforce-gtid-consistency=true -
Configurez l'esclave pour utiliser le positionnement automatique basé sur GTID.
mysql> CHANGE MASTER TO > MASTER_HOST = host, > MASTER_PORT = port, > MASTER_USER = replication_user, > MASTER_PASSWORD = password, > MASTER_AUTO_POSITION = 1; -
Si vous souhaitez ajouter un esclave au maître avec des données, vous devez effectuer une sauvegarde et la restaurer sur le serveur esclave.
mysqldump --all-databases --single-transaction --triggers --routines --host=127.0.0.1 --user=root --password=rootpassword > dump_replication.sqlConnectez-vous à la base de données esclave et exécutez :
slave> tee dump_replication_insert.log slave> source dump_replication.sql slave> CHANGE MASTER TO MASTER_HOST="host", MASTER_USER=" replication_user ", MASTER_PASSWORD="password ", MASTER_PORT=port, MASTER_AUTO_POSITION = 1;
