Présentation de la réplication croisée PostgreSQL et MySQL

Ce blog vise à expliquer un aperçu de la réplication croisée entre PostgreSQL et MySQL, et à discuter plus en détail des méthodes de configuration de la réplication croisée entre les deux serveurs de base de données. Traditionnellement, les bases de données impliquées dans une configuration de réplication croisée sont appelées bases de données hétérogènes, ce qui est une bonne approche pour passer d'un serveur RDBMS à un autre.

Les bases de données PostgreSQL et MySQL sont généralement des bases de données RDBMS, mais elles offrent également une capacité NoSQL avec des extensions supplémentaires pour avoir le meilleur des deux mondes. Cet article se concentre sur la discussion de la réplication entre PostgreSQL et MySQL du point de vue du SGBDR.

Une explication exhaustive sur les composants internes de la réplication n'est pas du ressort de ce blog, cependant, certains éléments fondamentaux seront discutés pour donner au public une compréhension de la façon dont la réplication est configurée entre les serveurs de base de données, les avantages, les limitations et peut-être certains cas d'utilisation connus. /P>

En général la réplication entre deux serveurs de base de données identiques est réalisée soit en mode binaire, soit en mode requête entre un nœud maître (autrement appelé éditeur, primaire ou actif) et un nœud esclave (abonné, de secours ou passif). Le but de la réplication est de fournir une copie en temps réel de la base de données maître du côté esclave, où les données sont transférées du maître à l'esclave, formant ainsi une configuration active-passive car la réplication n'est configurée que pour se produire dans un sens. D'autre part, la réplication entre deux bases de données peut être configurée dans les deux sens afin que les données puissent également être transférées de l'esclave vers le maître, établissant une configuration active-active. Tout cela peut être configuré entre deux ou plusieurs serveurs de base de données identiques qui peuvent également inclure une réplication en cascade. La configuration active-active ou active-passive dépend vraiment des besoins de l'entreprise, de la disponibilité de ces fonctionnalités dans la configuration native ou de l'utilisation de solutions externes pour configurer et des compromis applicables.

La configuration mentionnée ci-dessus peut être réalisée avec divers serveurs de base de données, un serveur de base de données pouvant être configuré pour accepter des données répliquées à partir d'un autre serveur de base de données complètement différent tout en conservant un instantané en temps réel des données en cours de réplication. Les serveurs de base de données MySQL et PostgreSQL offrent la plupart des configurations décrites ci-dessus, soit dans leur propre nativité, soit à l'aide d'extensions tierces, notamment la méthode de journal binaire, la méthode de bloc de disque, les méthodes basées sur les instructions et les lignes.

L'exigence de configurer une réplication croisée entre MySQL et PostgreSQL est vraiment le résultat d'un effort de migration unique pour passer d'un serveur de base de données à un autre. Comme les deux bases de données utilisent des protocoles différents, elles ne peuvent pas se parler directement. Afin de réaliser ce flux de communication, il existe un outil open source externe tel que pg_chameleon.

Contexte de pg_chameleon

pg_chameleon est un système de réplication MySQL vers PostgreSQL développé en Python 3. Il utilise une bibliothèque open source appelée mysql-replication qui est également développée en Python. La fonctionnalité consiste à extraire des images de lignes de tables MySQL et à les stocker en tant qu'objets JSONB dans une base de données PostgreSQL, qui est ensuite décodée par une fonction pl/pgsql et à relire ces modifications par rapport à la base de données PostgreSQL.

Caractéristiques de pg_chameleon

• Plusieurs schémas MySQL du même cluster peuvent être répliqués sur une seule base de données PostgreSQL cible, formant une configuration de réplication plusieurs vers un
• Les noms des schémas source et cible peuvent être différents
• Les données de réplication peuvent être extraites du réplica MySQL en cascade
• Les tables qui ne parviennent pas à se répliquer ou à générer des erreurs sont exclues
• Chaque fonctionnalité de réplication est gérée à l'aide de démons
• Contrôle à l'aide de paramètres et de fichiers de configuration basés sur la construction YAML

