DBVisit Replicate est un outil qui, comme son nom l’indique, permet de répliquer des données d’une base de données source vers une base de données cible. Il offre une alternative moins onéreuse que Oracle Goldengate.
Jusqu’à la version actuelle (2.9), la base de données source est obligatoirement une base Oracle, Standard Edition ou Enterprise Edition, à partir de la version 9iR2, jusqu’à la version 12cR2. Le produit supporte les instances Standalone et RAC (éditions DBVisit Replicate XTD et MAX).
Comme dans tout outil de réplication de données, certaines contraintes existent, notamment au niveau des types de données supportés. DBVisit fournit des scripts permettant de s’assurer de la compatibilité de vos données sources.
La base de données cible peut être sous MySQL, PostgreSQL, Microsoft SQL Server, Tibero, Google Cloud SQL, Hadoop, CSV ou Kafka.
DBVisit Replicate peut s’installer sous Linux (i386/x86_64), mais également sous Windows (i386/x86_64), IBM AIX, Sun Solaris ou HP-UX.
Trois éditions sont commercialisées :
- LTD : limitée à la réplication de 200 tables ;
- XTD : permettant de répliquer jusqu’à 2000 tables, offrant plus de fonctionnalités (support du RAC entre autres) et plus de types de données (LOB)) ;
- MAX : non limitée en nombre de tables et avec des fonctionnalités avancées (Two-way-replication, …).
Principe de fonctionnement de DBVisit Replicate
Le processus de réplication s’établit en 3 phases :
- le process « MINE » extrait les instructions DML des redo log de la base de données source et les retranscrit dans des fichiers « PLOG » ;
- les fichiers PLOG sont transmis via le réseau sur la machine cible ;
- les instructions contenues dans les fichiers PLOG sont alors appliquées par le process « APPLY » sur la base de données cible.
Contexte client
Le besoin d’un de nos clients était de pouvoir déporter les requêtes de type BI d’une base de données transactionnelle vers une base de données répliquée en temps réel. La volumétrie est d’environ 3To avec moins de 2000 tables. L’édition XTD a donc été choisie avec Oracle 11gR2 Entreprise Edition en source, et Oracle 11gR2 Standard Edition en cible.
Installation du produit
Sous Linux l’installation est triviale. Il suffit d’installer un RPM dans l’environnement source et dans l’environnement cible avec le compte root :
[root@source]$ rpm -ivh dbvisit_replicate-2.9.04-1.x86_64.rpm Preparing... ########################################### [100%] 1:dbvisit_replicate ########################################### [100%] [root@source]$
[root@cible]$ rpm -ivh dbvisit_replicate-2.9.04-1.x86_64.rpm Preparing... ########################################### [100%] 1:dbvisit_replicate ########################################### [100%] [root@cible]$
Créer un filesystem dédié sur le serveur source et le serveur cible pour stocker les fichiers créés par DBVisit, les plus volumineux étant les PLOG. Les fichiers sont automatiquement compressés et purgés par DBVisit mais il est conseillé d’avoir un espace de stockage d’une journée de production.
[root@source]# df -hP | grep dbvisit /dev/mapper/vg_root-lv_dbv_src1 50G 63M 49G 1% /u02/app/dbvisit [root@source]#
[root@cible]# df -hP | grep dbvisit /dev/mapper/vg_root-lv_dbv_cib1 50G 63M 49G 1% /u02/app/dbvisit [root@cible]#
A partir de maintenant, toutes les actions seront faites avec un compte système différent de root et ayant suffisamment de droits pour se connecter à une base de données Oracle.
Initialisation de la base de données cible
La base cible doit être créée et les données synchronisées avec la base de données source. Chaque contexte est différent et DBVisit Replicate nous donne le choix pour effectuer cette première synchronisation.
Si les données à répliquer représentent une petite partie de la base, Datapump sera adapté. Si au contraire les données représentent la quasi-totalité de la base, RMAN sera la solution à retenir avec sa fonction « duplicate ».
Dans notre contexte, les tables répliquées représentent 90% de la volumétrie sur les 3To de la base. Avec Oracle Database 11gR2, RMAN avec la fonctionnalité « duplicate from active database » a été choisi.
Paramétrage de DBVisit Replicate
Après l’initialisation de la base cible, vous devrez désactiver les triggers et les contraintes de clés étrangères sur la cible. Les triggers joués sur la base source ne doivent pas être rejoués sur la cible, la réplication étant faite de table à table entre la source et la cible.
Le paramétrage de la réplication peut maintenant être fait avec le « wizard » de DBVisit Replicate. Il peut être utilisé soit en mode interactif, soit avec un fichier de réponse préalablement créé. C’est la seconde solution qui est utilisée ici avec le fichier de réponse ci-dessous :
Version of response file: 2.9.00 accept_license: yes DDC_NAME: dbvatlg LICENSE_KEY: XXXXX-XXXXX-XXXXX-XXXXX-XXXXX-XXXXX-XXXXX SETUP_SCRIPT_PATH: /u02/app/dbvisit/dbvatlg TNS_ADMIN: /u01/app/oracle/product/11.2.0/dbhome_1/network/admin ###Step 1 store_passwords: YES rdbms: Oracle TNS_alias: SOURCE sysuser: SYS syspassword: ******** systemuser: SYSTEM systempassword: ******** dbvuser: dbvrep dbvpassword: ******** tablespace: USERS temp_tablespace: TEMP database#: add rdbms: Oracle TNS_alias: CIBLE sysuser: SYS syspassword: ******** systemuser: SYSTEM systempassword: ******** dbvuser: dbvrep dbvpassword: ******** tablespace: USERS temp_tablespace: TEMP database#: done ###Step 2 source db: 1 target db: 2 enable_ddl: Yes use_fetcher: No suplog_all: Yes encrypt_network: No compress_network: No network_timeout: 60 prepare_type: resetlogs instantiate_type: none pair#: done ###Step 3 pair#: 1 tables_and_schemas: APPLI1 APPLI2.TAB1 APPLI2.TAB2 add_more: No plsql_schemas: APPLI1 APPLI2 add_more: No rename_or_filter: No pair#: done ###Step 4 process#: 1 hostname: source OS: Linux email_notify: No snmp_notify: No SETUP_SCRIPT_PATH: /u02/app/dbvisit/dbvatlg change: No process#: 2 hostname: cible OS: Linux email_notify: No snmp_notify: No SETUP_SCRIPT_PATH: /u02/app/dbvisit/dbvatlg change: No process#: done
Informations concernant les paragraphes :
- En en-tête : DDC_NAME est le nom de notre réplication. Ici nous l’appelons dbvatlg. Nous retrouverons ce nom dans les fichiers de configuration générés. Nous avons aussi le numéro de licence et le répertoire de travail de la réplication.
- Step 1 : informations concernant les 2 bases de données impliquées dans la réplication.
- Step 2 : sens de réplication et mode de préparation de la cible. Ici « resetlogs » car nous avons choisi une duplication avec RMAN.
- Step 3 : les schémas et tables que nous allons répliquer. Dans cet exemple, le schéma APPLI1 (toutes ses tables), et les tables TABLE1 et TABLE2 du schéma APPLI2. plsql_schemas indique que les procédures, fonctions, packages sont également répliqués.
- Step 4 : il concerne les notifications que DBVisit Replicate peut envoyer par mail ou via des trappes SNMP. Ici nous ne les configurons pas, le client utilise ses propres supervisions.
La configuration peut être faite en lançant la commande ci-dessous :
$ /usr/dbvisit/replicate/dbvrep setup wizard respfile /u02/app/dbvisit/dbvatlg/dbvatlg-response_file.txt
Le wizard crée tous les fichiers de configuration et les scripts shell ci-dessous qui vont nous permettre de finaliser la configuration et lancer la réplication.
[oracle@source dbvatlg] $ ll total 312904 drwxr-xr-x 2 oracle oinstall 4096 Jan 29 17:59 config -rw-r--r-- 1 oracle oinstall 34634 Feb 1 23:18 dbvatlg-all.log -rwxr----- 1 oracle oinstall 2792 Feb 1 23:13 dbvatlg-all.sh -rw-r----- 1 oracle oinstall 754 Feb 1 23:15 dbvatlg-APPLY.ddc -rw-r----- 1 oracle oinstall 705 Feb 1 23:16 dbvatlg-MINE.ddc -rwxr----- 1 oracle oinstall 117 Feb 1 23:13 dbvatlg-run-cible.sh -rwxr----- 1 oracle oinstall 115 Feb 1 23:13 dbvatlg-run-source.sh drwxr-xr-x 2 oracle oinstall 4096 Feb 6 18:15 ddc_backup drwxr-xr-x 3 oracle oinstall 4096 Feb 8 16:10 log drwxr-xr-x 2 oracle oinstall 20480 Feb 8 17:26 mine -rw-r----- 1 oracle oinstall 1318 Feb 1 23:13 Nextsteps.txt drwxr-xr-x 2 oracle oinstall 4096 Dec 28 13:58 scripts -rwxr-x--- 1 oracle oinstall 87 Feb 1 23:13 start-console.sh [oracle@source dbvatlg] $ ll config total 108 -rw-r----- 1 oracle oinstall 2313 Feb 1 23:13 dbvatlg-dbsetup_CIBLE_dbvrep.sql -rw-r----- 1 oracle oinstall 2056 Feb 1 23:13 dbvatlg-dbsetup_SOURCE_dbvrep.sql -rw-r----- 1 oracle oinstall 35610 Feb 1 23:13 dbvatlg-grants_CIBLE_dbvrep.sql -rw-r----- 1 oracle oinstall 17192 Feb 1 23:13 dbvatlg-grants_SOURCE_dbvrep.sql -rw-r----- 1 oracle oinstall 3346 Feb 1 23:13 dbvatlg-onetime.ddc -rw-r----- 1 oracle oinstall 17420 Feb 1 23:13 dbvatlg-setup.dbvrep -rw-r----- 1 oracle oinstall 895 Feb 1 23:13 dbvatlg-wizard-databases.cfg -rw-r----- 1 oracle oinstall 2079 Feb 1 23:13 dbvatlg-wizard-ddc.cfg -rw-r----- 1 oracle oinstall 258 Feb 1 23:13 dbvatlg-wizard-pairs.cfg -rw-r----- 1 oracle oinstall 7390 Feb 1 23:13 dbvatlg-wizard-tables.cfg [oracle@source dbvatlg] $ ll scripts total 40 -rwxr----- 1 oracle oinstall 1317 Feb 1 23:13 dbvatlg-cible-dbvrep-APPLY.sh -rwxr----- 1 oracle oinstall 316 Feb 1 23:13 dbvatlg-cible-start-APPLY.sh -rwxr----- 1 oracle oinstall 129 Feb 1 23:13 dbvatlg-cible-stop-APPLY.sh -rwxr----- 1 oracle oinstall 1320 Feb 1 23:13 dbvatlg-source-dbvrep-MINE.sh -rwxr----- 1 oracle oinstall 312 Feb 1 23:13 dbvatlg-source-start-MINE.sh -rwxr----- 1 oracle oinstall 127 Feb 1 23:13 dbvatlg-source-stop-MINE.sh -rw-rw-r-- 1 oracle oinstall 624 Feb 1 23:13 systemd-dbvrep-APPLY_dbvatlg.service -rw-rw-r-- 1 oracle oinstall 617 Feb 1 23:13 systemd-dbvrep-MINE_dbvatlg.service -rw-rw-r-- 1 oracle oinstall 870 Feb 1 23:13 upstart-dbvrep-APPLY_dbvatlg.conf -rw-rw-r-- 1 oracle oinstall 857 Feb 1 23:13 upstart-dbvrep-MINE_dbvatlg.conf [oracle@source dbvatlg] $
Initialisation de la réplication
C’est l’étape cruciale ! Elle doit être réalisée lors d’une faible activité car DBVisit Replicate pose un lock sur chaque table une à une afin d’avoir une cohérence des données.
Cette étape peut être longue (en fonction du nombre de tables à répliquer et de leur volumétrie), du fait que DBVisit Replicate active « supplemental logging » sur chaque table répliquée. Si « supplemental logging » est déjà actif, cette étape est rapide.
Lancement de l’initialisation à partir du serveur source :
$ /u02/app/dbvisit/dbvatlg/dbvatlg-all.sh
A la fin de l’exécution du script, le fichier /u02/app/dbvisit/dbvatlg/Nextsteps.txt s’affiche. Il répertorie les dernières étapes pour que la réplication soit fonctionnelle :
These steps are required after the dbvatlg-all.sh script runs: 1) Create the necessary directory(ies) on the servers: cible: /u02/app/dbvisit/dbvatlg 2) Copy the DDC files to the server(s) where the processes will run: cible: /u02/app/dbvisit/dbvatlg/dbvatlg-APPLY.ddc source: /u02/app/dbvisit/dbvatlg/dbvatlg-MINE.ddc 3) Review that path to dbvrep executable is correct in the run scripts: /u02/app/dbvisit/dbvatlg/dbvatlg-run-cible.sh /u02/app/dbvisit/dbvatlg/dbvatlg-run-source.sh 4) Copy the run script to the server(s) where the processes will run: cible: /u02/app/dbvisit/dbvatlg/dbvatlg-run-cible.sh source: /u02/app/dbvisit/dbvatlg/dbvatlg-run-source.sh 5) Ensure firewall is open for listen interfaces 0.0.0.0:7902, 0.0.0.0:7901 used by the processes. 6) Make sure the data on apply are in sync as of time when setup was run. 7) Start the replication processes on all servers: cible: /u02/app/dbvisit/dbvatlg/dbvatlg-run-cible.sh source: /u02/app/dbvisit/dbvatlg/dbvatlg-run-source.sh 8) Start the console to monitor the progress: /u02/app/dbvisit/dbvatlg/start-console.sh
Une fois les contrôles effectués et les fichiers copiés sur la machine cible (étapes 1 à 6), les process de réplication MINE et APPLY peuvent être lancés sur la cible…
$ /u02/app/dbvisit/dbvatlg/dbvatlg-run-cible.sh
… puis sur la source :
$ /u02/app/dbvisit/dbvatlg/dbvatlg-run-source.sh
A partir du serveur source, vous pouvez maintenant lancer la console pour contrôler l’état de la réplication :
/u02/app/dbvisit/dbvatlg/start-console.sh
L’écran suivant s’affiche, il se met à jour en temps réel :
Copyright (C) Dbvisit Software Limited. All rights reserved. / Dbvisit Replicate 2.9.04(XTD edition) - Fully Licensed MINE is running. Currently at plog 87844 and SCN 53173366424 (02/09/2018 08:48:27). APPLY is running. Currently at plog 87844 and SCN 53173366417 (02/09/2018 08:48:27). Progress of replication dbvatlg:MINE->APPLY: total/this execution ---------------------------------------------------------------------------------------------------------- APPLI1.CDE: 100% Mine:12/12 Unrecov:0/0 Applied:12/12 Conflicts:0/0 Last:09/02/2018 08:48:23/OK APPLI1.CDL: 100% Mine:221/221 Unrecov:0/0 Applied:221/221 Conflicts:0/0 Last:09/02/2018 08:48:23/OK APPLI1.CDR: 100% Mine:54/54 Unrecov:0/0 Applied:54/54 Conflicts:0/0 Last:09/02/2018 08:47:45/OK APPLI1.ART: 100% Mine:3/3 Unrecov:0/0 Applied:3/3 Conflicts:0/0 Last:09/02/2018 08:48:21/OK APPLI2.TAB1: 100% Mine:1/1 Unrecov:0/0 Applied:1/1 Conflicts:0/0 Last:09/02/2018 08:48:03/OK APPLI2.TAB2: 100% Mine:3/3 Unrecov:0/0 Applied:3/3 Conflicts:0/0 Last:09/02/2018 08:47:45/OK
Les tables sont synchronisées. Nous pouvons voir que les process MINE et APPLY sont en état « running », et qu’ils sont bien synchrones (SCN et date).
La console permet de réaliser également plusieurs actions parmi lesquelles, l’arrêt et la mise en pause de la réplication, la gestion de conflits et la modification de paramètres. Il est également possible d’ajouter des tables ou schémas à une réplication.
Easyteam et DBVisit sont partenaires. N’hésitez pas à nous contacter pour vos projets DBVisit Replicate.
