Para uma visão geral conceitual da replicação entre data centers, consulte Sobre a replicação entre data centers.
Antes de começar
- Verifique se você tem conectividade de rede confiável e de baixa latência entre os data centers primário e secundário, o que é fundamental para que a replicação entre data centers funcione de maneira eficaz.
- Instale a versão mais recente do operador do AlloyDB Omni para implantar o AlloyDB Omni em um cluster do Kubernetes no data center primário e em um cluster do Kubernetes no data center secundário. A replicação entre data centers é compatível com a versão 1.5.0 ou mais recente do operador do AlloyDB Omni.
- Crie um cluster de banco de dados do AlloyDB Omni no cluster do Kubernetes no data center primário.
- Verifique se os servidores de banco de dados primário e em espera no cluster de banco de dados primário têm espaço adequado para o registro prévio de escrita (WAL) para acomodar os arquivos do WAL necessários para a replicação no cluster secundário. Todos os dados que ainda não foram replicados para o cluster secundário são armazenados no cluster primário como arquivos do WAL. Portanto, dependendo da velocidade de conexão entre os clusters primário e secundário, talvez seja necessário mais espaço em disco para essa finalidade.
Criar um cluster de banco de dados secundário
Para criar um cluster de banco de dados secundário do AlloyDB Omni e ativar a replicação do cluster de banco de dados primário, siga estas etapas:
Kubernetes
Verifique se a conectividade externa está ativada no cluster de banco de dados primário do AlloyDB Omni. Se a conectividade externa não estiver ativada, adicione o seguinte à seção de especificação do manifesto do cluster de banco de dados:
kind: DBCluster spec: allowExternalIncomingTraffic: true
Para usar a replicação entre data centers com um cluster de banco de dados primário que tenha alta disponibilidade (HA, na sigla em inglês) ativada, confirme se o campo
replayReplicationSlotsOnStandbys
está ativado no cluster de banco de dados primário:kind: DBCluster spec: availability: replayReplicationSlotsOnStandbys: true
Ao ativar esse campo, junto com o
logReplicationSlots
explicado na próxima etapa, o slot de replicação usado pelo cluster de banco de dados secundário será sincronizado com todos os bancos de dados em espera de alta disponibilidade. Essa configuração ajuda o novo primário de alta disponibilidade a reter os arquivos do registro prévio de escrita (WAL) ainda não consumidos pelo cluster de banco de dados secundário após um failover ou troca permitindo que ela retome a replicação sem interrupção.Para ativar a replicação no cluster de banco de dados primário, aplique um manifesto semelhante ao seguinte no cluster do Kubernetes no data center primário:
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_NAME logReplicationSlot: LOG_REPLICATION_SLOT
Substitua o seguinte:
DB_CLUSTER_NAME
: o nome do cluster de banco de dados, por exemplo,dbc-1
.ENCODED_PASSWORD
: a senha do usuário do banco de dados a ser usada para replicação de bancos de dados secundários, codificada como uma string base64, por exemplo,Q2hhbmdlTWUxMjM= for ChangeMe123
. O valor padrão éalloydbreplica
.REPLICATION_NAME
: o nome da replicação, por exemplo,replication-1
.LOG_REPLICATION_SLOT
: dados do slot de replicação de registros em arquivos do WAL. Para ativar essa opção, defina o valor dela comotrue
. O valor padrão éfalse
.
Recomendamos ativar a opção
logReplicationSlot
com o cluster de banco de dados primário que tem alta disponibilidade (HA) ativada para garantir que a replicação possa continuar funcionando após um failover ou uma troca.Aguarde até que o status da replicação seja "Pronto".
Para receber as informações de conexão upstream usadas para configurar a replicação no cluster de banco de dados secundário, execute o seguinte comando:
kubectl get replication REPLICATION_NAME
kubectl get replication REPLICATION_NAME -o json | jq .status.upstream
Um exemplo de resposta é parecido com este:
{ "host": "35.230.32.36", "password": { "name": "ha-rep-pw-dbc-1" }, "port": 5432, "replicationSlotName": "dbc_1_replication_1", "username": "alloydbreplica" }
Anote a resposta, porque ela será necessária para ativar a replicação no cluster de banco de dados secundário na próxima etapa.
Crie um cluster do AlloyDB Omni no cluster do Kubernetes no data center secundário com uma configuração idêntica ao cluster de banco de dados primário.
Verifique se a conectividade externa está ativada no cluster de banco de dados secundário do AlloyDB Omni.
Se a conectividade externa não estiver ativada, adicione o seguinte à seção de especificação do manifesto:
allowExternalIncomingTraffic: true
Para ativar a replicação no cluster de banco de dados secundário, aplique um manifesto semelhante ao seguinte ao cluster do Kubernetes no data center 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: setup
Substitua o seguinte:
SECONDARY_DB_CLUSTER_NAME
: o nome do cluster de banco de dados secundário, por exemplo,dbc-2
.ENCODED_PASSWORD
: a senha do usuário do banco de dados a ser usada para replicar o cluster de banco de dados primário, codificada como uma string base64, por exemplo,Q2hhbmdlTWUxMjM= for ChangeMe123
. O valor padrão éalloydbreplica
.SECONDARY_REPLICATION_NAME
: o nome da replicação, por exemplo,replication-2
.PRIMARY_HOST
: o endpoint de conexão do cluster de banco de dados primário da resposta na etapa 3, que o banco de dados secundário pode acessar para replicação.PRIMARY_PORT
: a porta de conexão do cluster de banco de dados primário da resposta na etapa 3, que o banco de dados secundário pode acessar para replicação.PRIMARY_REPLICATION_SLOT
: o nome do slot de replicação no cluster de banco de dados primário da resposta na etapa 3 que o banco de dados secundário pode usar para replicação.
Visualizar a replicação no cluster de banco de dados secundário
Para visualizar informações detalhadas sobre um cluster de banco de dados secundário do AlloyDB Omni e o status de replicação dele, execute os seguintes comandos:
Kubernetes
kubectl get dbcluster SECONDARY_DB_CLUSTER_NAME
kubectl get replication SECONDARY_REPLICATION_NAME
Quando o cluster de banco de dados secundário é configurado e tem replicação de transmissão do cluster de banco de dados primário, o status da replicação é "Pronto" e "Íntegro".
Promover um cluster de banco de dados secundário
Antes de promover um cluster de banco de dados secundário, siga estas etapas para verificar se ele aplicou todas as transações recebidas do cluster primário:
Kubernetes
Verifique o status da replicação do cluster de banco de dados secundário para garantir que ele seja "Pronto" e "Íntegro".
kubectl get replication SECONDARY_REPLICATION_NAME
Interrompa todas as gravações no cluster de banco de dados primário. Execute a consulta a seguir no cluster de banco de dados primário para verificar o atraso de replicação do banco de dados secundário. Confirme se o resultado mostra um atraso mínimo.
O ideal é um valor de atraso igual a 0. Se o atraso for maior que 0, ainda será possível promover o cluster de banco de dados secundário, mas há o risco de perder algumas transações recentes já confirmadas no cluster de banco de dados primário.
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 banco de dados secundário a um cluster de banco de dados primário, atualize o campo control do manifesto de replicação do cluster de banco de dados secundário para promote
e aplique isso no cluster do Kubernetes no data center 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
Realizar uma troca
Antes de realizar uma troca, verifique se os clusters de banco de dados primário e secundário pertencentes aos dois data centers estão on-line e em um estado íntegro.
Para garantir a consistência dos dados dos clusters de banco de dados primário e secundário durante a troca, siga estas etapas para verificar se o cluster de banco de dados secundário aplicou todas as transações recebidas do cluster de banco de dados primário:
Kubernetes
Verifique o status da replicação do cluster de banco de dados secundário para garantir que ele seja "Pronto" e "Íntegro".
kubectl get replication SECONDARY_REPLICATION_NAME
Interrompa todas as gravações no cluster de banco de dados primário. Execute a consulta a seguir no cluster de banco de dados primário para verificar o atraso de replicação do banco de dados secundário. Confirme se o resultado mostra um valor de atraso igual a
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 realizar uma troca, siga estas etapas:
Kubernetes
Para converter o cluster de banco de dados secundário do AlloyDB Omni em um cluster de banco de dados primário, atualize o manifesto de replicação no cluster do Kubernetes no data center secundário da seguinte maneira:
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_NAME
Aguarde até que o status da replicação seja "Pronto".
Para receber as informações de conexão upstream da replicação, execute o seguinte comando:
kubectl get replication SECONDARY_REPLICATION_NAME
kubectl get replication SECONDARY_REPLICATION_NAME -o json | jq .status.upstream
Um exemplo de resposta é parecido com este:
{ "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 banco de dados primário do AlloyDB Omni em um cluster de banco de dados secundário, atualize o manifesto de replicação no cluster do Kubernetes no data center primário, desta forma:
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: rewind
Aguarde até que o status da replicação seja "Pronto" e "Íntegro".
Para verificar o status da replicação, use:
kubectl get replication REPLICATION_NAME