Para uma vista geral conceptual da replicação entre centros de dados, consulte o artigo Acerca da replicação entre centros de dados.
Antes de começar
- Instale a versão 1.1.0 ou superior do AlloyDB Omni Operator para implementar o AlloyDB Omni num cluster do Kubernetes no centro de dados principal e num cluster do Kubernetes no centro de dados secundário.
- Crie um cluster de base de dados do AlloyDB Omni no cluster do Kubernetes no centro de dados principal.
Crie um cluster de base de dados secundário
Para criar um cluster de base de dados secundário do AlloyDB Omni e ativar a replicação a partir do cluster de base de dados principal, siga estes passos:
Kubernetes
Certifique-se de que a conetividade externa está ativada no cluster de base de dados principal do AlloyDB Omni. Se a conetividade externa não estiver ativada, adicione o seguinte à secção spec do manifesto do cluster da base de dados:
kind: DBCluster spec: allowExternalIncomingTraffic: truePara ativar a replicação no cluster da base de dados principal, aplique um manifesto semelhante ao seguinte ao cluster do Kubernetes no centro de dados 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_NAMESubstitua o seguinte:
DB_CLUSTER_NAME: o nome do cluster da base de dados, por exemplo,dbc-1.ENCODED_PASSWORD: a palavra-passe do utilizador da base de dados a usar para a replicação a partir de bases de dados secundárias, codificada como uma string base64, por exemplo,Q2hhbmdlTWUxMjM= for ChangeMe123. O valor predefinido éalloydbreplica.REPLICATION_NAME: o nome da replicação, por exemplo,replication-1.
Aguarde até que o estado da replicação esteja pronto.
Para obter as informações de ligação a montante usadas para configurar a replicação no cluster de base de dados secundário, execute o seguinte comando:
kubectl get replication REPLICATION_NAMEkubectl get replication REPLICATION_NAME -o json | jq .status.upstreamO exemplo de resultado tem um aspeto semelhante ao seguinte:
{ "host": "35.230.32.36", "password": { "name": "ha-rep-pw-dbc-1" }, "port": 5432, "replicationSlotName": "dbc_1_replication_1", "username": "alloydbreplica" }Tome nota do resultado, uma vez que precisa dele para ativar a replicação no cluster de base de dados secundário no passo seguinte.
Crie um cluster do AlloyDB Omni no seu cluster do Kubernetes no centro de dados secundário com uma configuração idêntica à do cluster da base de dados principal.
Certifique-se de que a conetividade externa está ativada no cluster de base de dados secundário do AlloyDB Omni.
Se a conetividade externa não estiver ativada, adicione o seguinte à secção de especificações do respetivo manifesto:
allowExternalIncomingTraffic: truePara ativar a replicação no cluster da base de dados secundária, aplique um manifesto semelhante ao seguinte ao cluster do Kubernetes no centro de dados secundário:
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: setupSubstitua o seguinte:
SECONDARY_DB_CLUSTER_NAME: o nome do cluster da base de dados secundária, por exemplo,dbc-2.ENCODED_PASSWORD: a palavra-passe do utilizador da base de dados a usar para a replicação do cluster da base de dados principal, codificada como uma string base64, por exemplo,Q2hhbmdlTWUxMjM= for ChangeMe123. O valor predefinido éalloydbreplica.SECONDARY_REPLICATION_NAME: o nome da replicação, por exemplo,replication-2.PRIMARY_HOST: o ponto final de ligação do cluster da base de dados principal a partir do resultado no passo 3 ao qual a base de dados secundária pode aceder para replicação.PRIMARY_PORT: a porta de ligação do cluster da base de dados principal a partir do resultado no passo 3 a que a base de dados secundária pode aceder para replicação.PRIMARY_REPLICATION_SLOT: o nome do espaço de replicação no cluster da base de dados principal a partir do resultado no passo 3 que a base de dados secundária pode usar para replicação.
Veja a replicação no cluster da base de dados secundária
Para ver informações detalhadas sobre um cluster de base de dados secundário do AlloyDB Omni e o respetivo estado de replicação, execute os seguintes comandos:
Kubernetes
kubectl get dbcluster SECONDARY_DB_CLUSTER_NAMEkubectl get replication SECONDARY_REPLICATION_NAME
Quando o cluster da base de dados secundária é configurado com êxito e tem replicação de streaming a partir do cluster da base de dados principal, o estado de replicação está pronto e é saudável.
Promova um cluster de base de dados secundário
Antes de promover um cluster de base de dados secundário, execute os seguintes passos para verificar se o cluster de base de dados secundário aplicou todas as transações recebidas do cluster de base de dados principal:
Kubernetes
Verifique o estado da replicação do cluster da base de dados secundária para garantir que está pronto e em bom estado.
kubectl get replication SECONDARY_REPLICATION_NAMEInterrompa todas as gravações no cluster da base de dados principal. Execute a seguinte consulta no cluster da base de dados principal para verificar o atraso de replicação da base de dados secundária. Confirme se o resultado apresenta um atraso mínimo.
Um valor de atraso de 0 é o ideal. Se o atraso for superior a 0, ainda pode promover o cluster de base de dados secundário, com o risco de perder algumas transações recentes já confirmadas no cluster de base de dados 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;'
Para promover um cluster de base de dados secundário a um cluster de base de dados principal, atualize o campo control do manifesto de replicação do cluster de base de dados secundário para promote e aplique-o no cluster do Kubernetes no centro de dados secundário.
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
Faça uma comutação
Antes de fazer a comutação, verifique se os clusters de base de dados principal e secundária pertencentes a ambos os centros de dados estão online e se os clusters de base de dados estão em bom estado.
Para garantir a consistência dos dados dos clusters de base de dados principal e secundário durante a comutação, siga estes passos para verificar se o cluster de base de dados secundário aplicou todas as transações recebidas do cluster de base de dados principal:
Kubernetes
Verifique o estado da replicação do cluster da base de dados secundária para garantir que está pronto e em bom estado.
kubectl get replication SECONDARY_REPLICATION_NAMEInterrompa todas as gravações no cluster da base de dados principal. Execute a seguinte consulta no cluster da base de dados principal para verificar o atraso de replicação da base de dados secundária. Confirme se o resultado mostra um valor de atraso 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;'
Para fazer uma comutação, conclua os seguintes passos:
Kubernetes
Para converter o cluster de base de dados secundário do AlloyDB Omni num cluster de base de dados principal, atualize o respetivo manifesto de replicação no cluster do Kubernetes no centro de dados secundário da seguinte forma:
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_NAMEAguarde até que o estado da replicação esteja pronto.
Para obter as informações de ligação a montante para a replicação, execute o seguinte comando:
kubectl get replication SECONDARY_REPLICATION_NAMEkubectl get replication SECONDARY_REPLICATION_NAME -o json | jq .status.upstreamO exemplo de resultado tem um aspeto semelhante ao seguinte:
{ "host": "34.23.207.137", "password": { "name": "ha-rep-pw-dbc-2" }, "port": 5432, "replicationSlotName": "dbc_2_replication_2", "username": "alloydbreplica" }Para converter o cluster de base de dados principal do AlloyDB Omni num cluster de base de dados secundário, atualize o respetivo manifesto de replicação no cluster do Kubernetes no centro de dados principal de forma semelhante ao seguinte:
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: rewindAguarde até que o estado de replicação fique pronto e saudável.
Para verificar o estado da replicação, use:
kubectl get replication REPLICATION_NAME