Démo

Pour commencer, préparez l'installation avec tous les prérequis nécessaires à l'installation de pg_chameleon. Dans cette démo, Python 3.6.8 est installé, créant un environnement virtuel et l'activant pour son utilisation.

$> wget https://www.python.org/ftp/python/3.6.8/Python-3.6.8.tar.xz
$> tar -xJf Python-3.6.8.tar.xz
$> cd Python-3.6.8
$> ./configure --enable-optimizations
$> make altinstall

Suite à une installation réussie de Python3.6, d'autres exigences supplémentaires sont remplies, telles que la création et l'activation d'un environnement virtuel. En plus de ce module pip mis à niveau vers la dernière version et il est utilisé pour installer pg_chameleon. Dans les commandes ci-dessous, pg_chameleon 2.0.9 a été volontairement installé alors que la dernière version est une 2.0.10. Ceci est fait afin d'éviter tout bogue nouvellement introduit dans la version mise à jour.

$> python3.6 -m venv venv
$> source venv/bin/activate
(venv) $> pip install pip --upgrade
(venv) $> pip install pg_chameleon==2.0.9

L'étape suivante consiste à invoquer pg_chameleon (chameleon est la commande) avec l'argument set_configuration_files pour permettre à pg_chameleon de créer des répertoires et des fichiers de configuration par défaut.

(venv) $> chameleon set_configuration_files
creating directory /root/.pg_chameleon
creating directory /root/.pg_chameleon/configuration/
creating directory /root/.pg_chameleon/logs/
creating directory /root/.pg_chameleon/pid/
copying configuration  example in /root/.pg_chameleon/configuration//config-example.yml

Maintenant, créez une copie de config-example.yml en tant que default.yml pour en faire le fichier de configuration par défaut. Un exemple de fichier de configuration utilisé pour cette démonstration est fourni ci-dessous.

$> cat default.yml
---
#global settings
pid_dir: '~/.pg_chameleon/pid/'
log_dir: '~/.pg_chameleon/logs/'
log_dest: file
log_level: info
log_days_keep: 10
rollbar_key: ''
rollbar_env: ''

# type_override allows the user to override the default type conversion into a different one.
type_override:
  "tinyint(1)":
    override_to: boolean
    override_tables:
      - "*"

#postgres  destination connection
pg_conn:
  host: "192.168.56.106"
  port: "5433"
  user: "usr_replica"
  password: "pass123"
  database: "db_replica"
  charset: "utf8"

sources:
  mysql:
    db_conn:
      host: "192.168.56.102"
      port: "3306"
      user: "usr_replica"
      password: "pass123"
      charset: 'utf8'
      connect_timeout: 10
    schema_mappings:
      world_x: pgworld_x
    limit_tables:
#      - delphis_mediterranea.foo
    skip_tables:
#      - delphis_mediterranea.bar
    grant_select_to:
      - usr_readonly
    lock_timeout: "120s"
    my_server_id: 100
    replica_batch_size: 10000
    replay_max_rows: 10000
    batch_retention: '1 day'
    copy_max_memory: "300M"
    copy_mode: 'file'
    out_dir: /tmp
    sleep_loop: 1
    on_error_replay: continue
    on_error_read: continue
    auto_maintenance: "disabled"
    gtid_enable: No
    type: mysql
    skip_events:
      insert:
        - delphis_mediterranea.foo #skips inserts on the table delphis_mediterranea.foo
      delete:
        - delphis_mediterranea #skips deletes on schema delphis_mediterranea
      update:

Le fichier de configuration utilisé dans cette démo est le fichier d'exemple fourni avec pg_chameleon avec des modifications mineures pour s'adapter aux environnements source et de destination, et un résumé des différentes sections du fichier de configuration suit.

