Réplication croisée entre PostgreSQL et MySQL

Je vais vous parler en général de la réplication croisée entre PostgreSQL et MySQL, ainsi que des méthodes de configuration de cette réplication entre ces deux serveurs de base de données. Les bases de données en réplication croisée sont généralement appelées homogènes, et c'est une méthode pratique pour migrer d'un serveur de SGBDR à un autre.

Les bases de données PostgreSQL et MySQL sont traditionnellement considérées comme relationnelles, mais avec des extensions supplémentaires, elles offrent également des possibilités NoSQL. Ici, nous allons discuter de la réplication entre PostgreSQL et MySQL, du point de vue des SGBDR.

Nous ne décrirons pas l'ensemble de l'architecture interne, juste les principes de base, afin que vous ayez une idée de la configuration de la réplication entre les serveurs de base de données, des avantages, des limitations et des scénarios d'utilisation.

En général, la réplication entre deux serveurs de base de données identiques s'effectue soit en mode binaire, soit par des requêtes entre le nœud principal (aussi appelé éditeur, maître ou actif) et l'égal (abonné, en attente ou passif). L'objectif de la réplication est de fournir en temps réel une copie de la base de données principale sur le côté de l'égal. Les données sont ainsi transférées du principal vers l'égal, c'est-à-dire de l'actif vers le passif, car la réplication ne se fait que dans un sens. Toutefois, il est possible de configurer une réplication entre deux bases de données dans les deux sens, permettant le transfert de données de l'égal vers le principal dans une configuration « actif-actif ». Tout cela, y compris la réplication en cascade, est possible entre deux serveurs de base de données identiques ou plus. La configuration « actif-actif » ou « actif-passif » dépend des besoins, de la disponibilité de ces fonctionnalités dans la configuration d'origine ou de l'utilisation de solutions externes pour la configuration et des compromis existants.

La configuration décrite est possible entre différents serveurs de base de données. Un serveur peut être configuré pour recevoir des données répliquées d'un autre serveur de base de données tout en sauvegardant des instantanés des données répliquées en temps réel. MySQL et PostgreSQL proposent la plupart de ces configurations, soit par leurs propres moyens, soit par le biais d'extensions tierces, y compris des méthodes de journal binaire, de verrouillage de disque et des méthodes basées sur des opérateurs et des lignes.

La réplication croisée entre MySQL et PostgreSQL est nécessaire pour une migration unique d'un serveur de base de données à un autre. Ces bases de données utilisent différents protocoles, il n'est donc pas possible de les relier directement. Pour établir un échange de données, vous pouvez utiliser un outil open source externe, comme pg_chameleon.

Qu'est-ce que pg_chameleon

pg_chameleon est un système de réplication de MySQL vers PostgreSQL en Python 3. Il utilise une bibliothèque open source mysql-replication, également en Python. Les images de lignes sont extraites des tables MySQL et enregistrées en tant qu'objets JSONB dans la base de données PostgreSQL, puis décodées par une fonction pl/pgsql et reproduites dans la base de données PostgreSQL.

Fonctionnalités de pg_chameleon

Plusieurs schémas MySQL d'un même cluster peuvent être répliqués dans une seule base de données cible PostgreSQL avec une configuration « un à plusieurs »
Les noms des schémas source et cible ne peuvent pas coïncider.
Les données de réplication peuvent être extraites d'une réplique en cascade MySQL.
Les tables qui ne peuvent pas être répliquées ou qui génèrent des erreurs sont exclues.
Chaque fonction de réplication est gérée par des démons.
Contrôle via des paramètres et des fichiers de configuration basés sur YAML.

Exemple

Hôte
vm1
vm2

Version du système d'exploitation
CentOS Linux 7.6 x86_64
CentOS Linux 7.5 x86_64

Version du serveur de base de données
MySQL 5.7.26
PostgreSQL 10.5

Port de la base de données
3306
5433

Adresse IP
192.168.56.102
192.168.56.106

Pour commencer, préparez tous les composants nécessaires à l'installation de pg_chameleon. Dans cet exemple, Python 3.6.8 est installé, créant un environnement virtuel et l'activant.

$> 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

