Remarques :

Ce tutoriel nécessite un accès à Oracle Cloud. Pour vous inscrire à un compte gratuit, reportez-vous à Introduction à Oracle Cloud Infrastructure Free Tier.
Il utilise des exemples de valeurs pour les informations d'identification, la location et les compartiments Oracle Cloud Infrastructure. Lorsque vous terminez votre atelier, remplacez ces valeurs par celles propres à votre environnement cloud.

Configuration de la réplication bidirectionnelle entre deux instances gérées MySQL Oracle Heatwave à l'aide d'OCI GoldenGate

Introduction

Oracle Cloud Infrastructure GoldenGate (OCI GoldenGate) est un service entièrement géré qui aide les ingénieurs données à déplacer des données en temps réel, à grande échelle, à partir de systèmes de gestion des données vers des bases de données OCI. Concevez, exécutez, orchestrez et surveillez les tâches de réplication de données dans une interface unique sans avoir à allouer ou gérer des environnements de calcul. OCI GoldenGate prend en charge plusieurs sources et cibles, notamment MySQL et le service de base de données Oracle HeatWave MySQL.

Dans ce tutoriel, nous vous expliquerons comment configurer la réplication bidirectionnelle à l'aide d'OCI GoldenGate entre deux instances Oracle HeatWave MySQL dans OCI.

Objectifs

Configurez une réplication bidirectionnelle entre deux instances gérées Oracle HeatWave MySQL à l'aide d'OCI GoldenGate dans OCI.

Prérequis

Les instances Oracle HeatWave MySQL source et cible doivent utiliser le moteur InnoDB et être exécutées sur les versions 5.7 ou 8.*.
Pour la réplication bidirectionnelle, il est recommandé d'utiliser la même version de l'instance MySQL sur la source et la cible.
Le paramètre d'instance binlog_expire_logs_second sur les instances source et cible doit être défini sur au moins 72 heures.
Le paramètre d'instance binlog_row_metadata sur les instances source et cible doit être défini sur Complète pour autoriser la réplication LDD (langage de définition de données).

Remarque : les paramètres d'instance ne peuvent être modifiés qu'en créant une configuration personnalisée. Pour plus d'informations, reportez-vous à la section Création d'une configuration personnalisée pour MySQL.
Consulter les types de données pris en charge. Pour plus d'informations, reportez-vous à MySQL : types de données, objets et opérations pris en charge.
Vérifiez les limites de réplication DDL. Pour plus d'informations, reportez-vous à Utilisation de la réplication DDL.
L'instance cible doit être créée à l'avance à partir de la source à l'aide de l'une des méthodes suivantes :
- Méthode 1 : utilisation d'utilitaires de shell MySQL tels que util.dumpInstance et util.loadDump.
- Méthode 2 : via l'option de sauvegarde et de restauration basée sur la console OCI.
- Méthode 3 : utilisation d'OCI GoldenGate pour l'extraction et la réplication initiales afin d'effectuer le chargement initial des données. Dans ce tutoriel, cette méthode a été utilisée (tâche 7).
Par conception, les instructions LDD de table de signaux d'activité sont ignorées par l'extraction. Vous devez créer la table de pulsations manuellement sur la cible.
Hôte bastion avec le client MySQL installé.
Règles entrantes et listes de sécurité mises à jour pour permettre la communication entre la source, la cible, le bastion et OCI GoldenGate.

Tâche 1 : déploiement d'OCI GoldenGate

Connectez-vous à la console OCI, recherchez GoldenGate, sélectionnez Service GoldenGate et cliquez sur Créer un déploiement.
Entrez les informations ci-après, puis cliquez sur Créer.
- Nom : entrez MySQLggdeployment1.
- Type de déploiement : sélectionnez Réplication de données.
- Sélectionner une technologie : sélectionnez MySQL.
- Sélectionner une version : entrez 21.15.
- Configuration matérielle : entrez # d'OCPU.
- Sélection de sous-réseau : sélectionnez un sous-réseau.
- Type de licence Sélectionnez un type de licence.
- Nom d'instance : entrez GGInstance1.
- Stockage d'informations d'identification : sélectionnez GoldenGate (créez une clé secrète de mot de passe ou sélectionnez une clé secrète existante).

Tâche 2 : créer des utilisateurs dans des instances Oracle HeatWave MySQL

Utilisez l'hôte OCI Bastion pour vous connecter aux instances MySQL source et cible et créer des utilisateurs pour les processus d'extraction et de réplication OCI GoldenGate. Exécutez la requête suivante :

Sur l'instance MySQL source.

