AWS Oracle RDS Read Replicas : un Active Dataguard en mode PaaS ?

mercredi, mai 22, 2019
By Emmanuel RAMI in AWS (erami@capdata-osmozium.com) [6 article(s)]

Comme nous le savons déjà, AWS dans son offre RDS, propose la fonctionnalité “Read Replicas” pour l’ensemble des bases MySQL, PostGreSQL, Aurora et MariaDb.

Or depuis mars 2019, AWS a décidé d’étendre cette fonctionnalité à Oracle. On attend toujours cette fonctionnalité pour SQL Server, ce qui ne devrait pas être techniquement difficile à mettre en oeuvre dans la mesure ou un AlwaysOn en lecture seul sait faire ce travail on-Premise ou en IaaS.

Mais voyons en détail, cette nouveauté pour Oracle.

Comme nous devions nous en douter, Amazon va ni plus ni moins se baser sur ce que Oracle sait déjà faire, à savoir l’option Active Dataguard. Le principe est d’avoir une base source primaire qui sera en mode “Read and write” qui servira de production OLTP ou bien pour des chargements ETL.
Une base dite “standby” sera alors créée et synchronisée avec celle ci en mode “Read only”. Ceci sera très utile en cas de besoin de reporting en temps réel sur des données de production fraîches.

 

Quelques conditions pour la mise en oeuvre

Afin de pouvoir mettre en place cette configuration, il faudra respecter les prérequis suivants. A peu de chose près, Amazon a repris dans cette liste ce que Oracle recommande pour sa fonctionnalité Active Dataguard :

  • Le Read Replicas pour Oracle RDS requiert la licence Active Dataguard
  • La base primaire doit être une version Enterprise Edition
  • Attention, Amazon ne supporte cette fonctionnalité qu’à partir d’Oracle 12.1 (12.1.0.2.v10) alors qu’Oracle a validé cette option dès sa version 11g.
  • Il sera nécessaire de créer des instance sur un VPC  nommé (pas de “Default VPC”), avec au moins 2 vCPU, pour effectuer cette configuration (soit une classe ‘db.m5.large’ minimum).
  • La base primaire et sa standby doivent être configurées avec le même DB parameter group et option group.
  • Il sera primordial d’activer les backup sur la base primaire, ce qui active le mode “archivelog” sur celle ci.

Créer le read replicas

Nous partirons d’un base de données Oracle RDS 12.1 EE existante nommée “capdata” dans laquelle nous avons créé un schéma “manu” comportant une table “employes”.

Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = capdata.cctwibgpckff.eu-west-3.rds.amazonaws.com)(PORT = 1532))) (CONNEC
T_DATA = (SERVICE_NAME = ORCL)))
OK (20 msec)

C:\Users\manu>sqlplus manu@CAPDATADB

SQL*Plus: Release 11.2.0.3.0 Production on Mon May 13 10:01:49 2019

Copyright (c) 1982, 2011, Oracle. All rights reserved.

Enter password:

Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 – 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

SQL>

SQL> select * from employes;

NOM                              POSTE
————————- ——————–
manu                             DBA
john                               admin systeme
Fred                               admin reseaux

 

Nous pourrons créer le read replicas, soit via l’interface graphique de la console, soit via AWS CLI.

– Interface console

Comme pour la création classique d’un Dataguard sous Oracle, il sera nécessaire de passer la base en mode “Force Logging” afin de valider l’enregistrement complet de toute transaction effective en base.

SQL> exec rdsadmin.rdsadmin_util.force_logging(p_enable => true);

On suppose que ceci sera fait par le processus de création du read replicas, mais afin de s’assurer de cela, nous pourrons le faire en avance de phase.

Sur le menu RDS, dans la partie Databases, ou nous voyons notre instance nommée “Capdata”, nous sélectionnerons celle ci puis “Actions”.

 

une fois arrivé sur la page des propriétés liées au nouveau replicas, nous pourrons choisir certaines options dont ; une nouvelle zone de disponibilité (nous prendrons la zone ‘eu-west-3c’ car la base principale est sur ‘eu-west-3b’) :

mais aussi les informations sur notre replication, la source qui est la base “capdata” et la base replicas qui sera “capdatarep” :

On laissera les autres options par défaut, comme nous l’avions effectué pour la base source.
Une fois terminé, nous pourrons cliquer sur la création du replicas :