Le fichier de configuration default.yml a une section "paramètres globaux" qui contrôle les détails tels que l'emplacement du fichier de verrouillage, les emplacements de journalisation et la période de rétention, etc. La section qui suit est la section "type override" qui est un ensemble de règles à remplacer types lors de la réplication. Un exemple de règle de remplacement de type est utilisé par défaut qui convertit un tinyint(1) en une valeur booléenne. La section suivante est la section des détails de connexion à la base de données de destination qui, dans notre cas, est une base de données PostgreSQL, désignée par "pg_conn". La dernière section est la section source qui contient tous les détails des paramètres de connexion à la base de données source, le mappage de schéma entre la source et la destination, toutes les tables à ignorer, y compris les paramètres de délai d'attente, de mémoire et de taille de lot. Notez les "sources" indiquant qu'il peut y avoir plusieurs sources vers une seule destination pour former une configuration de réplication plusieurs vers un.

Une base de données "world_x" est utilisée dans cette démo qui est un exemple de base de données avec 4 tables contenant des exemples de lignes, que la communauté MySQL propose à des fins de démonstration, et elle peut être téléchargée ici. L'exemple de base de données se présente sous la forme d'une archive tar et compressée avec des instructions pour la créer et y importer des lignes.

Un utilisateur dédié est créé dans les bases de données MySQL et PostgreSQL avec le même nom que usr_replica qui reçoit en outre des privilèges supplémentaires sur MySQL pour avoir un accès en lecture à toutes les tables en cours de réplication.

mysql> CREATE USER usr_replica ;
mysql> SET PASSWORD FOR usr_replica='pass123';
mysql> GRANT ALL ON world_x.* TO 'usr_replica';
mysql> GRANT RELOAD ON *.* to 'usr_replica';
mysql> GRANT REPLICATION CLIENT ON *.* to 'usr_replica';
mysql> GRANT REPLICATION SLAVE ON *.* to 'usr_replica';
mysql> FLUSH PRIVILEGES;

Une base de données est créée du côté PostgreSQL qui acceptera les modifications de la base de données MySQL, nommée "db_replica". L'utilisateur "usr_replica" dans PostgreSQL est automatiquement configuré en tant que propriétaire de deux schémas tels que "pgworld_x" et "sch_chameleon" qui contiennent respectivement les tables répliquées réelles et les tables de catalogue de réplication. Cette configuration automatique est effectuée par l'argument create_replica_schema, indiqué plus bas.

postgres=# CREATE USER usr_replica WITH PASSWORD 'pass123';
CREATE ROLE
postgres=# CREATE DATABASE db_replica WITH OWNER usr_replica;
CREATE DATABASE

La base de données MySQL est configurée avec quelques modifications de paramètres afin de la préparer à la réplication, comme indiqué ci-dessous, et nécessite un redémarrage du serveur de base de données pour que les modifications prennent effet.

$> vi /etc/my.cnf
binlog_format= ROW
binlog_row_image=FULL
log-bin = mysql-bin
server-id = 1

À ce stade, il est important de tester la connectivité aux deux serveurs de base de données pour s'assurer qu'il n'y a pas de problèmes lors de l'exécution des commandes pg_chameleon.

Sur le nœud PostgreSQL :

$> mysql -u usr_replica -Ap'admin123' -h 192.168.56.102 -D world_x 

Sur le nœud MySQL :

$> psql -p 5433 -U usr_replica -h 192.168.56.106 db_replica

Les trois commandes suivantes de pg_chameleon (chameleon) permettent de configurer l'environnement, d'ajouter une source et d'initialiser une réplique. L'argument "create_replica_schema" de pg_chameleon crée le schéma par défaut (sch_chameleon) et le schéma de réplication (pgworld_x) dans la base de données PostgreSQL comme cela a déjà été discuté. L'argument "add_source" ajoute la base de données source à la configuration en lisant le fichier de configuration (default.yml), qui dans ce cas est "mysql", tandis que "init_replica" initialise la configuration en fonction des paramètres du fichier de configuration.

$> chameleon create_replica_schema --debug
$> chameleon add_source --config default --source mysql --debug
$> chameleon init_replica --config default --source mysql --debug