> create user 'ggsuser_S'@'%' identified by "<password>";
> grant all privileges on airportdb.* to 'ggsuser_S'@'%' with grant option;
> Grant select,  process, replication slave, replication client on *.* to 'ggsuser_S'@'%';

Sur l'instance MySQL cible.

> create user 'ggsuser_T'@'%' identified by "<password>";
> grant all privileges on airportdb.* to 'ggsuser_T'@'%' with grant option;
> Grant select,  process, replication slave, replication client on *.* to 'ggsuser_T'@'%';

Tâche 3 : configuration des connexions dans le déploiement OCI GoldenGate

Accédez à la page de déploiement OCI GoldenGate et cliquez sur Connexions pour configurer la connexion.
Entrez les informations de connexion.
Répétez les étapes ci-dessus pour ajouter des connexions source et cible.
Sélectionnez Déploiements et cliquez sur Connexions affectées pour affecter les connexions au déploiement.

Tâche 4 : configuration des règles entrantes et des listes de sécurité pour la console OCI GoldenGate

Configurez des règles entrantes et mettez à jour les listes de sécurité pour permettre la communication entre les instances Oracle HeatWave MySQL, le déploiement OCI GoldenGate et le calcul OCI Bastion.

Remarque : si vous utilisez un VPN, vous pouvez ignorer cette étape.

Suivez les étapes répertoriées ici : Option B : utilisation de votre propre bastion sur OCI Compute.
```
ssh -i <private-ssh-key-of-bastion-compute> opc@<bastion-compute-public-ip> -L 443:<GoldenGategate-deployment-hostname>:443 -N
```
Testez les connexions pour les bases de données source et cible dans la console OCI et via la console OCI GoldenGate.
1. Validez les connexions d'instance MySQL dans la console OCI.
2. Validez les mêmes connexions à partir de la console OCI GoldenGate.

Tâche 5 : Créer les processus d'extraction et de réplication

Créez un processus Extract principal (EXT1).
1. Connectez-vous à la console OCI GoldenGate.
2. Accédez à Présentation et cliquez sur + dans la section Extractions.
3. Saisissez les informations d'extraction.
4. Modifiez le fichier de paramètres selon vos besoins. Le fichier de paramètres suivant capture toutes les modifications apportées à la base de données classicmodels, y compris les modifications LDD.
```
EXTRACT ext1
USERIDALIAS  MySQLpoc1, DOMAIN OracleGoldenGate
EXTTRAIL e1
DDL INCLUDE MAPPED
TRANLOGOPTIONS FETCHPARTIALJSON
TABLE classicmodels.*;
```
  Remarque : MySQLpoc1 est une instance source.
5. Démarrez l'extraction et notez l'identifiant global de transaction (GTID) sur la source.
```
MySQL>  select @@gtid_executed, @@gtid_purged\G
*************************** 1. row ***************************
@@gtid_executed: 3b631a96-6aa7-11ef-95c0-02001701769c:1-94    <--- make a note of this GTID
@@gtid_purged: 3b631a96-6aa7-11ef-95c0-02001701769c:1-72
1 row in set (0.00 sec)
MySQL>
```
  Démarrez l'extraction et continuez à l'exécuter tout le temps, même lorsque vous travaillez toujours à configurer la base de données cible pour vous assurer que toutes les modifications sont capturées.
Créez une réplication principale (REP1).
1. Connectez-vous à la console OCI GoldenGate.
2. Accédez à Présentation et cliquez sur + dans la section Réplication.
  
  Remarque : le nom de la table de point de reprise doit être précédé du nom de la base de données/du schéma en minuscules. Si vous ne le faites pas, la création de la table de points de reprise échouera.
  
  Par exemple, classicmodels.OCIGG_CHECKPOINT_REP1.
  
  Il est recommandé de créer une base de données/un schéma dédié distinct (par exemple, schéma ggadmin) pour la table de point de reprise.
```
MySQL> create database ggadmin;
Query OK, 1 row affected (0.01 sec)
MySQL> grant all privileges on ggadmin.* to 'ggsuser_T'@'%' with grant option;
Query OK, 0 rows affected (0.00 sec)
MySQL> grant all privileges on ggadmin.* to 'ggsuser_S'@'%' with grant option;
Query OK, 0 rows affected (0.00 sec)
```
3. Modifiez le fichier de paramètres selon vos besoins. Le fichier de paramètres suivant réplique tous les objets sous la base de données classicmodels avec les modifications LDD.
```
REPLICAT rep1
USERIDALIAS  MySQLpoc2, DOMAIN OracleGoldenGate
DDL INCLUDE MAPPED
MAP classicmodels.*, TARGET classicmodels.*;
```
  Remarque : MySQLpoc2 est une instance cible.