Les opérations de duplication sont alors en cours. Ceci peut être assez long en fonction de la taille de votre base source. Si tout se passe bien, vous pourrez alors, accéder au récapitulatif suivant :

Nous irons voir si cette base répliquée comporte bien nos données de la table “employes”. Pour cela nous irons enregistrer dans le tnsnames.ora l’entrée de cette base avec le ‘endpoint’ que Amazon nous aura donné, ou bien envoyer le chemin complet via la méthode Ezconnect.

Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = capdatarep.cctwibgpckff.eu-west-3.rds.amazonaws.com)(PORT = 1532))) (CON
NECT_DATA = (SERVICE_NAME = ORCL)))
OK (10 msec)

Notre repliacas comportera le nom de host suivant :

SQL> select INSTANCE_NAME,HOST_NAME from v$instance;

INSTANCE_NAME    HOST_NAME
---------------- ----------------------------------------------------------------
ORCL             ip-172-16-2-203
 

Nous retrouvons bien notre table “employes”

SQL> select * from employes;

NOM                              POSTE
————————- ——————–
manu                             DBA
john                               admin systeme
Fred                               admin reseaux

Bien entendu, nous sommes en mode lecture seule uniquement !!

SQL> insert into employes values ('toto','pirate');
insert into employes values ('toto','pirate')
*
ERROR at line 1:
ORA-16000: database or pluggable database open for read-only access

 -- > A noter que la base se nomme ORCL

SQL> select name, open_mode from v$database;

NAME      OPEN_MODE
--------- --------------------
ORCL      READ ONLY WITH APPLY

 

– interface AWS CLI

Nous utiliserons l’utilitaire aws cli afin de pouvoir scripter cette procédure de création. Pour cela c’est l’option “create-db-instance-read-replica” qui sera choisi, avec les nombreuses options potentielles (voir https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance-read-replica.html)

Nous pourrons créer un nouveau réplicas avec les mêmes caractéristiques que “capdatarep” que nous nommerons “capdatarep2” :

$ aws rds create-db-instance-read-replica --db-instance-identifier capdatarep2 --source-db-instance-identifier capdata \
  --availability-zone eu-west-3c --no-publicly-accessible --region eu-west-3

La réponse sera alors en mode JSON et nous indiquera la prise en compte de notre opération :

{
    "DBInstance": {
        "PubliclyAccessible": false,
        "MasterUsername": "manu",
        "MonitoringInterval": 0,
        "LicenseModel": "bring-your-own-license",
        "VpcSecurityGroups": [
            {
                "Status": "active",
                "VpcSecurityGroupId": "sg-03b37eb21e178db5d"
            },
            {
                "Status": "active",
                "VpcSecurityGroupId": "sg-020a6713a54e7921e"
            }
        ],
        "CopyTagsToSnapshot": false,
        "OptionGroupMemberships": [
            {
                "Status": "pending-apply",
                "OptionGroupName": "default:oracle-ee-12-1"
            }
        ],
        "PendingModifiedValues": {},
        "Engine": "oracle-ee",
        "MultiAZ": false,
        "DBSecurityGroups": [],
        "DBParameterGroups": [
            {
                "DBParameterGroupName": "default.oracle-ee-12.1",
                "ParameterApplyStatus": "in-sync"
            }
        ],
        "PerformanceInsightsEnabled": false,
        "ReadReplicaSourceDBInstanceIdentifier": "capdata",
        "AutoMinorVersionUpgrade": false,
        "PreferredBackupWindow": "13:13-13:43",
        "DBSubnetGroup": {
            "Subnets": [
                {
                    "SubnetStatus": "Active",
                    "SubnetIdentifier": "subnet-0b3c36203a277331f",
                    "SubnetAvailabilityZone": {
                        "Name": "eu-west-3c"
                    }
                },
                {
                    "SubnetStatus": "Active",
                    "SubnetIdentifier": "subnet-0b56834a874187f7d",
                    "SubnetAvailabilityZone": {
                        "Name": "eu-west-3b"
                    }
                }
            ],
            "DBSubnetGroupName": "default-vpc-09c93b8bac48a99ff",
            "VpcId": "vpc-09c93b8bac48a99ff",
            "DBSubnetGroupDescription": "Created from the RDS Management Console",
            "SubnetGroupStatus": "Complete"
        },
        "ReadReplicaDBInstanceIdentifiers": [],
        "AllocatedStorage": 20,
        "DBInstanceArn": "arn:aws:rds:eu-west-3:018033502850:db:capdatarep2",
        "BackupRetentionPeriod": 0,
        "DBName": "ORCL",
        "PreferredMaintenanceWindow": "sun:04:57-sun:05:27",
        "DBInstanceStatus": "creating",
        "IAMDatabaseAuthenticationEnabled": false,
        "EngineVersion": "12.1.0.2.v15",
        "DeletionProtection": false,
        "CharacterSetName": "AL32UTF8",
        "AvailabilityZone": "eu-west-3c",
        "DomainMemberships": [],
        "StorageType": "gp2",
        "DbiResourceId": "db-DQ7BCOFD5ULPI3SQTRLUTMY34A",
        "CACertificateIdentifier": "rds-ca-2015",
        "StorageEncrypted": false,
        "DBInstanceClass": "db.m5.large",
        "DbInstancePort": 0,
        "DBInstanceIdentifier": "capdatarep2"
    }
}

