Pour obtenir une présentation conceptuelle de la réplication inter-data centers, consultez À propos de la réplication inter-data centers.
Avant de commencer
- Installez l'opérateur AlloyDB Omni version 1.1.0 ou ultérieure pour déployer AlloyDB Omni sur un cluster Kubernetes dans le centre de données principal et sur un cluster Kubernetes dans le centre de données secondaire.
- Créez un cluster de bases de données AlloyDB Omni sur le cluster Kubernetes du centre de données principal.
Créer un cluster de base de données secondaire
Pour créer un cluster de base de données secondaire AlloyDB Omni et activer la réplication à partir de votre cluster de base de données principal, procédez comme suit :
Kubernetes
Assurez-vous que la connectivité externe est activée sur votre cluster de base de données principal AlloyDB Omni. Si la connectivité externe n'est pas activée, ajoutez ce qui suit à la section "spec" du fichier manifeste du cluster de bases de données :
kind: DBCluster spec: allowExternalIncomingTraffic: truePour utiliser la réplication entre centres de données avec un cluster de base de données principal dont la haute disponibilité est activée, assurez-vous que les serveurs de base de données principal et de secours de votre cluster de base de données principal disposent d'un espace de journalisation Write-Ahead Logging (WAL) suffisant pour accueillir les fichiers WAL nécessaires à la réplication vers le cluster secondaire. Définissez la taille du WAL pour votre cluster de base de données principal AlloyDB Omni en définissant la section "spec" du fichier manifeste du cluster de base de données :
kind: DBCluster spec: primarySpec: parameters: wal_keep_size: WAL_KEEP_SIZE max_wal_size: MAX_WAL_SIZERemplacez les éléments suivants :
WAL_KEEP_SIZE: taille minimale des fichiers WAL passés stockés dans le répertoire WAL au cas où un serveur secondaire aurait besoin de les récupérer pour la réplication en flux continu. Si un serveur secondaire connecté au serveur principal est en retard de plus dewal_keep_sizemégaoctets, le serveur principal peut supprimer un segment WAL dont le serveur secondaire a besoin. Dans ce cas, la connexion de réplication est interrompue. Les connexions en aval finiront également par échouer. DéfinissezWAL_KEEP_SIZEsur une valeur qui répond aux exigences de votre charge de travail, en fonction du taux de génération WAL, des caractéristiques du réseau de réplication et du décalage de réplication entre les centres de données où vos clusters de bases de données principal et secondaire sont déployés. La valeur par défaut est de 100 Mo.MAX_WAL_SIZE: taille maximale pour permettre au WAL de s'étendre lors des points de contrôle automatiques de la base de données. La valeur par défaut est de 1 504 Mo. Cette valeur doit être supérieure à celle dewal_keep_size.
Pour activer la réplication sur votre cluster de base de données principal, appliquez un fichier manifeste semblable à celui ci-dessous à votre cluster Kubernetes dans le centre de données principal :
apiVersion: v1 kind: Secret metadata: name: ha-rep-pw-DB_CLUSTER_NAME type: Opaque data: rep-user-pw: "ENCODED_PASSWORD" --- apiVersion: alloydbomni.dbadmin.goog/v1 kind: Replication metadata: name: REPLICATION_NAME spec: dbcluster: name: DB_CLUSTER_NAME upstream: password: name: ha-rep-pw-DB_CLUSTER_NAMERemplacez les éléments suivants :
DB_CLUSTER_NAME: nom du cluster de base de données, par exempledbc-1.ENCODED_PASSWORD: mot de passe de l'utilisateur de la base de données à utiliser pour la réplication à partir des bases de données secondaires, encodé sous forme de chaîne base64 (par exemple,Q2hhbmdlTWUxMjM= for ChangeMe123). La valeur par défaut estalloydbreplica.REPLICATION_NAME: nom de la réplication, par exemple,replication-1.
Attendez que l'état de la réplication soit "Prêt".
Pour obtenir les informations de connexion en amont utilisées pour configurer la réplication sur le cluster de bases de données secondaires, exécutez la commande suivante :
kubectl get replication REPLICATION_NAMEkubectl get replication REPLICATION_NAME -o json | jq .status.upstreamVoici un exemple de résultat :
{ "host": "35.230.32.36", "password": { "name": "ha-rep-pw-dbc-1" }, "port": 5432, "replicationSlotName": "dbc_1_replication_1", "username": "alloydbreplica" }Notez le résultat, car vous en aurez besoin pour activer la réplication sur le cluster de bases de données secondaire à l'étape suivante.
Créez un cluster AlloyDB Omni sur votre cluster Kubernetes dans le centre de données secondaire avec une configuration identique à celle de votre cluster de base de données principal.
Assurez-vous que la connectivité externe est activée sur votre cluster de base de données secondaire AlloyDB Omni.
Si la connectivité externe n'est pas activée, ajoutez ce qui suit à la section "spec" de son fichier manifeste :
allowExternalIncomingTraffic: truePour activer la réplication sur votre cluster de base de données secondaire, appliquez un fichier manifeste semblable à celui ci-dessous à votre cluster Kubernetes dans le centre de données secondaire :
apiVersion: v1 kind: Secret metadata: name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME type: Opaque data: rep-user-pw: "ENCODED_PASSWORD" --- apiVersion: alloydbomni.dbadmin.goog/v1 kind: Replication metadata: name: SECONDARY_REPLICATION_NAME spec: dbcluster: name: SECONDARY_DB_CLUSTER_NAME downstream: host: PRIMARY_HOST port: PRIMARY_PORT username: alloydbreplica password: name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME replicationSlotName: PRIMARY_REPLICATION_SLOT control: setupRemplacez les éléments suivants :
SECONDARY_DB_CLUSTER_NAME: nom du cluster de base de données secondaire, par exempledbc-2.ENCODED_PASSWORD: mot de passe de l'utilisateur de la base de données à utiliser pour la réplication du cluster de base de données principal, encodé sous forme de chaîne base64 (par exemple,Q2hhbmdlTWUxMjM= for ChangeMe123). La valeur par défaut estalloydbreplica.SECONDARY_REPLICATION_NAME: nom de la réplication, par exemple,replication-2.PRIMARY_HOST: point de terminaison de connexion du cluster de base de données principal à partir de la sortie de l'étape 3 auquel la base de données secondaire peut accéder pour la réplication.PRIMARY_PORT: port de connexion du cluster de base de données principal à partir de la sortie de l'étape 3 auquel la base de données secondaire peut accéder pour la réplication.PRIMARY_REPLICATION_SLOT: nom de l'emplacement de réplication sur le cluster de base de données principal à partir de la sortie de l'étape 3 que la base de données secondaire peut utiliser pour la réplication.
Afficher la réplication sur le cluster de base de données secondaire
Pour afficher des informations détaillées sur un cluster de base de données secondaire AlloyDB Omni et son état de réplication, exécutez les commandes suivantes :
Kubernetes
kubectl get dbcluster SECONDARY_DB_CLUSTER_NAMEkubectl get replication SECONDARY_REPLICATION_NAME
Lorsque le cluster de bases de données secondaire est correctement configuré et qu'il effectue une réplication en flux continu à partir du cluster de bases de données principal, l'état de la réplication est à la fois "Prêt" et "Sain".
Promouvoir un cluster de bases de données secondaires
Avant de promouvoir un cluster de bases de données secondaires, procédez comme suit pour vérifier qu'il a appliqué toutes les transactions reçues du cluster de bases de données principal :
Kubernetes
Vérifiez l'état de la réplication du cluster de bases de données secondaires pour vous assurer qu'il est prêt et opérationnel.
kubectl get replication SECONDARY_REPLICATION_NAMEArrêtez toutes les opérations en écriture dans le cluster de base de données principal. Exécutez la requête suivante sur votre cluster de base de données principal pour vérifier le décalage de réplication de la base de données secondaire. Vérifiez que le résultat présente un décalage minimal.
Une valeur de décalage de 0 est idéale. Si le décalage est supérieur à 0, vous pouvez toujours promouvoir le cluster de bases de données secondaires, au risque de perdre certaines transactions récentes déjà validées sur le cluster de bases de données principal.
psql -h PRIMARY_HOST -U postgres -d postgres -c 'SELECT application_name, pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag FROM pg_stat_replication;'
Pour promouvoir un cluster de bases de données secondaire en cluster de bases de données principal, définissez le champ control du fichier manifeste de réplication de votre cluster de bases de données secondaire sur promote, puis appliquez-le à votre cluster Kubernetes dans le centre de données secondaire.
Kubernetes
apiVersion: v1
kind: Secret
metadata:
name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
type: Opaque
data:
rep-user-pw: "ENCODED_PASSWORD"
---
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Replication
metadata:
name: SECONDARY_REPLICATION_NAME
spec:
dbcluster:
name: SECONDARY_DB_CLUSTER_NAME
downstream:
host: PRIMARY_HOST
port: PRIMARY_PORT
username: alloydbreplica
password:
name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
replicationSlotName: PRIMARY_REPLICATION_SLOT
control: promote
Effectuer une commutation
Avant d'effectuer un basculement, vérifiez que les clusters de bases de données principaux et secondaires appartenant aux deux centres de données sont en ligne et en bon état.
Pour garantir la cohérence des données de vos clusters de bases de données principal et secondaire lors de la bascule, procédez comme suit pour vérifier que le cluster de bases de données secondaire a appliqué toutes les transactions reçues du cluster de bases de données principal :
Kubernetes
Vérifiez l'état de la réplication du cluster de bases de données secondaires pour vous assurer qu'il est prêt et opérationnel.
kubectl get replication SECONDARY_REPLICATION_NAMEArrêtez toutes les opérations en écriture dans le cluster de base de données principal. Exécutez la requête suivante sur votre cluster de base de données principal pour vérifier le décalage de réplication de la base de données secondaire. Vérifiez que le résultat affiche une valeur de décalage de
0.psql -h PRIMARY_HOST -U postgres -d postgres -c 'SELECT application_name, pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag FROM pg_stat_replication;'
Pour effectuer une permutation, procédez comme suit :
Kubernetes
Pour convertir votre cluster de bases de données secondaires AlloyDB Omni en cluster de bases de données principal, mettez à jour son fichier manifeste de réplication sur votre cluster Kubernetes dans le centre de données secondaire comme suit :
apiVersion: v1 kind: Secret metadata: name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME type: Opaque data: rep-user-pw: "ENCODED_PASSWORD" --- apiVersion: alloydbomni.dbadmin.goog/v1 kind: Replication metadata: name: SECONDARY_REPLICATION_NAME spec: dbcluster: name: SECONDARY_DB_CLUSTER_NAME upstream: password: name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAMEAttendez que l'état de la réplication soit "Prêt".
Pour obtenir les informations de connexion en amont pour la réplication, exécutez la commande suivante :
kubectl get replication SECONDARY_REPLICATION_NAMEkubectl get replication SECONDARY_REPLICATION_NAME -o json | jq .status.upstreamVoici un exemple de résultat :
{ "host": "34.23.207.137", "password": { "name": "ha-rep-pw-dbc-2" }, "port": 5432, "replicationSlotName": "dbc_2_replication_2", "username": "alloydbreplica" }Pour convertir votre cluster de base de données principal AlloyDB Omni en cluster de base de données secondaire, mettez à jour son fichier manifeste de réplication sur votre cluster Kubernetes dans le centre de données principal, comme suit :
apiVersion: v1 kind: Secret metadata: name: ha-rep-pw-DB_CLUSTER_NAME type: Opaque data: rep-user-pw: "ENCODED_PASSWORD" --- apiVersion: alloydbomni.dbadmin.goog/v1 kind: Replication metadata: name: REPLICATION_NAME spec: dbcluster: name: DB_CLUSTER_NAME downstream: host: SECONDARY_HOST port: SECONDARY_PORT username: alloydbreplica password: name: ha-rep-pw-DB_CLUSTER_NAME replicationSlotName: SECONDARY_REPLICATION_SLOT control: rewindAttendez que l'état de la réplication devienne "Prêt" et "OK".
Pour vérifier l'état de la réplication, utilisez la commande suivante :
kubectl get replication REPLICATION_NAME