Esta página descreve como usar e promover réplicas de leitura entre regiões (réplicas criadas numa região diferente da região primária) para a migração regional ou a recuperação de desastres.
Vista geral
Existem dois cenários comuns para promover réplicas entre regiões:
- Migração regional: execute uma migração planeada de uma base de dados para uma região diferente.
- Recuperação de desastres: comutação de uma base de dados para outra região no caso de a região principal ficar indisponível.
Ambos os exemplos de utilização envolvem a configuração da replicação entre regiões e, em seguida, a promoção da réplica. A principal diferença entre elas é se a promoção da réplica é planeada (no caso da migração regional) ou não planeada (é necessária uma comutação por falha para a região da réplica para continuar as operações porque a principal ficou indisponível).
Migração regional
Pode usar uma réplica entre regiões para migrar a sua base de dados para outra região com um tempo de inatividade mínimo. A ideia geral é criar uma réplica noutra região, aguardar até que a replicação seja atualizada, promovê-la e, em seguida, direcionar os clientes para a instância recentemente promovida.
Os passos envolvidos na promoção são os mesmos que para promover uma réplica na região. Siga essas instruções para garantir que a instância recentemente promovida tem todas as transações que foram confirmadas na instância principal original. Depois de promover a réplica e verificar que a instância recém-promovida está a funcionar, atualize todos os clientes da base de dados para estabelecer ligação à nova instância.
Recuperação de desastres (RD)
As réplicas entre regiões podem ser usadas como parte de um procedimento de recuperação de desastres. Pode promover uma réplica entre regiões para fazer failover para outra região se a região da instância principal ficar indisponível durante um período prolongado.
Para mais informações sobre a recuperação de desastres, consulte o artigo Acerca da recuperação de desastres no Cloud SQL.
Recuperação de desastres (RD) avançada
Se estiver a usar a edição Cloud SQL Enterprise Plus, pode designar uma réplica de leitura entre regiões como uma réplica de recuperação de desastres (réplica de RD) para recuperação de desastres (RD) avançada. Com a recuperação de desastres avançada, faz uma comutação por falha da réplica para substituir a instância principal pela réplica de recuperação de desastres designada. A instância principal antiga torna-se uma réplica da réplica de DR promovida. Só pode fazer a comutação por falha da réplica para a réplica de recuperação de desastres designada. Pode continuar a promover outras réplicas de leitura sem comutação por falha.
Para devolver a implementação ao estado original após a comutação por falha da réplica sem perda de dados, pode fazer uma comutação. Uma vez que a instância principal antiga é uma réplica da nova instância principal, pode voltar a trocar as funções para restaurar a instância principal antiga.
Para mais informações, consulte o artigo Recuperação de desastres (RD) avançada.
Valide os critérios de comutação por falha
Uma vez que a replicação é assíncrona, quando ocorre uma indisponibilidade da região e é tentada uma comutação por falha, algumas transações recentes que foram confirmadas na base de dados principal podem ser perdidas (não replicadas para a réplica). Sempre que uma instância principal fica indisponível, os passos seguintes mostram (1) como determinar a quantidade de dados, se existirem, que podem ter sido perdidos na comutação por falha entre regiões e (2) como garantir que a réplica promovida reflete o maior número possível de gravações recentes.
Primeiro, verifique os valores Lag Bytes no painel de controlo de monitorização. Quando existe uma indisponibilidade regional na região da instância principal, é comunicado o erro Lag Bytes para a instância principal.
Em seguida, ligue-se à instância da réplica com um cliente PostgreSQL seguindo as instruções na página estado da replicação (consulte o separador cliente psql). Consulte as instruções relativas às métricas pg_catalog.pg_last_wal_receive_lsn() e pg_catalog.pg_last_wal_replay_lsn(). Verifique se a réplica processou todas as transações que recebeu da base de dados principal.
Isto garante que, quando promovida, a réplica reflete todas as transações que foram recebidas antes de a base de dados primária ficar indisponível.
Promova uma réplica de leitura
Depois de determinar que os critérios de comutação por falha foram cumpridos, pode promover uma das réplicas a uma instância autónoma gravável. Considere o seguinte cenário:
- A região A (us-central1) tem uma instância principal de alta disponibilidade (db-a-0)
- A região B (us-west1) tem uma réplica entre regiões de alta disponibilidade (db-b-1) de db-a-0
- A região C (us-east1) tem uma réplica entre regiões (db-c-1) de db-a-0
Pode optar por promover db-b-1 na região B para se tornar uma instância autónoma gravável.
Consulte o artigo Promover uma réplica para ver instruções detalhadas.
Certifique-se de que o tipo de máquina é adequado
Certifique-se de que o tipo de máquina da instância recentemente promovida é adequado para a respetiva carga de trabalho monitorizando as métricas na instância, como a utilização de CPU e memória. Se a instância recém-promovida for mais pequena do que a sua antiga instância principal, recomendamos que redimensione a instância promovida para corresponder à sua antiga instância principal, de modo a poder processar a mesma quantidade de carga.
Ative a elevada disponibilidade para a instância promovida
Para uma configuração de recuperação de desastres, recomendamos que configure a réplica que pretende promover como uma réplica de alta disponibilidade. Em alternativa, configure a instância recém-promovida como de elevada disponibilidade. Se optar por não configurar a réplica de leitura com elevada disponibilidade, também pode configurar a instância com elevada disponibilidade se e quando a promover.
Quando são promovidas, as réplicas de leitura são configuradas automaticamente com cópias de segurança. A configuração de uma réplica de leitura para alta disponibilidade é feita da mesma forma que para uma instância principal. Para mais informações, consulte o artigo sobre configurar a instância para alta disponibilidade.
Recrie réplicas adicionais
Se promover uma réplica para se tornar uma instância principal, tem de recriar todas as outras réplicas da antiga instância principal. Por exemplo, considere a configuração referenciada anteriormente e repetida aqui:
- A região A (us-central1) tem uma instância principal de alta disponibilidade (db-a-0)
- A região B (us-west1) tem uma réplica entre regiões (db-b-1) de db-a-0
- A região C (us-east1) tem uma réplica entre regiões (db-c-1) de db-a-0
Se a instância principal (db-a-0) ficar indisponível, pode promover a réplica na região B para se tornar a principal. Para ter novamente réplicas adicionais nas regiões A e C, elimine as instâncias antigas (a antiga instância principal em A e a réplica em C) e crie novas réplicas de leitura a partir da nova instância principal em B.
A configuração resultante seria:
- A região A (us-central1) tem agora uma réplica entre regiões (db-a-1)
- A região B (us-west1) tem agora a instância principal (db-b-1)
- A região C (us-east1) tem agora uma nova réplica entre regiões (db-c-2)