La sortie des trois commandes ci-dessus est explicite et indique le succès de chaque commande avec un message de sortie évident. Toutes les pannes ou erreurs de syntaxe sont clairement mentionnées dans des messages simples et clairs, suggérant et incitant ainsi à des actions correctives.

La dernière étape consiste à démarrer la réplication avec "start_replica", dont le succès est indiqué par un indice de sortie comme indiqué ci-dessous.

$> chameleon start_replica --config default --source mysql 
output: Starting the replica process for source mysql

L'état de la réplication peut être interrogé avec l'argument "show_status" tandis que les erreurs peuvent être visualisées avec l'argument "show_errors".

$> chameleon show_status --source mysql  
OUTPUT: 
  Source id  Source name    Type    Status    Consistent    Read lag    Last read    Replay lag    Last replay
-----------  -------------  ------  --------  ------------  ----------  -----------  ------------  -------------
          1  mysql          mysql   running   No            N/A                      N/A

== Schema mappings ==
Origin schema    Destination schema
---------------  --------------------
world_x          pgworld_x

== Replica status ==
---------------------  ---
Tables not replicated  0
Tables replicated      4
All tables             4
Last maintenance       N/A
Next maintenance       N/A
Replayed rows
Replayed DDL
Skipped rows
---------------------  ---
$> chameleon show_errors --config default 
output: There are no errors in the log

Comme indiqué précédemment, chacune des fonctionnalités de réplication est gérée à l'aide de démons, qui peuvent être visualisés en interrogeant la table de processus à l'aide de la commande Linux "ps", présentée ci-dessous.

$>  ps -ef|grep chameleon
root       763     1  0 19:20 ?        00:00:00 /u01/media/mysql_samp_dbs/world_x-db/venv/bin/python3.6 /u01/media/mysq l_samp_dbs/world_x-db/venv/bin/chameleon start_replica --config default --source mysql
root       764   763  0 19:20 ?        00:00:01 /u01/media/mysql_samp_dbs/world_x-db/venv/bin/python3.6 /u01/media/mysq l_samp_dbs/world_x-db/venv/bin/chameleon start_replica --config default --source mysql
root       765   763  0 19:20 ?        00:00:00 /u01/media/mysql_samp_dbs/world_x-db/venv/bin/python3.6 /u01/media/mysq l_samp_dbs/world_x-db/venv/bin/chameleon start_replica --config default --source mysql

Aucune configuration de réplication n'est terminée tant qu'elle n'est pas soumise au test « d'application en temps réel », qui a été simulé comme ci-dessous. Cela implique de créer une table et d'insérer quelques enregistrements dans la base de données MySQL. Ensuite, l'argument "sync_tables" de pg_chameleon est invoqué pour mettre à jour les démons afin de répliquer la table avec ses enregistrements dans la base de données PostgreSQL.

mysql> create table t1 (n1 int primary key, n2 varchar(10));
Query OK, 0 rows affected (0.01 sec)
mysql> insert into t1 values (1,'one');
Query OK, 1 row affected (0.00 sec)
mysql> insert into t1 values (2,'two');
Query OK, 1 row affected (0.00 sec)

$> chameleon sync_tables --tables world_x.t1 --config default --source mysql
Sync tables process for source mysql started.

Le test est confirmé en interrogeant la table de la base de données PostgreSQL pour refléter les lignes.

$> psql -p 5433 -U usr_replica -d db_replica -c "select * from pgworld_x.t1";
 n1 |  n2
----+-------
  1 | one
  2 | two

S'il s'agit d'un projet de migration, les commandes pg_chameleon suivantes marqueront la fin de l'effort de migration. Les commandes doivent être exécutées après avoir confirmé que les lignes de toutes les tables cibles ont été répliquées, et le résultat sera une base de données PostgreSQL proprement migrée sans aucune référence à la base de données source ou au schéma de réplication (sch_chameleon).

$> chameleon stop_replica --config default --source mysql 
$> chameleon detach_replica --config default --source mysql --debug