Après l'installation réussie de Python 3.6, vous devez remplir les autres exigences, comme créer et activer un environnement virtuel. De plus, le module pip est mis à jour vers la dernière version et utilisé pour installer pg_chameleon. Dans les commandes ci-dessous, nous choisissons intentionnellement d'installer pg_chameleon 2.0.9, même si la version la plus récente est 2.0.10. Cela est nécessaire pour éviter de nouveaux bugs 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

Ensuite, nous invoquons pg_chameleon (chameleon est la commande) avec l'argument set_configuration_files pour activer pg_chameleon et créer les répertoires et 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/
coping configuration example in /root/.pg_chameleon/configuration//config-example.yml

Nous créons maintenant une copie de config-example.yml en tant que default.yml, afin qu'elle devienne le fichier de configuration par défaut. Un exemple de fichier de configuration pour cet exemple est donné ci-dessous.

$> cat default.yml
---
#paramètres globaux
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 permet à l'utilisateur de remplacer la conversion de type par défaut par une autre.
type_override:
  "tinyint(1)":
    override_to: boolean
    override_tables:
      - "*"

# connexion de destination postgres
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 #ignore les insertions dans la table delphis_mediterranea.foo
      delete:
        - delphis_mediterranea #ignore les suppressions dans le schéma delphis_mediterranea
      update:

Le fichier de configuration dans cet exemple est un modèle de fichier pg_chameleon avec des modifications mineures en fonction des environnements source et cible, et ci-dessous se trouve un aperçu des différentes sections du fichier de configuration.

Le fichier de configuration default.yml contient une section de paramètres globaux (global settings), où vous pouvez gérer des réglages tels que l'emplacement du fichier de verrouillage, l'emplacement des journaux, la période de conservation des journaux, etc. Ensuite, il y a une section de remplacement de type (type override), où un ensemble de règles pour le remplacement des types pendant la réplication est spécifié. Dans l'exemple par défaut, une règle de remplacement de type est utilisée pour convertir tinyint(1) en une valeur booléenne. Dans la section suivante, nous spécifions les détails de connexion à la base de données cible. Dans notre cas, il s'agit d'une base de données PostgreSQL, désignée par pg_conn. Dans la dernière section, nous indiquons les données sources, c'est-à-dire les paramètres de connexion à la base de données source, le schéma de correspondance entre les bases de données source et cible, les tables à ignorer, le délai d'attente, la mémoire, la taille des lots. Notez que « sources » est précisé au pluriel, indiquant que nous pouvons ajouter plusieurs bases de données sources pour une seule cible afin de configurer une configuration « plusieurs à un ».

La base de données world_x dans l'exemple contient 4 tables avec des lignes que la communauté MySQL propose à titre d'exemple. Elle peut être téléchargée. ici. L'exemple de base de données est fourni sous forme d'archive tar compressée avec des instructions pour créer et importer des lignes.

Dans les bases de données MySQL et PostgreSQL, un utilisateur spécial est créé avec le même nom usr_replica. Dans MySQL, il reçoit des droits supplémentaires pour lire toutes les tables répliquées.

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;

Du côté de PostgreSQL, une base de données db_replica est créée, qui accueillera les modifications de la base de données MySQL. L'utilisateur usr_replica dans PostgreSQL est automatiquement configuré comme propriétaire de deux schémas pgworld_x et sch_chameleon, qui contiennent respectivement les tables répliquées réelles et les tables de catalogues de réplication. La configuration automatique est gérée par l'argument create_replica_schema, comme vous le verrez ci-dessous.

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 des modifications de certains paramètres pour la préparer à la réplication, comme montré ci-dessous. Il sera nécessaire de redémarrer le serveur de base de données pour que les changements prennent effet.

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

Il est maintenant important de vérifier la connexion aux deux serveurs de base de données pour éviter tout problème 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) préparent l'environnement, ajoutent la source et initialisent la réplique. L'argument create_replica_schema dans 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 nous l'avons déjà mentionné. L'argument add_source ajoute la base de données source à la configuration en lisant le fichier de configuration (default.yml), et dans notre cas, c'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

Les sorties de ces trois commandes indiquent clairement leur exécution réussie. Tous les dysfonctionnements ou erreurs de syntaxe sont signalés par des messages simples et compréhensibles, accompagnés de conseils pour corriger les problèmes.

Enfin, lançons la réplication en utilisant start_replica et recevons un message de succès.

$> chameleon start_replica --config default --source mysql 
output: Démarrage du processus de réplication pour la source mysql