4. Etant donné qu'il s'agit de la réplication principale et qu'elle a été démarrée pour la première fois, elle commencera à s'appliquer à partir du fichier trace 0. Toutefois, si vous souhaitez modifier la réplication pour qu'elle commence à partir d'un GTID particulier, procédez comme suit :
  1. Accédez à la section Réplication dans la console OCI GoldenGate.
  2. Sélectionnez la réplication, cliquez sur Modifier, Modifier, BEGIN, sélectionnez GTID et entrez le GTID.
Jusqu'à présent, nous avons configuré le unidirectionnel pour la réplication DML (Data Manipulation Language) et DDL. Une fois la réplication unidirectionnelle synchronisée, nous pouvons procéder à la réplication bidirectionnelle.
1. Répétez les étapes 5.1 et 5.2, mais cette fois, nous inversons les détails de la source et de la cible. L'instance de base de données source agira désormais en tant qu'instance cible et l'instance cible agira en tant qu'instance source.
  - Source : entrez MySQLpoc2.
  - Cible : entrez MySQLpoc1.
  - Pour ce cas d'emploi, nous avons utilisé une deuxième base de données airportdb. Vous pouvez configurer la réplication bidirectionnelle pour la même base de données.
2. Ajoutez le processus Extract principal (EXT2).
```
EXTRACT ext2
USERIDALIAS  MySQLpoc2, DOMAIN OracleGoldenGate
EXTTRAIL e2
DDL INCLUDE MAPPED
TRANLOGOPTIONS FILTERTABLE ggadmin.OCIGG_CHECKPOINT_REP*  -- from 23ai GG use EXCLUDEFILTERTABLE
TABLE airportdb.*;
```
3. Créez manuellement une table de points de reprise car il s'agit d'une réplication classique. Seules les répliques classiques et coordonnées sont prises en charge pour la réplication bidirectionnelle.
```
For example: ggadmin.OCIGG*CHECKPOINT_REP`- Add primary REPLICAT REP2:` REPLICAT rep2
USERIDALIAS MySQLpoc1, DOMAIN OracleGoldenGate
DDL INCLUDE MAPPED
MAP airportdb.*, TARGET airportdb.\_;
```

Tâche 6 : exécuter des tests DDL et DML

Maintenant que la configuration bidirectionnelle est terminée, il est temps d'exécuter des tests LMD et LDD simples.

--DML test from classicmodels database on source MySQLpoc1
MySQLpoc1> select count(*) from weatherdata;
+----------+
| count(*) |
+----------+
|  4626432 |
+----------+
1 row in set (0.19 sec)

MySQLpoc1> insert into weatherdata values ('2005-01-02','04:50:00',-8.1,3,57.0,990.00,38.00,'Nebel-Schneefall',61);
Query OK, 1 row affected (0.00 sec)

MySQLpoc1> select count(*) from weatherdata;
+----------+
| count(*) |
+----------+
|  4626433 |
+----------+
1 row in set (0.23 sec)

-DDL replication test from classicmodels database on source MySQLpoc1
MySQLpoc1> create table test (name char(5));
Query OK, 0 rows affected (0.02 sec)

MySQL> insert into test values ('cj');
Query OK, 1 row affected (0.00 sec)

MySQL>

--Now Let's check if the above DML and DDLs got replicated to target MySQLpoc2
MySQLpoc2> select count(*) from weatherdata;
+----------+
| count(*) |
+----------+
|  4626433 | <--- row count matches to source
+----------+
1 row in set (0.37 sec)

MySQLpoc2>
MySQLpoc2> select * from test;
+------+
| name |
+------+
| cj   |          <-- table CJ got replicated
+------+
1 row in set (0.00 sec)

MySQL>


-- Now testing Bi directional
-- on target (MySQLpoc2)
MySQLpoc2> select * from test;
+------+
| name |
+------+
| cj   |
+------+
1 row in set (0.00 sec)

MySQLpoc2> insert into test values ('cj2');
Query OK, 1 row affected (0.01 sec)

MySQLpoc2> select * from test;
+------+
| name |
+------+
| cj   |
| cj2  |
+------+
2 rows in set (0.00 sec)

MySQLpoc2> insert into test values ('cjs3');
Query OK, 1 row affected (0.00 sec)

MySQLpoc2> select * from test;
+------+
| name |
+------+
| cj   |
| cj2  |
| cjs3 |
+------+
3 rows in set (0.00 sec)

MySQLpoc2>

--On source (MySQLpoc1):
--DML on the target got REPLICATed on the source
MySQLpoc1> select * from test;
+------+
| name |
+------+
| cj   |
| cj2  |
| cjs3 |
+------+
3 rows in set (0.00 sec)

MySQL>