En option, les commandes suivantes suppriment la configuration source et le schéma de réplication.

$> chameleon drop_source --config default --source mysql --debug
$> chameleon drop_replica_schema --config default --source mysql --debug

Avantages de l'utilisation de pg_chameleon

• Installation simple et configuration moins compliquée
• Dépannage et détection d'anomalies simples avec une sortie d'erreur facile à comprendre
• Des tables ad hoc supplémentaires peuvent être ajoutées à la réplication après l'initialisation, sans modifier aucune autre configuration
• Plusieurs sources peuvent être configurées pour une seule base de données de destination, ce qui est utile dans les projets de consolidation pour fusionner les données d'une ou plusieurs bases de données MySQL dans une seule base de données PostgreSQL
• Les tables sélectionnées peuvent ne pas être répliquées

Inconvénients de l'utilisation de pg_chameleon

• Pris en charge uniquement à partir de MySQL 5.5 en tant que base de données d'origine et PostgreSQL 9.5 et ultérieur pour la base de données de destination
• Nécessite que chaque table ait une clé primaire ou unique, sinon les tables sont initialisées pendant le processus init_replica mais elles ne pourront pas être répliquées
• Réplication unidirectionnelle, c'est-à-dire MySQL vers PostgreSQL. Limitant ainsi son utilisation à une seule configuration active-passive
• La base de données source ne peut être qu'une base de données MySQL, tandis que la prise en charge de la base de données PostgreSQL en tant que source est expérimentale avec d'autres limitations (cliquez ici pour en savoir plus)

Résumé de pg_chameleon

L'approche de réplication proposée par pg_chameleon est favorable à une migration de base de données de MySQL vers PostgreSQL. Cependant, l'une des limites importantes de la réplication unidirectionnelle peut décourager les professionnels des bases de données de l'adopter pour autre chose que la migration. Cet inconvénient de la réplication unidirectionnelle peut être résolu à l'aide d'un autre outil open source appelé SymmetricDS.

Afin d'étudier l'utilitaire plus en détail, veuillez vous référer à la documentation officielle ici. La référence de la ligne de commande peut être obtenue ici.

Un aperçu de SymmetricDS

SymmetricDS est un outil open source capable de répliquer n'importe quelle base de données vers n'importe quelle autre base de données, à partir de la liste populaire des serveurs de base de données tels qu'Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird et d'autres instances de bases de données basées sur le cloud telles que Redshift et Azure, etc. Certaines des offres incluent la synchronisation de bases de données et de fichiers, la réplication multimaître, la synchronisation filtrée et la transformation. L'outil est développé à l'aide de Java, nécessitant une édition standard (version 8.0 ou supérieure) de JRE ou de JDK. La fonctionnalité implique que les modifications de données soient capturées par des déclencheurs dans la base de données source et acheminées vers une base de données de destination participante en tant que lots sortants

Fonctionnalités de SymmetricDS

• Indépendant de la plate-forme, ce qui signifie que deux ou plusieurs bases de données différentes peuvent communiquer entre elles, n'importe quelle base de données vers n'importe quelle autre base de données
• Les bases de données relationnelles réalisent la synchronisation à l'aide de la capture de données modifiées, tandis que les systèmes basés sur le système de fichiers utilisent la synchronisation des fichiers
• Réplication bidirectionnelle à l'aide de la méthode Push et Pull, qui est réalisée sur la base de règles définies
• Le transfert de données peut également se produire sur des réseaux sécurisés et à faible bande passante
• Récupération automatique lors de la reprise d'un nœud en panne et résolution automatique des conflits
• Prêt pour le cloud et contient de puissantes API d'extension

Démo

SymmetricDS peut être configuré dans l'une des deux options :

• Un nœud maître (parent) qui agit comme un intermédiaire centralisé coordonnant la réplication des données entre deux nœuds esclaves (enfant), dans lequel la communication entre les deux nœuds enfants ne peut se produire que via le parent.
• Un nœud actif (nœud1) peut répliquer vers et depuis un autre nœud actif (nœud2) sans aucun intermédiaire.