Le statut de la réplication peut être interrogé à l'aide de l'argument show_status, et les erreurs peuvent être consultées à l'aide de l'argument show_errors.

Résultat.

Comme nous l'avons déjà mentionné, chaque fonction de réplication est gérée par des démons. Pour les visualiser, interrogeons la table des processus avec la commande Linux ps, comme indiqué ci-dessous.

Résultat.

La réplication n'est pas considérée comme configurée tant que nous ne l'avons pas testée en temps réel, comme indiqué ci-dessous. Nous créons une table, insérons quelques enregistrements dans la base de données MySQL et activons l'argument sync_tables dans pg_chameleon pour mettre à jour les démons et répliquer la table avec les 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
Processus de synchronisation des tables pour la source mysql démarré.

Pour confirmer les résultats du test, interrogeons la table de la base de données PostgreSQL et affichons les lignes.

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

Si nous effectuons une migration, les commandes pg_chameleon suivantes en seront la conclusion. Les commandes doivent être exécutées après que nous nous soyons assurés que les lignes de toutes les tables cibles ont été répliquées, le résultat étant une base de données PostgreSQL soigneusement transférée sans liens vers la base de données source ou le schéma de réplication (sch_chameleon).

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

Facultativement, les commandes suivantes peuvent être utilisées pour supprimer 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

Les avantages de pg_chameleon

Configuration et paramétrage simples.
Dépannage et identification des anomalies faciles avec des messages d'erreur clairs.
Il est possible d'ajouter des tables spéciales supplémentaires à la réplication après l'initialisation, sans modifier le reste de la configuration.
Il est possible de configurer plusieurs bases de données sources pour une seule cible, ce qui est très pratique si vous combinez des données provenant d'une ou plusieurs bases de données MySQL dans une seule base de données PostgreSQL.
Il est possible de ne pas répliquer les tables sélectionnées.

Inconvénients de pg_chameleon

Il est supporté uniquement avec MySQL 5.5 et supérieur comme source et PostgreSQL 9.5 et supérieur comme base de données cible.
Chaque table doit avoir une clé primaire ou unique, sinon les tables sont initialisées lors du processus init_replica, mais ne sont pas répliquées.
La réplication unidirectionnelle — uniquement de MySQL vers PostgreSQL. Elle convient donc uniquement au schéma « actif-passif ».
La source ne peut être qu'une base de données MySQL, et le support de la base de données PostgreSQL comme source est seulement expérimental et avec des contraintes (en savoir plus ici)

Résumé sur pg_chameleon

La méthode de réplication dans pg_chameleon est idéale pour migrer une base de données de MySQL vers PostgreSQL. Le principal inconvénient est que la réplication est uniquement unidirectionnelle, donc les experts en bases de données ne voudront probablement l'utiliser que pour des migrations. Mais le problème de la réplication unidirectionnelle peut être résolu par un autre outil open source : SymmetricDS.

Pour plus de détails, consultez la documentation officielle ici. L'aide en ligne pour la ligne de commande est disponible ici.

Aperçu de SymmetricDS

SymmetricDS est un outil open source qui réplique n'importe quelle base de données vers une autre base de données courante : Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird et d'autres instances cloud de bases de données, comme Redshift et Azure, etc. Les fonctionnalités disponibles : synchronisation de bases de données et de fichiers, réplication de plusieurs bases de données sources, synchronisation filtrée, transformation, et autres. C'est un outil basé sur Java, nécessitant une version standard de JRE ou JDK (version 8.0 ou supérieure). Il est possible d'enregistrer les modifications des données par des déclencheurs dans la base de données source et de les diriger vers la base de données cible correspondante sous forme de paquets.

Fonctionnalités de SymmetricDS

L'outil est indépendant de la plateforme, ce qui signifie que deux bases de données différentes ou plus peuvent échanger des données.
Les bases de données relationnelles sont synchronisées par l'enregistrement des modifications de données, tandis que les bases de données basées sur des systèmes de fichiers utilisent la synchronisation de fichiers.
Réplication bidirectionnelle en utilisant des méthodes Push et Pull basées sur un ensemble de règles.
Le transfert de données est possible via des réseaux sécurisés et des réseaux à faible bande passante.
Récupération automatique lors de la reprise des nœuds après une panne et résolution automatique des conflits.
Compatibilité avec le cloud et API d'extension efficaces.