Nous avons donc un read replicas, nommé “capdatarep2” version Oracle 12.1.0.2.v15 sur l’AZ “eu-west-3c”, en cours de création sur notre compte RDS. On peut éditer au format text les informations liées à notre nouvelle instance :

$ aws rds describe-db-instances --db-instance-identifier capdatarep2 --region=eu-west-3 --output=text
DBINSTANCES     20      False   eu-west-3c      0       rds-ca-2015     AL32UTF8        False   
	arn:aws:rds:eu-west-3:018033502850:db:capdatarep2       db.m5.large     
	capdatarep2     modifying       ORCL    0       db-DQ7BCOFD5ULPI3SQTRLUTMY34A   False   oracle-ee       12.1.0.2.v15    False   2019-05-13T13:26:31.991Z
        bring-your-own-license  manu    0       False   False   13:13-13:43     sun:04:57-sun:05:27 False       capdata False   gp2
DBPARAMETERGROUPS       		default.oracle-ee-12.1  in-sync
DBSUBNETGROUP   			Created from the RDS Management Console default-vpc-09c93b8bac48a99ff   Complete     vpc-09c93b8bac48a99ff
SUBNETS 				subnet-0b3c36203a277331f        Active
SUBNETAVAILABILITYZONE  		eu-west-3c
SUBNETS 				subnet-0b56834a874187f7d        Active
SUBNETAVAILABILITYZONE  		eu-west-3b
ENDPOINT        			capdatarep2.cctwibgpckff.eu-west-3.rds.amazonaws.com    
ZMESEXB7ZGGQ3   			1532
OPTIONGROUPMEMBERSHIPS  		default:oracle-ee-12-1  applying
STATUSINFOS     			True    replicating     read replication
VPCSECURITYGROUPS       		active  sg-03b37eb21e178db5d
VPCSECURITYGROUPS       		active  sg-020a6713a54e7921e


Celle ci sera également visible sur la console

 

Notons le ‘endpoint’ attribué à notre instance (ici capdatarep2.cctwibgpckff.eu-west-3.rds.amazonaws.com) et le port qui est le même , 1532. Nous pouvons alors nous connecter et tester notre nouveau replicas :

SQL> select INSTANCE_NAME,HOST_NAME from v$instance;

INSTANCE_NAME    HOST_NAME
---------------- ----------------------------------------------------------------
ORCL             ip-172-16-2-218

La nouvelle IP pour notre nouvelle base sera renseigné dans le champ host. Puis on teste les données :

SQL> select * from employes;

NOM                       POSTE
------------------------- --------------------
manu                      DBA
john                      admin systeme
Fred                      admin reseaux
SQL> insert into employes values ('nouveau','test');
insert into employes values ('nouveau','test')
*
ERROR at line 1:
ORA-16000: database or pluggable database open for read-only access

 

L’avantage d’un read replicas, outre les opérations de reporting en lecture seule,  est le fait de pouvoir effectuer des “snapshots” sur celle-ci, ceci permet donc de libérer des IO pour la base master primaire qui n’aura pas à gérer ces tâches de maintenance.

Promouvoir un read replicas

dans le cadre d’un disaster recovery, il sera possible de promouvoir un des reads replicas que nous aurons créé. Attention, cela veut bien dire que nous allons ouvrir en lecture mais aussi en écriture la base replicas qui, à partir de ce moment, vivra sa vie indépendamment de la base master.