Dans les deux options, la communication entre les nœuds se fait via des événements "Push" et "Pull". Dans cette démo, une configuration active-active entre deux nœuds sera expliquée. L'architecture complète peut être exhaustive, les lecteurs sont donc encouragés à consulter le guide de l'utilisateur disponible ici pour en savoir plus sur les composants internes de SymmetricDS.

L'installation de SymmetricDS est aussi simple que de télécharger la version open source du fichier zip à partir d'ici et de l'extraire dans un emplacement pratique. Les détails de l'emplacement d'installation et de la version de SymmetricDS dans cette démo sont conformes au tableau ci-dessous, ainsi que d'autres détails concernant les versions de base de données, les versions Linux, les adresses IP et le port de communication pour les deux nœuds participants.

La maison d'installation dans ce cas est "/usr/local/symmetric-server-3.9.20" qui sera le répertoire de base de SymmetricDS, qui contient divers autres sous-répertoires et fichiers. Deux des sous-répertoires qui ont maintenant de l'importance sont les « échantillons » et les « moteurs ». Le répertoire des exemples contient des exemples de fichiers de configuration des propriétés de nœud en plus d'exemples de scripts SQL pour lancer une démo rapide.

Les trois fichiers de configuration de propriétés de nœud suivants peuvent être vus dans le répertoire "samples" avec des noms indiquant la nature du nœud dans une configuration donnée.

corp-000.properties
store-001.properties
store-002.properties

Comme SymmetricDS est livré avec tous les fichiers de configuration nécessaires pour prendre en charge une configuration de base à 3 nœuds (option 1), il est pratique d'utiliser les mêmes fichiers de configuration pour configurer également une configuration à 2 nœuds (option 2). Le fichier de configuration prévu est copié du répertoire "samples" vers les "engines" sur l'hôte vm1, et il ressemble à ci-dessous.

$> cat engines/corp-000.properties
engine.name=corp-000
db.driver=com.mysql.jdbc.Driver
db.url=jdbc:mysql://192.168.1.107:3306/replica_db?autoReconnect=true&useSSL=false
db.user=root
db.password=admin123
registration.url=
sync.url=http://192.168.1.107:31415/sync/corp-000
group.id=corp
external.id=000

Le nom de ce nœud dans la configuration SymmetricDS est "corp-000" avec la connexion à la base de données gérée avec le pilote mysql jdbc en utilisant la chaîne de connexion comme indiqué ci-dessus avec les identifiants de connexion. La base de données à connecter est "replica_db" et les tables seront créées lors de la création de l'exemple de schéma. Le "sync.url" indique l'emplacement pour contacter le nœud pour la synchronisation.

Le nœud 2 sur l'hôte vm2 est configuré en tant que "store-001" avec le reste des détails comme configuré dans le fichier node.properties, illustré ci-dessous. Le nœud "store-001" exécute une base de données PostgreSQL, avec "pgdb_replica" comme base de données pour la réplication. Le "registration.url" permet à l'hôte "vm2" de communiquer avec l'hôte "vm1" pour extraire les détails de configuration.

$> cat engines/store-001.properties
engine.name=store-001
db.driver=org.postgresql.Driver
db.url=jdbc:postgresql://192.168.1.112:5832/pgdb_replica
db.user=postgres
db.password=admin123
registration.url=http://192.168.1.107:31415/sync/corp-000
group.id=store
external.id=001

La démo par défaut préconfigurée de SymmetricDS contient des paramètres pour configurer une réplication bidirectionnelle entre deux serveurs de base de données (deux nœuds). Les étapes ci-dessous sont exécutées sur l'hôte vm1 (corp-000), ce qui créera un exemple de schéma comportant 4 tables. De plus, l'exécution de "create-sym-tables" avec la commande "symadmin" créera les tables de catalogue qui stockent et contrôlent les règles et la direction de la réplication entre les nœuds. Enfin, les tables de démonstration sont chargées avec des exemples de données.