Exemple

SymmetricDS peut être configuré dans l'un des deux modes :
Un nœud principal (parent) qui coordonne de manière centralisée la réplication des données entre deux nœuds secondaires (enfant), et les échanges de données entre les nœuds enfants se font uniquement par l'intermédiaire du parent.
Un nœud actif (nœud 1) peut échanger des données pour la réplication avec un autre nœud actif (nœud 2) sans intermédiaire.

Dans les deux cas, l'échange de données se fait via Push et Pull. Dans cet exemple, nous allons examiner la configuration « actif-actif ». Décrire toute l'architecture prend trop de temps, donc consultez guide, pour en savoir plus sur le dispositif SymmetricDS.

Installer SymmetricDS est très simple : téléchargez la version open source du fichier zip d'ici et décompressez-le où vous le souhaitez. Le tableau ci-dessous fournit des informations sur l'emplacement de l'installation et la version de SymmetricDS dans cet exemple, ainsi que les versions des bases de données, les versions Linux, les adresses IP et les ports pour les deux nœuds.

Hôte
vm1
vm2

Version du système d'exploitation
CentOS Linux 7.6 x86_64
CentOS Linux 7.6 x86_64

Version du serveur de base de données
MySQL 5.7.26
PostgreSQL 10.5

Port de la base de données
3306
5832

Adresse IP
192.168.1.107
192.168.1.112

Version de SymmetricDS
SymmetricDS 3.9
SymmetricDS 3.9

Chemin d'installation de SymmetricDS
/usr/local/symmetric-server-3.9.20
/usr/local/symmetric-server-3.9.20

Nom du nœud SymmetricDS
corp-000
store-001

Ici, nous installons SymmetricDS dans /usr/local/symmetric-server-3.9.20, et différents sous-répertoires et fichiers seront stockés ici. Nous nous intéressons aux sous-répertoires samples et engines. Le répertoire samples contient des exemples de fichiers de configuration avec les propriétés du nœud, ainsi que des exemples de scripts SQL pour un démarrage rapide de la démonstration.

Dans le répertoire samples, nous voyons trois fichiers de configuration avec les propriétés du nœud — le nom indique la nature du nœud dans un schéma donné.

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

SymmetricDS contient tous les fichiers de configuration nécessaires pour un schéma de base de 3 nœuds (option 1), et ces mêmes fichiers peuvent être utilisés pour un schéma de 2 nœuds (option 2). Nous copions le fichier de configuration nécessaire du répertoire samples dans engines sur l'hôte vm1. Cela donne :

$> 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

Ce nœud dans la configuration de SymmetricDS s'appelle corp-000, et la connexion à la base de données est gérée par le pilote mysql jdbc, qui utilise la chaîne de connexion indiquée ci-dessus et les identifiants de connexion. Nous nous connectons à la base de données replica_db, et lors de la création du schéma, des tables seront créées. sync.url indique l'emplacement de liaison avec le nœud pour la synchronisation.

Le nœud 2 sur l'hôte vm2 est configuré comme store-001, et le reste est indiqué dans le fichier node.properties ci-dessous. Le nœud store-001 exécute une base de données PostgreSQL, et pgdb_replica est la base de données pour la réplication. registration.url permet à l'hôte vm2 de contacter l'hôte vm1 et d'obtenir 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

L'exemple de SymmetricDS comprend 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), qui créera un exemple de schéma avec 4 tables. Ensuite, l'exécution de create-sym-tables avec la commande symadmin crée des tables de catalogues où seront stockées les règles et la direction de réplication entre les nœuds. Enfin, des données d'exemple sont chargées dans les tables.

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

Dans l'exemple, les tables item et item_selling_price sont configurées automatiquement pour la réplication de corp-000 vers store-001, tandis que les tables sale (sale_transaction et sale_return_line_item) sont automatiquement configurées pour la réplication de store-001 vers corp-000. Nous créons maintenant le schéma dans la base de données PostgreSQL sur l'hôte vm2 (store-001) pour 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

Assurez-vous qu'il y a des exemples de tables et des tables de catalogues SymmetricDS dans la base de données MySQL sur vm1. Notez que les tables système de SymmetricDS (avec le préfixe sym_) sont actuellement disponibles uniquement sur le nœud corp-000, car c'est là que nous avons exécuté la commande create-sym-tables et que nous allons gérer la réplication. En outre, la base de données sur le nœud store-001 n'aura que 4 tables d'exemple sans données.