Il est donc bien important de considérer que ceci n’est aucunement un “switchover” comme Oracle peut le considérer dans le cadre d’un Dataguard, mais bien un “Failover” dans le sens ou l’on casse la replication entre le master et son réplicas.

Nous pouvons, également pour cette opération, effectuer ceci via la console, ou bien via AWS CLI.

– interface console

Sur la page des bases RDS choisir le replicas à promouvoir et cliquer “Actions” et “promote”.

Nous laisserons par défaut la stratégie de backup mis en place pour le replicas “capdatarep”.

Un message d’avertissement nous indique les conséquences de cette opération et son côté irréversible. La base “capdatarep” est donc prête à devenir indépendante !

On pourra se connecter à “capdatarep” pour voir si celle ci accepte les mises à jour :

SQL>

INSTANCE_NAME    HOST_NAME            STARTUP_TIME        STATUS       DATABASE_STATUS   INSTANCE_ROLE      ACTIVE_ST
---------------- -------------------- ------------------- ------------ ----------------- ------------------ ---------
ORCL             ip-172-16-2-203      2019/05/13 14:09:05 OPEN         ACTIVE            PRIMARY_INSTANCE   NORMAL

SQL>  select name, open_mode from v$database;

NAME      OPEN_MODE
--------- --------------------
ORCL      READ WRITE

On voit que la base est ouverte depuis 14h avec le mode “READ WRITE”, allons le vérifier :

SQL> select * from employes;

NOM                       POSTE
------------------------- --------------------
manu                      DBA
john                      admin systeme
Fred                      admin reseaux

SQL> insert into employes values ('toto','pirate');

1 row created.

SQL> commit;

Commit complete.

SQL> select * from employes;

NOM                       POSTE
------------------------- --------------------
toto                      pirate
manu                      DBA
john                      admin systeme
Fred                      admin reseaux

Nous pouvons en déduire que notre base “capdatarep” est maintenant une base indépendante ouverte en lecture/écriture.

– interface AWS CLI

Avec aws cli, la promotion d’un read replicas se fera via la commande (exemple avec “capdatarep2”):

$ aws rds promote-read-replica --db-instance-identifier capdatarep2 --region eu-west-3

Une réponse en JSON sera envoyé après cette commande

{
    "DBInstance": {
        "PubliclyAccessible": false,
        "MasterUsername": "manu",
        "MonitoringInterval": 0,
        "LicenseModel": "bring-your-own-license",
        "VpcSecurityGroups": [
            {
                "Status": "active",
                "VpcSecurityGroupId": "sg-03b37eb21e178db5d"
            },
            {
                "Status": "active",
                "VpcSecurityGroupId": "sg-020a6713a54e7921e"
            }
        ],
        "InstanceCreateTime": "2019-05-13T13:26:31.991Z",
        "CopyTagsToSnapshot": false,
        "OptionGroupMemberships": [
            {
                "Status": "in-sync",
                "OptionGroupName": "default:oracle-ee-12-1"
            }
        ],
        "PendingModifiedValues": {
            "BackupRetentionPeriod": 1
        },
        "Engine": "oracle-ee",
        "MultiAZ": false,
        "DBSecurityGroups": [],
        "DBParameterGroups": [
            {
                "DBParameterGroupName": "default.oracle-ee-12.1",
                "ParameterApplyStatus": "in-sync"
            }
        ],
        "PerformanceInsightsEnabled": false,
        "ReadReplicaSourceDBInstanceIdentifier": "capdata",
        "AutoMinorVersionUpgrade": false,
        "PreferredBackupWindow": "10:22-10:52",
        "DBSubnetGroup": {
            "Subnets": [
                {
                    "SubnetStatus": "Active",
                    "SubnetIdentifier": "subnet-0b3c36203a277331f",
                    "SubnetAvailabilityZone": {
                        "Name": "eu-west-3c"
                    }
                },
                {
                    "SubnetStatus": "Active",
                    "SubnetIdentifier": "subnet-0b56834a874187f7d",
                    "SubnetAvailabilityZone": {
                        "Name": "eu-west-3b"
                    }
                }
            ],
            "DBSubnetGroupName": "default-vpc-09c93b8bac48a99ff",
            "VpcId": "vpc-09c93b8bac48a99ff",
            "DBSubnetGroupDescription": "Created from the RDS Management Console",
            "SubnetGroupStatus": "Complete"
        },
        "ReadReplicaDBInstanceIdentifiers": [],
        "AllocatedStorage": 20,
        "DBInstanceArn": "arn:aws:rds:eu-west-3:018033502850:db:capdatarep2",
        "BackupRetentionPeriod": 0,
        "DBName": "ORCL",
        "PreferredMaintenanceWindow": "sun:04:57-sun:05:27",
        "Endpoint": {
            "HostedZoneId": "ZMESEXB7ZGGQ3",
            "Port": 1532,
            "Address": "capdatarep2.cctwibgpckff.eu-west-3.rds.amazonaws.com"
        },
        "DBInstanceStatus": "modifying",
        "StatusInfos": [
            {
                "Status": "replicating",
                "StatusType": "read replication",
                "Normal": true
            }
        ],
        "IAMDatabaseAuthenticationEnabled": false,
        "EngineVersion": "12.1.0.2.v15",
        "DeletionProtection": false,
        "CharacterSetName": "AL32UTF8",
        "AvailabilityZone": "eu-west-3c",
        "DomainMemberships": [],
        "StorageType": "gp2",
        "DbiResourceId": "db-DQ7BCOFD5ULPI3SQTRLUTMY34A",
        "CACertificateIdentifier": "rds-ca-2015",
        "StorageEncrypted": false,
        "DBInstanceClass": "db.m5.large",
        "DbInstancePort": 0,
        "DBInstanceIdentifier": "capdatarep2"
    }
}