vm1$> cd /usr/local/symmetric-server-3.9.20/bin
vm1$> ./dbimport --engine corp-000 --format XML create_sample.xml
vm1$> ./symadmin --engine corp-000 create-sym-tables
vm1$> ./dbimport --engine corp-000 insert_sample.sql

Les tables de démonstration "item" et "item_selling_price" sont configurées automatiquement pour se répliquer de corp-000 à store-001, tandis que les tables de vente (sale_transaction et sale_return_line_item) sont configurées automatiquement pour se répliquer de store-001 à corp-000. L'étape suivante consiste à créer l'exemple de schéma dans la base de données PostgreSQL sur l'hôte vm2 (store-001), afin de le préparer à recevoir des données de corp-000.

vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> ./dbimport --engine store-001 --format XML create_sample.xml

Il est important de vérifier l'existence de tables de démonstration et de tables de catalogue SymmetricDS dans la base de données MySQL sur vm1 à ce stade. Notez que les tables système SymmetricDS (tables avec le préfixe "sym_") ne sont disponibles que dans le nœud corp-000 à ce stade, car c'est là que la commande "create-sym-tables" a été exécutée, qui sera l'endroit pour contrôler et gérer la réplication. En plus de cela, la base de données du nœud store-001 n'aura que 4 tables de démonstration sans données.

L'environnement est maintenant prêt à démarrer les processus du serveur "sym" sur les deux nœuds, comme indiqué ci-dessous.

vm1$> cd /usr/local/symmetric-server-3.9.20/bin
vm1$> sym 2>&1 &

Les entrées du journal sont toutes deux envoyées à un fichier journal d'arrière-plan (symmetric.log) sous un répertoire de journaux dans l'emplacement d'installation de SymmetricDS ainsi qu'à la sortie standard. Le serveur "sym" peut maintenant être lancé sur le nœud store-001.

vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> sym 2>&1 &

Le démarrage du processus de serveur "sym" sur l'hôte vm2 créera également les tables de catalogue SymmetricDS dans la base de données PostgreSQL. Le démarrage du processus de serveur "sym" sur les deux nœuds les amènera à se coordonner pour répliquer les données de corp-000 vers store-001. Après quelques secondes, l'interrogation des quatre tables de chaque côté affichera les résultats de la réplication réussie. Alternativement, une charge initiale peut également être envoyée au nœud store-001 à partir de corp-000 avec la commande ci-dessous.

vm1$> ./symadmin --engine corp-000 reload-node 001

À ce stade, un nouvel enregistrement est inséré dans la table "item" de la base de données MySQL au nœud corp-000 (hôte :vm1) et il peut être vérifié qu'il a bien été répliqué dans la base de données PostgreSQL au nœud store-001 (hôte :vm2 ). Cela montre l'événement "Pull" des données de corp-000 à store-001.

mysql> insert into item values ('22000002','Jelly Bean');
Query OK, 1 row affected (0.00 sec)

vm2$> psql -p 5832 -U postgres pgdb_replica -c "select * from item" 
 item_id  |   name
----------+-----------
 11000001 | Yummy Gum
 22000002 | Jelly Bean
(2 rows)

L'événement "Push" des données de store-001 à corp-000 peut être réalisé en insérant un enregistrement dans la table "sale_transaction" et en confirmant qu'il doit être répliqué.

pgdb_replica=# insert into "sale_transaction" ("tran_id", "store_id", "workstation", "day", "seq") values (1000, '001', '3', '2007-11-01', 100);
vm1$> [[email protected] ~]#  mysql -uroot -p'admin123' -D replica_db -e "select * from sale_transaction";
+---------+----------+-------------+------------+-----+
| tran_id | store_id | workstation | day        | seq |
+---------+----------+-------------+------------+-----+
|     900 | 001      | 3           | 2012-12-01 |  90 |
|    1000 | 001      | 3           | 2007-11-01 | 100 |
|    2000 | 002      | 2           | 2007-11-01 | 200 |
+---------+----------+-------------+------------+-----+