Tâche 7 : configurer l'extraction du chargement initial

Configurez l'extraction de chargement initial si vous voulez utiliser OCI GoldenGate pour effectuer le chargement initial des données dans la base de données cible.
1. Connectez-vous à la console OCI GoldenGate.
2. Accédez à Présentation et cliquez sur + dans la section Extraire. Cela est très similaire à la création d'une extraction principale. La seule différence est de sélectionner Type d'extraction comme Chargement initial lors de la création d'une extraction.
  
  Fichier de paramètres pour l'extraction du chargement initial.
```
Parameter file for initial load EXTRACT:
EXTRACT EXTIL
USERIDALIAS  MySQLpoc1, DOMAIN OracleGoldenGate
EXTFILE il ,  PURGE
TABLE airportdb.*;
MAP_PARALLELISM 4
MIN_APPLY_PARALLELISM 2
MAX_APPLY_PARALLELISM 10
SPLIT_TRANS_RECS 1000
CHUNK_SIZE 1 GB
```
De même, configurez une réplication qui lira les fichiers trace générés par l'extraction du chargement initial. Cette réplication et l'extraction du chargement initial seront supprimées une fois le chargement initial terminé.
1. Sur la base de données cible, assurez-vous que toutes les tables sont vides. Supprimer/désactiver toutes les clés étrangères sur la cible. Désactiver les déclencheurs et les index sur la cible pour améliorer les performances de chargement initial.
  
  Remarque : effectuez une sauvegarde des instructions LDD des objets de schéma avant d'en supprimer.
2. Voici l'ordre dans lequel les processus Extract et Replicat doivent être créés si vous utilisez l'extraction de chargement initial pour le chargement initial des données.
  1. Créez une extraction principale pour la source (ne démarrez pas encore le processus).
  2. Créez une extraction de chargement initial pour la source (ne lancez pas encore le traitement) et capturez le code GTID sur la source.
  3. Créez une réplication pour traiter les fichiers trace générés par l'extraction du chargement initial pour la cible (ne démarrez pas encore le processus).
    
    Remarque : il n'existe pas de type de réplication distinct pour le chargement initial.
  4. Créez une réplication principale pour la cible (ne démarrez pas encore le processus).
  5. Utilisez la même table de points de reprise pour le processus Replicat de chargement initial et le processus Replicat principal. Le processus Replicat de chargement initial pointe vers les fichiers trace Extract initiaux et le processus Replicat principal vers les fichiers trace Extract principaux (les deux fichiers trace sont différents).
3. Voici l'ordre dans lequel les processus doivent être démarrés lors de l'utilisation de l'extraction de chargement initial.
  1. Démarrez l'extraction principale et notez le GTID avec lequel elle s'inscrit.
  2. Démarrez la réplication créée pour le chargement initial de l'extraction.
  3. Modifiez l'extraction de chargement initial et modifiez-la pour qu'elle commence par le GTID obtenu lors du démarrage de l'extraction principale.
  4. Démarrez la réplication principale.
    Remarque :
    - Démarrez la réplication principale uniquement après que l'extraction du chargement initial et la réplication pour le chargement initial sont synchronisées (LAG 0).
    - Créez ou activez les clés étrangères avant de démarrer la réplication principale.
    Créez des index (si vous les avez supprimés précédemment pour améliorer les performances de chargement initial) avant de démarrer la réplication principale.

Restrictions

Seules les répliques classique et coordonnée prennent en charge la réplication bidirectionnelle et multidirectionnelle. La réplication parallèle n'est pas prise en charge.
Incrémenter automatiquement les problèmes de colonne.
Si une table comporte une colonne qui n'est pas une clé primaire ou une clé unique, la mise en correspondance échoue car la combinaison de toutes les colonnes de cette table est la même sur la source et la cible.
Types de données, instructions DDL et autres limitations de fonctionnalités.
Lors de l'utilisation de la réplication Active-Active, les fuseaux horaires doivent être les mêmes sur les deux systèmes afin que la résolution et la détection des conflits basées sur l'horodatage puissent fonctionner.

Remerciements

Auteur - Chakradhar Jagganagari (Spécialiste de l'implémentation LIFT - Personnalisé, 3e partie, bases de données et applications VM)

Ressources de formation supplémentaires

Explorez d'autres ateliers sur docs.oracle.com/learn ou accédez à d'autres contenus de formation gratuits sur le canal Oracle Learning YouTube. De plus, visitez le site education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

Pour obtenir la documentation produit, consultez le site Oracle Help Center.

Informations relatives au titre et au copyright

Set up Bidirectional Replication Between Two Oracle Heatwave MySQL managed instances using OCI GoldenGate

G29683-02