le “promote” de la base “capdatarep2” est en cours, le processus redémarrera la base et celle ci sera vu comme “instance” et non plus “replica” sur la console :

On pourra également se connecter sur “capdatarep2” et tester l’ajout de données dans notre table “employes” pour valider le fait que cette base est passé en mode “READ WRITE”. Procéder à ce qui a été fait à l’étape du “promote” de la base “capdatarep” pour verifier cela.

 

Conclusion

L’option Oracle for RDS Read Replicas fait-elle office d’option Active Datagaurd ?

Oui car

comme nous l’avons vu, dans le cadre d’une base de données Oracle RDS ouverte en lecture / écriture , nous pourrons y attacher une base de données Oracle de même version qui pourra accueillir le flux de données en lecture afin de “réduire” les accès sur la base primaire.
Il sera nécessaire de disposer de licences Enterprise Edition, dans la cadre de license BYOL (Bring your own license) pour cette mise en place dans Amazon.

La réplication en mode “Redo Apply” est effectuée au fil de l’eau comme ceci peut se faire sur une installation en mode IaaS ou sur un système On-Premise.
Il sera d’ailleurs possible de suivre notre processus de media recovery via les vues dataguard classiques:

v$managed_standby pour suivre l’etat des processus rfs et arc.

v$dataguard_status pour suivre les logs Oracle liés à la replication.

v$dataguard_stats pour suivre les composants de replication ; transport_lag et apply_lag.

v$archived_log pour savoir quels sont les archivelogs sauvegardés, appliqués et supprimés.

 

Mais en fait

nous sommes dans un environnement PaaS, donc certaines fonctionnalités liées au dataguard ne seront pas accessibles. On pense notamment au DG Broker, car celui ci se gère via l’outil “dgmgrl”, outil qui ne nous sera pas mis à disposition par Amazon.
Les vues systèmes ci dessus nous permettent de suivre notre processus de recover, mais pas de broker pour la replication.

Enfin, chose importante à bien se mettre en tête, AWS nous propose ici un mode “Read Replicas” mais ne nous assure pas un véritable “Disaster Recovery” comme peut le faire le mode “Multi-AZ”. Il ne nous sera pas possible d’effectuer un véritable “Switchover” de base, ainsi la primaire ne changera jamais de rôle avec l’option Read Replicas.

Avec le Read Replicas, Amazon n’a certainement pas voulu mettre en concurrence son option “Multi-AZ” mais juste mettre en oeuvre une fonctionnalité qui permet de maximiser les performances en lectures sans pénaliser les écritures de la base primaire. Le multi-AZ est là pour s’assurer de la haute disponibilité. Amazon a clairement identifier les rôles propres à chacune de ces solutions dans un tableau défini comme ceci :

Cordialement

 

Emmanuel RAMI

 

 

Continuez votre lecture sur le blog :




Cliquer pour partager cet article sur Viadeo
Cliquer sur "CAPTURER" pour sauvegarder cet article dans Evernote Clip to Evernote

Tags: , , ,

Leave a Reply