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 ces deux serveurs de base de données. En règle générale, les bases de données de réplication croisée sont appelées homogènes, et il s'agit d'une méthode pratique pour passer d'un serveur de bases de données relationnelles à un autre.
Les bases de données PostgreSQL et MySQL sont considérées comme relationnelles, mais avec des extensions supplémentaires, elles offrent des fonctionnalités NoSQL. Ici, nous allons discuter de la réplication entre PostgreSQL et MySQL, en termes de SGBD relationnel.
Nous ne décrirons pas toute la cuisine intérieure, seulement les principes de base, afin que vous ayez une idée de la façon de configurer la réplication entre les serveurs de base de données, les avantages, les limitations et les scénarios d'utilisation.
En règle générale, la réplication entre deux serveurs de base de données identiques est effectuée soit en mode binaire, soit par le biais de requêtes entre le nœud maître (c'est l'éditeur, maître ou actif) et l'esclave (abonné, en attente 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 n'est effectuée que dans un sens. Mais vous pouvez configurer la réplication entre deux bases de données dans les deux sens, de sorte que les données soient transférées de l'esclave au maître dans la configuration active-active. Tout cela, y compris la réplication en cascade, éventuellement entre deux serveurs de base de données identiques ou plus. La configuration active-active ou active-passive dépend du besoin, de la disponibilité de ces fonctionnalités dans la configuration initiale ou de l'utilisation de solutions de configuration externes et de compromis existants. .
La configuration décrite est possible entre différents serveurs de base de données. Le serveur peut être configuré pour recevoir des données répliquées d'un autre serveur de base de données et toujours enregistrer des instantanés en temps réel des données répliquées. MySQL et PostgreSQL proposent la plupart de ces configurations seules ou avec des extensions tierces, y compris des méthodes de journal binaire, des verrous de disque et des méthodes basées sur des instructions et des chaînes.
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, elles ne peuvent donc pas être connectées 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 chaîne sont extraites des tables MySQL et stockées en tant qu'objets JSONB dans la base de données PostgreSQL, puis déchiffrées par la fonction pl / pgsql et lues dans la base de données PostgreSQL.
Fonctionnalités de Pg_chameleon
Plusieurs schémas MySQL du même cluster peuvent être répliqués vers la même base de données cible PostgreSQL avec une configuration un-à-plusieurs
Les noms des schémas source et cible ne peuvent pas correspondre.
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 se répliquer ou générer des erreurs sont exclues.
Chaque fonction de réplication est contrôlée par des démons.
Contrôle à l'aide de paramètres et de fichiers de configuration basés sur YAML.
Exemple
Pour commencer, préparez tous les composants nécessaires à l'installation de pg_chameleon. Dans cet exemple, Python 3.6.8 est installé, ce qui crée un environnement virtuel et l'active.
$> 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 avoir correctement installé Python3.6, vous devez remplir les autres conditions requises, par exemple, créer et activer un environnement virtuel. De plus, le module pip est mis à jour vers la dernière version et est utilisé pour installer pg_chameleon. Dans les commandes ci-dessous, pg_chameleon 2.0.9 est intentionnellement installé, bien que la dernière version soit 2.0.10. Ceci est nécessaire pour éviter de nouveaux bogues 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 appelons pg_chameleon (caméléon 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.yml
Nous 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 présenté 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 avec pg_chameleon avec des modifications mineures en fonction des environnements source et cible, et ce qui suit est 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 où vous pouvez contrôler des paramètres tels que l'emplacement du fichier de verrouillage, l'emplacement des journaux, la période de stockage des journaux, etc. La section suivante est la section de remplacement de type, où l'ensemble est spécifié règles pour remplacer les types lors de la réplication. L'exemple par défaut utilise une règle de redéfinition de type qui convertit tinyint (1) en valeur booléenne. Dans la section suivante, nous indiquons les détails de la connexion à la base de données cible. Dans notre cas, il s'agit d'une base de données PostgreSQL désignée comme 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 des bases de données source et cible, les tables à ignorer, le délai d'expiration, la mémoire et la taille du paquet. Notez que «sources» est indiqué au pluriel, c'est-à-dire que nous pouvons ajouter plusieurs bases de données source pour la même cible pour configurer la configuration plusieurs-à-un.
La base de données world_x de l'exemple contient 4 tables avec des lignes que la communauté MySQL propose pour l'exemple. Il peut être téléchargé ici . La base de données exemple se présente sous la forme de tar et d'une archive compressée avec des instructions pour créer et importer des chaînes.
Un utilisateur spécial est créé dans les bases de données MySQL et PostgreSQL avec le même nom usr_replica. Dans MySQL, il dispose de 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;
Côté PostgreSQL, la base de données db_replica est créée, qui acceptera les modifications de la base de données MySQL. L'utilisateur usr_replica de PostgreSQL est automatiquement configuré en tant que propriétaire de deux schémas pgworld_x et sch_chameleon qui contiennent des tables répliquées réelles et des tables avec des répertoires de réplication respectivement. 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 DATABASE
La base de données MySQL est configurée avec quelques modifications 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 = 1
Maintenant, il est 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_x
Sur le nœud MySQL:
$> psql -p 5433 -U usr_replica -h 192.168.56.106 db_replica
Les trois commandes pg_chameleon (caméléon) suivantes 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à dit. L'argument add_source ajoute la base de données d'origine à 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 --debug
La sortie de ces trois commandes indique évidemment leur exécution réussie. Tous les plantages ou erreurs de syntaxe sont indiqués dans des messages simples et clairs avec des conseils de dépannage.
Enfin, démarrez la réplication avec start_replica et obtenez un message de réussite.
$> chameleon start_replica --config default --source mysql output: Starting the replica process for source mysql
L'état de la réplication peut être demandé à l'aide de l'argument show_status et les erreurs peuvent être affichées à l'aide de l'argument show_errors.
Résultat.
Comme nous l'avons dit précédemment, chaque fonction de réplication est contrôlée par des démons. Pour les visualiser, nous interrogeons la table de 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 illustré 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 | two
Si nous effectuons la migration, les commandes pg_chameleon suivantes seront sa fin. Les commandes doivent être exécutées après avoir vérifié 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érence à la base de données ou au schéma de réplication d'origine (sch_chameleon).
$> chameleon stop_replica --config default --source mysql $> chameleon detach_replica --config default --source mysql --debug
Si vous le souhaitez, les commandes suivantes peuvent supprimer le schéma de configuration et de réplication d'origine.
$> chameleon drop_source --config default --source mysql --debug $> chameleon drop_replica_schema --config default --source mysql --debug
Avantages de pg_chameleon
Installation et configuration faciles.
Dépannage et détection d'anomalies pratiques avec des messages d'erreur clairs.
Vous pouvez ajouter des tables spéciales supplémentaires à la réplication après l'initialisation sans modifier le reste de la configuration.
Vous pouvez configurer plusieurs bases de données source pour une cible, ce qui est très pratique si vous combinez des données d'une ou plusieurs bases de données MySQL dans une base de données PostgreSQL.
Vous ne pouvez pas répliquer les tables sélectionnées.
Inconvénients de pg_chameleon
Pris en charge 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 dans le processus init_replica, mais pas répliquées.
Réplication unidirectionnelle - uniquement de MySQL vers PostgreSQL. Par conséquent, il ne convient que pour le schéma actif-passif.
Seule la base de données MySQL peut être la source, et la prise en charge de la base de données PostgreSQL car la source est uniquement expérimentale et avec des limitations (en savoir plus ici )
Résultats 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. Un inconvénient majeur est que la réplication n'est qu'à sens unique, il est donc peu probable que les experts en 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 par un autre outil open source - SymmetricDS.
En savoir plus dans la documentation officielle ici . Vous trouverez de l'aide sur la ligne de commande ici .
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 base de données cloud, par exemple Redshift et Azure, etc. Fonctions disponibles: synchronisation des bases de données et des fichiers, réplication de plusieurs bases de données de premier plan, synchronisation filtrée, conversion et autres. Il s'agit d'un outil Java et nécessite une version standard de JRE ou JDK (version 8.0 ou supérieure). Ici, vous pouvez enregistrer les modifications de données sur les déclencheurs dans la base de données source et les envoyer à la base de données cible correspondante sous forme de paquets.
Fonctionnalités de SymmetricDS
L'outil est indépendant de la plate-forme, c'est-à-dire que deux bases de données différentes ou plus peuvent échanger des données.
Les bases de données relationnelles sont synchronisées en écrivant les modifications de données et les bases de données basées sur le système de fichiers utilisent la synchronisation des fichiers.
Réplication bidirectionnelle à l'aide des méthodes Push et Pull basées sur un ensemble de règles.
La transmission de données est possible sur des réseaux sécurisés et des réseaux à faible bande passante.
Récupération automatique lorsque les nœuds reprennent après une panne et résolution automatique des conflits.
API d'extension compatibles et puissantes dans le cloud.
Exemple
SymmetricDS peut être configuré de deux manières:
Un nœud maître (parent) qui coordonne de manière centrale la réplication des données entre deux nœuds esclaves (enfants) et l'échange de données entre les nœuds enfants est effectué uniquement via le parent.
Le 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, les données sont échangées via Push and Pull. Dans cet exemple, nous allons examiner la configuration active-active. Décrivez l'architecture entière trop longtemps, alors consultez le guide pour en savoir plus sur SymmetricDS.
L'installation de SymmetricDS est très simple: téléchargez ici la version open source du fichier zip et extrayez-la 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 les versions de base de données, les versions Linux, les adresses IP et les ports pour les deux nœuds.
Ici, nous installons SymmetricDS dans /usr/local/symmetric-server-3.9.20, et différents sous-répertoires et fichiers seront stockés là. Nous nous intéressons aux exemples de répertoires imbriqués et aux moteurs. Le répertoire d'exemples contient des exemples de fichiers de configuration avec des propriétés d'hôte, ainsi que des exemples de scripts SQL pour démarrer rapidement la démonstration.
Dans le répertoire des exemples, nous voyons trois fichiers de configuration avec les propriétés du nœud - le nom montre la nature du nœud dans un schéma particulier.
corp-000.properties store-001.properties store-002.properties
SymmetricDS possède tous les fichiers de configuration nécessaires pour un diagramme de base à 3 nœuds (option 1), et les mêmes fichiers peuvent être utilisés pour un diagramme à 2 nœuds (option 2). Copiez le fichier de configuration souhaité depuis le répertoire des exemples vers les moteurs de l'hôte vm1. Il se présente 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=000
Ce nœud dans la configuration SymmetricDS est appelé corp-000 et la connexion à la base de données est traitée par le pilote mysql jdbc, qui utilise la chaîne de connexion spécifiée ci-dessus et les informations de connexion. Nous nous connectons à la base de données replica_db et des tables seront créées lors de la création du schéma. sync.url affiche le site de communication avec le nœud pour la synchronisation.
Le noeud 2 sur l'hôte vm2 est configuré en tant que magasin-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 pour la réplication. registration.url permet à l'hôte vm2 de contacter l'hôte vm1 et d'en 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 préconfiguré de SymmetricDS contient des options pour 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), ce 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épertoire où 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 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 automatiquement configurées pour la réplication de corp-000 vers store-001, et les tables de vente (sale_transaction et sale_return_line_item) sont automatiquement configurées pour la réplication de store-001 vers corp-000. Créez 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 de vérifier que la base de données MySQL sur vm1 contient des exemples de tables et des tables de répertoires SymmetricDS. Notez que les tables système SymmetricDS (avec le préfixe sym_) ne sont désormais disponibles que sur l'hôte corp-000, car là, nous avons exécuté la commande create-sym-tables et gérons 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.
C’est tout. L'environnement est prêt à exécuter des processus de serveur sym sur les deux nœuds, comme illustré ci-dessous.
vm1$> cd /usr/local/symmetric-server-3.9.20/bin vm1$> sym 2>&1 &
Les entrées de journal sont envoyées au fichier journal d'arrière-plan (symmetric.log) dans le dossier journal du répertoire où SymmetricDS est installé, 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 &
Si vous exécutez le processus du serveur sym sur l'hôte vm2, il créera également les 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 est réussie. Ou vous pouvez envoyer le bootstrap vers 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 l'hôte corp-000 (hôte: vm1), et vous pouvez vérifier sa réplication dans la base de données PostgreSQL sur l'hôte magasin-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 des données de store-001 vers corp-000, insérez un enregistrement dans la table sale_transaction et vérifiez que la réplication est terminée.
Résultat.
Nous constatons une configuration réussie de la réplication bidirectionnelle d'exemples de tables entre les bases de données MySQL et PostgreSQL. Pour configurer la réplication pour les nouvelles tables d'utilisateurs, procédez comme suit: Nous créons la table t1 à titre d'exemple et configurons les règles pour sa réplication comme suit. Nous configurons donc 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)
Ensuite, la configuration est notifiée de la modification du 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 correspondre aux 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 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 faciles, y compris un ensemble de fichiers prêts à l'emploi avec des paramètres pour créer un circuit à trois ou deux nœuds.
Bases de données multiplateformes et indépendance des plates-formes, y compris les serveurs, les ordinateurs portables et les appareils mobiles.
Répliquez n'importe quelle base de données vers n'importe quelle autre base de données localement, dans un WAN ou dans le cloud.
La capacité de travailler de manière optimale avec quelques bases de données ou plusieurs milliers pour une réplication facile.
Version payante avec une interface graphique et un excellent support.
Inconvénients de SymmetricDS
Il est nécessaire de déterminer manuellement les règles et le sens de la réplication via les instructions SQL sur la ligne de commande pour charger les tables de répertoire, ce qui n'est pas pratique.
La configuration de nombreuses tables pour la réplication peut être fastidieuse si vous n'utilisez pas de scripts pour créer des instructions SQL qui définissent les règles et la direction de la réplication.
Trop d'informations sont entrées dans les journaux, et parfois vous devez nettoyer le fichier journal afin qu'il ne prenne pas trop de place.
Résumé SymmetricDS
SymmetricDS vous permet de configurer la réplication bidirectionnelle entre deux, trois, voire plusieurs milliers de nœuds pour répliquer et synchroniser les fichiers. Il s'agit d'un outil unique qui effectue indépendamment de nombreuses tâches, par exemple, la récupération automatique des données après un long temps d'arrêt sur un nœud, l'échange sécurisé et efficace de données entre les nœuds via HTTPS, la gestion automatique des conflits basée sur un ensemble de règles, etc. SymmetricDS se réplique entre toutes les bases de données, par conséquent, il peut être utilisé pour une variété de scénarios, y compris la migration, la mise à niveau, la distribution, le filtrage et la conversion de données entre plates-formes.
L'échantillon est basé sur le Guide de démarrage rapide SymmetricDS officiel. Le guide de l'utilisateur détaille divers concepts liés à la configuration de la réplication à l'aide de SymmetricDS.