C'est tout. L'environnement est prêt pour le lancement des processus 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 enregistrements des journaux sont envoyés dans le fichier de journal en arrière-plan (symmetric.log) dans le dossier des journaux du répertoire où SymmetricDS est installé, ainsi que dans la sortie standard. Le serveur sym peut maintenant être initié sur le nœud store-001.

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

Si vous lancez le processus serveur sym sur l'hôte vm2, il créera également des tables de répertoire SymmetricDS dans la base de données PostgreSQL. Si vous lancez le processus serveur sym sur les deux nœuds, ils se coordonneront pour répliquer les données de corp-000 vers store-001. Si, après quelques secondes, nous demandons les 4 tables de chaque côté, nous verrons que la réplication a été effectuée avec succès. Ou vous pouvez envoyer un chargement initial vers le nœud store-001 depuis corp-000 avec la commande suivante.

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 sur le nœud corp-000 (hôte : vm1), et nous pouvons vérifier sa réplication dans la base de données PostgreSQL sur le nœud store-001. Nous voyons une opération Pull pour déplacer les données de corp-000 vers 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)

Pour effectuer une opération Push pour déplacer des données de store-001 vers corp-000, nous insérons un enregistrement dans la table sale_transaction et vérifions que la réplication a été effectuée.

Résultat.

Nous voyons la configuration réussie de la réplication bidirectionnelle des tables d'exemple entre les bases de données MySQL et PostgreSQL. Pour configurer la réplication pour de nouvelles tables utilisateur, nous effectuons les étapes suivantes. Nous créons la table t1 à titre d'exemple et configurons les règles de sa réplication comme suit. Ainsi, nous configurons 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)

La configuration reçoit une notification de modification du schéma, c'est-à-dire l'ajout d'une nouvelle table, à l'aide de la commande symadmin avec l'argument sync-triggers, qui recrée les déclencheurs pour faire correspondre les définitions des tables. L'envoi du schéma est exécuté pour transmettre les modifications du schéma au nœud store-001, et la réplication de la table t1 est configurée.

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

Avantages de SymmetricDS

Installation et configuration simples, y compris un ensemble de fichiers prêts à l'emploi avec des paramètres pour créer un schéma avec trois ou deux nœuds.
Cross-plateforme des bases de données et indépendance par rapport à la plateforme, y compris serveurs, ordinateurs portables et appareils mobiles.
Réplication de n'importe quelle base de données dans n'importe quelle autre base de données localement, dans un WAN ou dans le cloud.
Possibilité de fonctionnement optimal avec une paire de bases de données ou plusieurs milliers pour une réplication facile.
Version payante avec interface graphique et excellent support.

Inconvénients de SymmetricDS

Il est nécessaire de définir manuellement dans la ligne de commande les règles et la direction de la réplication à travers des opérateurs SQL pour charger les tables de catalogue, ce qui peut être peu pratique.
Configurer de nombreuses tables pour la réplication peut être fastidieux si on n'utilise pas de scripts pour créer des opérateurs SQL définissant les règles et la direction de la réplication.
Trop d'informations sont enregistrées dans les logs, et parfois il faut faire le tri dans le fichier log pour qu'il ne prenne pas trop de place.

Résumé sur SymmetricDS

SymmetricDS permet de configurer une réplication bidirectionnelle entre deux, trois et même plusieurs milliers de nœuds pour effectuer la réplication et synchroniser des fichiers. C'est un outil unique qui exécute de nombreuses tâches de manière autonome, telles que la récupération automatique des données après une longue période d'inactivité sur un nœud, un échange de données sécurisé et efficace entre les nœuds via HTTPS, une gestion automatique des conflits basée sur un ensemble de règles, etc. SymmetricDS réalise la réplication entre toutes les bases de données, ce qui permet de l'utiliser pour divers scénarios, y compris la migration, la mise à niveau, la distribution, le filtrage et la transformation des données sur différentes plateformes.

L'exemple est basé sur le guide rapide officiel de SymmetricDS. Dans manuel de l'utilisateur Les différents concepts liés à la configuration de la réplication à l'aide de SymmetricDS sont décrits en détail.

Source : habr.com