Cela marque la configuration réussie de la réplication bidirectionnelle des tables de démonstration entre une base de données MySQL et PostgreSQL. Tandis que la configuration de la réplication pour les tables utilisateur nouvellement créées peut être réalisée en procédant comme suit. Une table d'exemple "t1" est créée pour la démo et les règles de sa réplication sont configurées selon la procédure ci-dessous. Les étapes configurent uniquement la réplication de corp-000 vers store-001.

mysql> create table  t1 (no integer);
Query OK, 0 rows affected (0.01 sec)

mysql> insert into sym_channel (channel_id,create_time,last_update_time) 
values ('t1',current_timestamp,current_timestamp);
Query OK, 1 row affected (0.01 sec)

mysql> insert into sym_trigger (trigger_id, source_table_name,channel_id,
last_update_time, create_time) values ('t1', 't1', 't1', current_timestamp,
current_timestamp);
Query OK, 1 row affected (0.01 sec)

mysql> insert into sym_trigger_router (trigger_id, router_id,
Initial_load_order, create_time,last_update_time) values ('t1',
'corp-2-store-1', 1, current_timestamp,current_timestamp);
Query OK, 1 row affected (0.01 sec)

Après cela, la configuration est informée du changement de schéma d'ajout d'une nouvelle table en appelant la commande symadmin avec l'argument "sync-triggers" qui recréera les déclencheurs pour correspondre aux définitions de table. Ensuite, exécutez "send-schema" pour envoyer les modifications de schéma au nœud store-001, après quoi la réplication de la table "t1" sera configurée avec succès.

vm1$> ./symadmin -e corp-000 --node=001 sync-triggers    
vm1$> ./symadmin send-schema -e corp-000 --node=001 t1

Avantages de l'utilisation de SymmetricDS

• Installation et configuration sans effort, y compris un ensemble préconfiguré de fichiers de paramètres pour créer une configuration à 3 nœuds ou à 2 nœuds
• Base de données multiplateforme activée et indépendante de la plate-forme, y compris les serveurs, les ordinateurs portables et les appareils mobiles
• Répliquer n'importe quelle base de données vers n'importe quelle autre base de données, qu'elle soit sur site, WAN ou cloud
• Capable de gérer de manière optimale quelques bases de données à plusieurs milliers de bases de données pour répliquer les données de manière transparente
• Une version commerciale du logiciel offre une console de gestion pilotée par une interface graphique avec un excellent package de support

Inconvénients de l'utilisation de SymmetricDS

• La configuration manuelle de la ligne de commande peut impliquer la définition de règles et la direction de la réplication via des instructions SQL pour charger les tables du catalogue, ce qui peut être difficile à gérer
• Configurer un grand nombre de tables pour la réplication sera un effort considérable, à moins qu'une forme de script ne soit utilisée pour générer les instructions SQL définissant les règles et la direction de la réplication
• Beaucoup d'informations de journalisation encombrent le fichier journal, nécessitant ainsi une maintenance périodique du fichier journal pour ne pas permettre au fichier journal de remplir le disque

Résumé DS symétrique

SymmetricDS offre la possibilité de configurer une réplication bidirectionnelle entre 2 nœuds, 3 nœuds, etc. pour plusieurs milliers de nœuds afin de répliquer les données et de réaliser la synchronisation des fichiers. Il s'agit d'un outil unique qui effectue de nombreuses tâches de maintenance d'auto-réparation telles que la récupération automatique des données après de longues périodes d'indisponibilité dans un nœud, une communication sécurisée et efficace entre les nœuds à l'aide de HTTPS et la gestion automatique des conflits basée sur des règles définies. , etc. The essential feature of replicating any database to any other database makes SymmetricDS ready to be deployed for a number of use cases including migration, version and patch upgrade, distribution, filtering and transformation of data across diverse platforms.

The demo was created by referring to the official quick-start tutorial of SymmetricDS which can be accessed from here. The user guide can be found here, which provides a detailed account of various concepts involved in a SymmetricDS replication setup.