Je décrirai la réplication croisée entre PostgreSQL et MySQL, ainsi que les méthodes de configuration de la réplication croisée entre les deux serveurs de base de données. En règle générale, les bases de données répliquées de manière croisée sont dites homogènes et constituent une méthode pratique pour passer d'un serveur SGBDR à un autre.
Les bases de données PostgreSQL et MySQL sont généralement considérées comme relationnelles, mais avec des extensions supplémentaires, elles offrent des fonctionnalités NoSQL. Ici, nous discuterons de la réplication entre PostgreSQL et MySQL du point de vue d'un SGBD relationnel.
Nous ne décrirons pas tout le fonctionnement interne, juste les principes de base afin que vous ayez une idée de la configuration de la réplication entre serveurs de bases de données, des avantages, des limites et des cas d'utilisation.
Généralement, la réplication entre deux serveurs de bases de données identiques s'effectue soit en mode binaire, soit à l'aide de requêtes entre un maître (c'est-à-dire éditeur, maître ou actif) et un esclave (abonné, veille 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 côté esclave. Dans ce cas, les données sont transférées du maître à l'esclave, c'est-à-dire de l'actif au passif, car la réplication s'effectue dans un seul sens. Mais vous pouvez configurer la réplication entre deux bases de données dans les deux sens, afin que les données soient transférées de l'esclave au maître dans une configuration active-active. Tout cela, y compris la réplication en cascade, est possible entre deux ou plusieurs serveurs de bases de données identiques. La configuration active-active ou active-passive dépend des besoins, de la disponibilité de ces fonctionnalités dans la configuration initiale ou de l'utilisation de solutions de configuration externes et des compromis existants.
La configuration décrite est possible entre différents serveurs de bases de données. Le serveur peut être configuré pour accepter les données répliquées d'un autre serveur de base de données tout en conservant des instantanés en temps réel des données répliquées. MySQL et PostgreSQL proposent la plupart de ces configurations en interne ou via des extensions tierces, notamment les méthodes de journalisation binaire, le verrouillage de disque et les méthodes basées sur les instructions et les 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 des protocoles différents, il n'est donc pas possible de les relier directement. Pour établir l'échange de données, vous pouvez utiliser un outil open source externe, par exemple 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 la bibliothèque open source mysql-replication, également en Python. Les images de lignes sont extraites des tables MySQL et stockées sous forme d'objets JSONB dans la base de données PostgreSQL, puis déchiffrées par la fonction pl/pgsql et reproduites dans la base de données PostgreSQL.
Caractéristiques de pg_chameleon
Plusieurs schémas MySQL du même cluster peuvent être répliqués vers une seule base de données PostgreSQL cible dans une configuration un-à-plusieurs.
Les noms des schémas source et cible ne peuvent pas être identiques.
Les données de réplication peuvent être récupérées à partir d'une réplique MySQL en cascade.
Les tables qui ne peuvent pas être répliquées ou qui produisent des erreurs sont exclues.
Chaque fonction de réplication est contrôlé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 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 pour installer pg_chameleon. Cet exemple installe Python 3.6.8, qui crée et active l'environnement virtuel.
$> 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 altinstallAprès avoir installé avec succès Python3.6, vous devez remplir les conditions restantes, telles que la création et l'activation d'un environnement virtuel. De plus, le module pip est mis à jour vers la dernière version et utilisé pour installer pg_chameleon. Les commandes ci-dessous installent intentionnellement pg_chameleon 2.0.9, bien que la dernière version soit la 2.0.10. Ceci 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.9Nous appelons ensuite pg_chameleon (chameleon est une commande) avec l'argument set_configuration_files pour activer pg_chameleon et 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.ymlNous créons maintenant une copie de config-example.yml en tant que default.yml afin qu'il devienne le fichier de configuration par défaut. Un exemple de fichier de configuration pour cet exemple 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 dans cet exemple est un exemple de fichier pg_chameleon avec des modifications mineures pour s'adapter aux environnements source et cible, et vous trouverez ci-dessous un aperçu des différentes sections du fichier de configuration.
Dans le fichier de configuration default.yml, il y a une section de paramètres globaux, dans laquelle vous pouvez gérer des paramètres tels que l'emplacement du fichier de verrouillage, l'emplacement des journaux, la période de stockage des journaux, etc. Vient ensuite la section de remplacement de type, où un ensemble de règles pour remplacer les types lors de la réplication. L'exemple utilise par défaut une règle de substitution de type qui convertit 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 pg_conn. Dans la dernière section, nous indiquons les données source, c'est-à-dire les paramètres de connexion de la base de données source, le schéma de mappage entre les bases de données source et cible, les tables qui doivent être ignorées, le temps d'attente, la mémoire, la taille du package. Notez que « sources » est au pluriel, ce qui signifie que nous pouvons ajouter plusieurs bases de données sources à une seule base de données cible pour mettre en place une configuration plusieurs-à-un.
L'exemple de base de données world_x contient 4 tables avec des lignes que la communauté MySQL propose à titre d'exemple. Il peut être téléchargé . L'exemple de base de données se présente sous la forme d'une archive tar et 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 dispose de droits de lecture supplémentaires sur 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 acceptera 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 du répertoire de réplication. L'argument create_replica_schema est responsable de la configuration automatique, 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 DATABASELa base de données MySQL est configurée avec quelques modifications de paramètres pour la préparer à la réplication, comme indiqué ci-dessous. Vous devrez redémarrer le 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 = 1Il est maintenant important de vérifier la connexion aux deux serveurs de base de données afin qu'il n'y ait aucun 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_xSur le nœud MySQL :
$> psql -p 5433 -U usr_replica -h 192.168.56.106 db_replicaLes trois commandes pg_chameleon (chameleon) suivantes préparent l'environnement, ajoutent la source et initialisent la réplique. L'argument create_replica_schema de pg_chameleon crée un schéma par défaut (sch_chameleon) et un schéma de réplication (pgworld_x) dans la base de données PostgreSQL, comme nous l'avons déjà évoqué. L'argument add_source ajoute une base de données source à la configuration en lisant le fichier de configuration (default.yml), et dans notre cas c'est mysql, et 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 --debugLe résultat de ces trois commandes indique clairement qu’elles ont été exécutées avec succès. Tout plantage ou erreur de syntaxe est signalé dans des messages simples et clairs avec des conseils sur la façon de résoudre le problème.
Enfin, nous démarrons la réplication en utilisant start_replica et recevons un message de réussite.
$> chameleon start_replica --config default --source mysql
output: Starting the replica process for source mysqlL'état de la réplication peut être interrogé à l'aide de l'argument show_status et les erreurs peuvent être visualisées à l'aide de l'argument show_errors.
Comme nous l'avons déjà dit, chaque fonction de réplication est contrôlée par des démons. Pour les afficher, nous interrogeons la table des processus avec la commande Linux ps, comme indiqué ci-dessous.
La réplication n'est pas considérée comme configurée tant que nous ne la testons pas 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 appelons 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
Sync tables process for source mysql started.Pour confirmer les résultats du test, nous interrogeons la table à partir 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 | twoSi nous effectuons une migration, les commandes pg_chameleon suivantes en seront la fin. Les commandes doivent être exécutées une fois que nous sommes sûrs que les lignes de toutes les tables cibles ont été répliquées, et le résultat sera une base de données PostgreSQL soigneusement migrée sans références à 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 --debugSi vous le souhaitez, vous pouvez utiliser les commandes suivantes pour supprimer la configuration d'origine et le schéma de réplication.
$> chameleon drop_source --config default --source mysql --debug
$> chameleon drop_replica_schema --config default --source mysql --debugAvantages de pg_chameleon
Installation et configuration faciles.
Dépannez et identifiez facilement les anomalies avec des messages d’erreur clairs.
Des tables spéciales supplémentaires peuvent être ajoutées à 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 base de données cible, ce qui est très utile si vous combinez les données d'une ou plusieurs bases de données MySQL dans une seule base de données PostgreSQL.
Vous n'êtes pas obligé de répliquer les tables sélectionnées.
Inconvénients de pg_chameleon
Uniquement pris en charge 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.
Réplication unidirectionnelle - uniquement de MySQL vers PostgreSQL. Il ne convient donc que pour le circuit « actif-passif ».
La source ne peut être qu'une base de données MySQL, et la prise en charge d'une base de données PostgreSQL en tant que source est uniquement expérimentale et avec des limitations (en savoir plus )
Résultats pour 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. L'inconvénient majeur est que la réplication n'est qu'unidirectionnelle, de sorte qu'il est peu probable que les professionnels des bases de données veuillent l'utiliser pour autre chose que la migration. Mais le problème de la réplication unidirectionnelle peut être résolu avec un autre outil open source : SymmetricDS.
En savoir plus dans la documentation officielle . L'aide en ligne de commande peut être trouvée .
Présentation de SymmetricDS
SymmetricDS est un outil open source qui réplique n'importe quelle base de données vers n'importe quelle autre base de données commune : Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird et d'autres instances de bases de données cloud, par exemple Redshift, et Azure, etc. Fonctionnalités disponibles : synchronisation de bases de données et de fichiers, réplication de bases de données multi-maîtres, synchronisation filtrée, transformation et autres. Il s'agit d'un outil Java et nécessite une version standard du JRE ou du JDK (version 8.0 ou supérieure). Ici, les modifications des données apportées aux déclencheurs dans la base de données source peuvent être enregistrées et envoyées à la base de données cible appropriée sous forme de lots.
Fonctionnalités SymmetricDS
L'outil est indépendant de la plate-forme, ce qui signifie que deux ou plusieurs bases de données différentes peuvent échanger des données.
Les bases de données relationnelles sont synchronisées à l'aide d'enregistrements de modifications de données, tandis que les bases de données basées sur le système de fichiers utilisent la synchronisation de fichiers.
Réplication bidirectionnelle utilisant les méthodes Push et Pull basées sur un ensemble de règles.
Le transfert de données est possible sur des réseaux sécurisés et à faible bande passante.
Récupération automatique lorsque les nœuds reprennent leur fonctionnement après une panne et résolution automatique des conflits.
API d'extension puissantes et compatibles avec le cloud.
Exemple
SymmetricDS peut être configuré selon l'une des deux options suivantes :
Un nœud maître (parent) qui coordonne de manière centralisée la réplication des données entre deux nœuds esclaves (enfants), et la communication entre les nœuds enfants s'effectue uniquement via le parent.
Un nœud actif (nœud 1) peut communiquer pour la réplication avec un autre nœud actif (nœud 2) sans intermédiaire.
Dans les deux options, l'échange de données s'effectue via Push et Pull. Dans cet exemple, nous considérerons une configuration active-active. Il serait trop long de décrire l’ensemble de l’architecture, alors faites vos recherches. pour en savoir plus sur le périphérique SymmetricDS.
L'installation de SymmetricDS est très simple : téléchargez la version open source du fichier zip et emportez-le où vous voulez. Le tableau ci-dessous fournit des informations sur l'emplacement d'installation et la version de SymmetricDS dans cet exemple, ainsi que sur les versions de base de données, les versions Linux, les adresses IP et les ports des 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 base de données
3306
5832
Adresse IP
192.168.1.107
192.168.1.112
Version SymmetricDS
SymétriqueDS 3.9
SymétriqueDS 3.9
Chemin d'installation de SymmetricDS
/usr/local/serveur-symétrique-3.9.20
/usr/local/serveur-symétrique-3.9.20
Nom du nœud SymmetricDS
corp-000
magasin-001
Ici, nous installons SymmetricDS dans /usr/local/symétrique-server-3.9.20, et divers sous-répertoires et fichiers y seront stockés. Nous sommes intéressés par les sous-répertoires samples et moteurs. Le répertoire samples contient des exemples de fichiers de configuration avec des propriétés de nœud, ainsi que des exemples de scripts SQL pour vous permettre de démarrer rapidement.
Dans le répertoire des exemples, nous voyons trois fichiers de configuration avec les propriétés du nœud - le nom indique la nature du nœud dans un certain schéma.
corp-000.properties
store-001.properties
store-002.propertiesSymmetricDS dispose de tous les fichiers de configuration nécessaires pour une conception de base à 3 nœuds (option 1), et les mêmes fichiers peuvent être utilisés pour une conception à 2 nœuds (option 2). Copiez le fichier de configuration requis du répertoire d'exemples vers les moteurs sur l'hôte vm1. Cela se passe comme ceci :
$> 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=000Ce nœud dans la configuration 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 ci-dessus et les informations de connexion. Nous nous connectons à la base de données replica_db et les tables seront créées lors de la création du schéma. sync.url indique où contacter le nœud pour la synchronisation.
Le nœud 2 sur l'hôte vm2 est configuré comme store-001 et le reste est spécifié dans le fichier node.properties ci-dessous. Le nœud store-001 exécute la base de données PostgreSQL et pgdb_replica est la base de données de réplication. Registration.url permet à l'hôte vm2 de contacter l'hôte vm1 et d'en recevoir 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=001L'exemple SymmetricDS terminé contient des paramètres permettant de configurer la réplication bidirectionnelle entre deux serveurs de base de données (deux nœuds). Les étapes ci-dessous sont effectué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 répertoires dans lesquelles les règles et la direction de réplication entre les nœuds seront stockées. Enfin, des exemples de données sont chargés dans les tableaux.
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.sqlDans l'exemple, les tables item et item_writing_price sont automatiquement configurées pour être répliquées du corp-000 au store-001, et les tables de vente (sale_transaction et sale_return_line_item) sont automatiquement configurées pour être répliquées du store-001 au corp-000. Nous créons maintenant un schéma dans la base de données PostgreSQL sur l'hôte vm2 (store-001) pour le préparer à recevoir les données de corp-000.
vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> ./dbimport --engine store-001 --format XML create_sample.xmlAssurez-vous de vérifier que la base de données MySQL sur vm1 contient des exemples de tables et des tables de catalogue SymmetricDS. Notez que les tables système SymmetricDS (préfixées par sym_) ne sont actuellement disponibles que sur le nœud corp-000 car c'est là que nous avons exécuté la commande create-sym-tables et gérerons la réplication. Et dans la base de données sur le nœud store-001, il n'y aura que 4 exemples de tables sans données.
Tous. L'environnement est prêt à exécuter 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 envoyées vers un fichier journal en arrière-plan (symétrique.log) dans le dossier des journaux du répertoire où SymmetricDS est installé, ainsi que vers 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 &Si vous exécutez le processus du serveur sym sur l'hôte vm2, il créera également des tables de catalogue SymmetricDS dans la base de données PostgreSQL. Si vous exécutez le processus du serveur sym sur les deux nœuds, ils se coordonnent pour répliquer les données de corp-000 vers store-001. Si après quelques secondes nous interrogeons les 4 tables des deux côtés, nous verrons que la réplication a réussi. Ou vous pouvez envoyer le bootstrap au nœud store-001 à partir de 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 des éléments de la base de données MySQL sur le nœud corp-000 (hôte : vm1), et vous pouvez vérifier sa réplication dans la base de données PostgreSQL sur le nœud store-001 (hôte : vm2). 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 les données du store-001 vers corp-000, nous insérons un enregistrement dans la table sale_transaction et vérifions que la réplication est réussie.
Nous voyons la configuration réussie de la réplication bidirectionnelle des exemples de tables entre les bases de données MySQL et PostgreSQL. Pour configurer la réplication pour les nouvelles tables utilisateur, procédez comme suit : Nous créons par exemple la table t1 et configurons ses règles de réplication comme suit. De cette façon, 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 est ensuite informée du changement de schéma, c'est-à-dire de l'ajout d'une nouvelle table, à l'aide de la commande symadmin avec l'argument sync-triggers, qui recrée les déclencheurs pour mapper les définitions de table. send-schema est exécuté pour envoyer les modifications de 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 t1Avantages de SymmetricDS
Installation et configuration faciles, comprenant un ensemble de fichiers prêts à l'emploi avec des paramètres permettant de créer un circuit à trois ou deux nœuds.
Bases de données multiplateformes et indépendance des plateformes, y compris les serveurs, les ordinateurs portables et les appareils mobiles.
Répliquez n'importe quelle base de données sur n'importe quelle autre base de données localement, sur le WAN ou dans le cloud.
Possibilité de travail optimal avec quelques bases de données ou plusieurs milliers pour une réplication pratique.
Version payante avec interface graphique et excellent support.
Inconvénients de SymmetricDS
Vous devez définir manuellement les règles et la direction de réplication sur la ligne de commande via des instructions SQL pour charger les tables de catalogue, ce qui peut s'avérer gênant.
La configuration de nombreuses tables pour la réplication peut s'avérer fastidieuse, sauf si vous utilisez des scripts pour créer des instructions SQL définissant les règles et la direction de la réplication.
Il y a trop d'informations enregistrées dans les journaux et vous devez parfois ranger le fichier journal afin qu'il ne prenne pas trop de place.
Résultats pour SymmetricDS
SymmetricDS vous permet de mettre en place une réplication bidirectionnelle entre deux, trois voire plusieurs milliers de nœuds pour répliquer et synchroniser des fichiers. Il s'agit d'un outil unique qui effectue de manière indépendante de nombreuses tâches, telles que la récupération automatique des données après une longue période d'indisponibilité sur un nœud, l'échange de données sécurisé et efficace entre les nœuds via HTTPS, la gestion automatique des conflits basée sur un ensemble de règles, etc. SymmetricDS effectue la réplication entre n'importe quelle base de données peut donc être utilisée pour une grande variété de scénarios, notamment la migration, la migration, la distribution, le filtrage et la transformation des données entre plates-formes.
L'exemple est basé sur le fonctionnaire par SymmetricDS. DANS Décrit en détail les différents concepts impliqués dans la configuration de la réplication avec SymmetricDS.
Source: habr.com