O Cloud SQL permite-lhe restaurar as suas instâncias a partir de uma cópia de segurança ou através da execução da recuperação pontual (PITR). Isto permite-lhe recuperar uma instância para um período ou uma hora específicos, restaurando a cópia de segurança para uma instância existente ou para uma nova instância. Para restaurar, pode usar a cópia de segurança de uma instância ativa ou eliminada. A operação de restauro usa as definições, as bases de dados e os utilizadores da instância de origem e define-os na instância de destino que escolher.
Quando faz o restauro para uma nova instância, a instância de destino pode estar numa região ou num projeto diferente da instância de origem. A instância de destino também pode usar um número diferente de núcleos ou uma quantidade de memória diferente da instância de origem.
O Cloud SQL define sempre a capacidade de armazenamento da instância de destino para o valor máximo do tamanho do disco configurado e do disco de cópia de segurança. O disco de cópia de segurança tem o tamanho do disco quando a cópia de segurança é feita.
Quando fizer um restauro numa instância, tenha em atenção o seguinte:
- A operação de restauro substitui todos os dados na instância de destino.
- As flags da instância de origem não são restauradas. Todas as flags definidas anteriormente na instância de destino são mantidas após o restauro.
- A instância de destino não está disponível para ligações durante a operação de restauro. As ligações existentes são perdidas.
- Se estiver a restaurar para uma instância com réplicas de leitura, tem de eliminar todas as réplicas e recriá-las após a conclusão da operação de restauro.
- A operação de restauro reinicia a instância.
- Depois de restaurar a partir de uma cópia de segurança, as configurações de cópia de segurança da instância de destino são definidas como valores predefinidos. Se a instância de origem tiver configurações de cópias de segurança personalizadas ou estiver a usar cópias de segurança melhoradas, tem de atualizar as configurações de cópias de segurança após a conclusão da restauração.
Restaurar através de uma cópia de segurança
O Cloud SQL permite-lhe restaurar uma instância através de uma cópia de segurança. Pode usar uma cópia de segurança de uma instância ativa ou eliminada e usá-la para restaurar uma instância nova ou existente. Pode usar qualquer cópia de segurança disponível para restaurar a instância. Para saber mais sobre como funcionam as cópias de segurança no Cloud SQL, consulte a Vista geral das cópias de segurança.
Quando restaura uma instância através de uma cópia de segurança, pode fazer o seguinte:
- Restaurar para uma nova instância
- Restaurar para uma instância existente
- Restaurar para uma instância noutro projeto ou região
Em caso de indisponibilidade, pode continuar a aceder a uma lista de cópias de segurança num projeto específico a partir da qual restaurar.
Para restaurar a sua instância através de uma cópia de segurança, consulte o artigo Restaure uma instância através de uma cópia de segurança.
Recuperação pontual (PITR)
A PITR permite-lhe restaurar a sua instância para um momento específico da base de dados. Por exemplo, se um erro causar uma perda de dados, pode recuperar uma base de dados para o estado em que se encontrava antes de o erro ocorrer. Ao contrário do restauro através de uma cópia de segurança, a PITR cria sempre uma nova instância. Não pode fazer uma PITR para uma instância existente. A nova instância herda as definições da instância de origem, de forma semelhante ao que acontece quando cria um clone.
Se criar uma instância da edição Enterprise Plus do Cloud SQL, a PITR é ativada por predefinição. Tem de desativar a funcionalidade manualmente.
Se criar uma instância da edição Enterprise do Cloud SQL na Google Cloud consola, a PITR é ativada por predefinição. Caso contrário, se criar a instância através da CLI gcloud, do Terraform ou da API Cloud SQL Admin, a PITR está desativada por predefinição. Para ativar a PITR para estas instâncias, tem de a ativar manualmente.
Para receber instruções passo a passo sobre como realizar a PITR, consulte o artigo Use a recuperação pontual (PITR).
Armazenamento de registos para PITR
A PITR usa para arquivar registos. Quando restaura uma instância existente através de uma cópia de segurança, estes registos de arquivo são eliminados e não estão disponíveis para realizar uma PITR. Só é possível usar para PITR os novos registos gerados após a conclusão do restauro.
A 31 de maio de 2024, lançámos o armazenamento de registos de transações para PITR no Cloud Storage. Desde este lançamento, aplicam-se as seguintes condições:
Todas as instâncias da edição Cloud SQL Enterprise Plus armazenam os respetivos registos de transações usados para PITR no Cloud Storage. Apenas as instâncias da edição Cloud SQL Enterprise Plus que atualizou a partir da edição Cloud SQL Enterprise antes de 1 de abril de 2024 e que tinham o PITR ativado antes de 31 de maio de 2024 continuam a armazenar os respetivos registos para PITR no disco.
As instâncias da edição Enterprise do Cloud SQL criadas com a PITR ativada antes de 31 de maio de 2024 continuam a armazenar os respetivos registos para a PITR no disco.
Se atualizar uma instância da edição Cloud SQL Enterprise após 31 de maio de 2024 que armazena registos de transações para PITR no disco para a edição Cloud SQL Enterprise Plus, o processo de atualização muda a localização de armazenamento dos registos de transações usados para PITR para o Cloud Storage. Para mais informações, consulte o artigo Atualize uma instância para a edição Cloud SQL Enterprise Plus através da atualização no local.
Todas as instâncias da edição Enterprise do Cloud SQL que criar com a PITR ativada após 31 de maio de 2024 armazenam registos usados para a PITR no Cloud Storage.
Se a sua instância usar o Cloud Storage para armazenar registos de transações, os registos são armazenados na mesma região que a instância principal. Estes registos são armazenados durante um máximo de 35 dias para a edição Cloud SQL Enterprise Plus e 7 dias para a edição Cloud SQL Enterprise, e não geram custos adicionais por instância.
Para mais informações sobre como verificar a localização do armazenamento dos registos de transações usados para PITR, consulte o artigo verifique onde os registos de transações estão armazenados para a sua instância.
Para instâncias que armazenam registos de transações apenas no disco, pode mudar a localização de armazenamento dos registos de transações usados para PITR do disco para o Cloud Storage através da CLI gcloud ou da API Cloud SQL Admin. Para mais informações, consulte o artigo Mude o armazenamento do registo de transações para o Cloud Storage.
Para garantir que os registos da sua instância são armazenados no Cloud Storage em vez de no disco, conclua as seguintes ações:
- Verifique a arquitetura de rede da instância. Se a instância estiver na arquitetura de rede antiga, atualize-a para a nova arquitetura de rede.
Se o tamanho dos registos no disco estiver a causar problemas de desempenho na sua instância, desative o PITR e volte a ativá-lo. Esta ação garante que os novos registos são armazenados no Cloud Storage em vez de no disco.
Período de retenção de registos
O Cloud SQL retém os registos de transações no Cloud Storage até ao valor definido na definição de configuração de PITR transactionLogRetentionDays. Este valor pode variar entre 1 e 35 dias para a edição Cloud SQL Enterprise Plus e entre 1 e 7 dias para a edição Cloud SQL Enterprise. Se não for definido um valor para este parâmetro, o período de retenção do registo de transações predefinido é de 14 dias para instâncias da edição Cloud SQL Enterprise Plus e de 7 dias para instâncias da edição Cloud SQL Enterprise. Para mais
informações sobre como definir os dias de retenção do registo de transações,
consulte o artigo Defina a retenção do registo de transações.
Embora uma instância armazene os registos de transações usados para PITR no Cloud Storage, a instância também mantém um número menor de registos de transações duplicados no disco para permitir a replicação dos registos no Cloud Storage. Por predefinição, quando cria uma instância com a PITR ativada, a instância armazena os respetivos registos de transações para a PITR no Cloud Storage. O Cloud SQL também define o valor das flags expire_logs_days e binlog_expire_logs_seconds para o equivalente a um dia automaticamente. Isto traduz-se num dia de registos no disco.
Para registos de transações PITR armazenados no disco, que estão a ser comutados para o Cloud Storage ou que já foram comutados para o Cloud Storage, o Cloud SQL retém os registos durante o valor mínimo definido para uma das seguintes configurações:
- A definição de configuração de cópia de segurança
transactionLogRetentionDays - A bandeira
expire_logs_daysou a bandeirabinlog_expire_logs_seconds
O Cloud SQL não define valores para estes flags se os registos de transações estiverem armazenados no disco, estiverem a ser mudados para o Cloud Storage ou já tiverem sido mudados para o Cloud Storage. Quando os registos são armazenados no disco, a modificação dos valores destas flags pode afetar o comportamento da recuperação PITR e o número de dias de registos armazenados no disco. Enquanto a localização de armazenamento de registos estiver a ser
alterada para o Cloud Storage, não pode modificar os valores das flags.
Também não recomendamos que configure nenhum valor de flag para 0. Para mais
informações, consulte o artigo
Configure as flags da base de dados.
transactionLogRetentionDaysde configuraçãoexpire_logs_daysbase de dadosbinlog_expire_logs_secondsbase de dados
Por exemplo, para evitar problemas de desempenho, reduza o valor das flags em um dia, todos os dias, durante vários dias. Consequentemente, o Cloud SQL não limpa todos os registos de transações em simultâneo.
Para
instâncias com a chave de encriptação gerida pelo cliente (CMEK) ativada,
os registos de transações são encriptados com a versão mais recente da
CMEK. Para fazer um restauro, é necessária a versão mais recente da chave para todos os dias
retidos como parte do parâmetro retained-transaction-log-days.
Limitações da PITR
As seguintes limitações estão associadas à ativação da PITR na sua instância e ao tamanho dos registos de transações no disco, o que causa um problema para a sua instância:
- Pode desativar a PITR e reativá-la para garantir que o Cloud SQL armazena registos no Cloud Storage na mesma região que a instância. No entanto, o Cloud SQL elimina todos os registos existentes, pelo que não pode executar uma operação PITR antes da hora em que reativou a PITR.
- Pode aumentar o tamanho do armazenamento da instância, mas o aumento do tamanho do registo de transações no disco pode ser temporário.
- Para evitar problemas de armazenamento inesperados, recomendamos que ative os aumentos automáticos de armazenamento. Esta recomendação aplica-se apenas se a sua instância tiver a PITR ativada e os registos estiverem armazenados no disco.
Instantâneos de bases de dados
Não pode usar instantâneos da base de dados do SQL Server em nenhuma base de dados numa instância em que a PITR esteja ativada.
As imagens instantâneas da base de dados podem interferir com a cópia de segurança completa da base de dados e a cópia de segurança do registo de transações, das quais a PITR depende. Esta interferência pode impedir operações PITR bem-sucedidas para qualquer base de dados na instância.
Modelo de recuperação da base de dados para PITR
Se ativar a PITR numa instância, o Cloud SQL define automaticamente o modelo de recuperação das bases de dados existentes e subsequentes para o modelo de recuperação completo.
Para mais informações sobre os modelos de recuperação do SQL Server, consulte a documentação da Microsoft.
Para receber instruções passo a passo sobre como realizar a PITR, consulte o artigo [Use a recuperação num ponto específico no tempo (PITR)][perform-pitr].
Restaure uma instância eliminada através da PITR
Pode usar a PITR para restaurar uma instância do Cloud SQL após a eliminação. Para usar esta funcionalidade, a sua instância tem de ter o PITR e as cópias de segurança retidas ativados antes de a instância ser eliminada. Quando ativado, os registos de PITR são retidos após a eliminação da instância.
Após a eliminação de uma instância, os registos de PITR continuam a seguir as definições de retenção definidas pela instância quando estava ativa. Os registos de PITR expiram com base nas definições de retenção de forma contínua após a eliminação da instância. O período contínuo é definido com base no período de retenção da PITR definido na instância antes da eliminação. Por exemplo, se a sua instância da edição Cloud SQL Enterprise Plus tiver a retenção de PITR definida para 14 dias, o registo de PITR mais recente é eliminado 14 dias após a eliminação da instância. Quando um registo PITR expira, não é possível recuperá-lo.
Uma vez que os nomes das instâncias podem ser reutilizados depois de uma instância ser eliminada no Cloud SQL, os registos de PITR retidos podem ser identificados em Google Cloud com os seguintes campos:
instance_deletion_timelog_retention_days
Estes campos permitem-lhe identificar se um registo PITR pertence a uma instância eliminada.
O período de recuperação PITR é definido como os horários de recuperação mais antigos e mais recentes disponíveis para restaurar a sua instância através da PITR. Para encontrar as horas de recuperação mais antigas e mais recentes da instância eliminada, consulte o artigo Obtenha a hora de recuperação mais antiga e mais recente.
Para restaurar uma instância através da PITR após a eliminação da instância, consulte o artigo Realize uma PITR numa instância eliminada.
Requisitos para a restrição a uma nova instância
Quando restaura a sua instância para uma nova instância, tenha em atenção os seguintes requisitos:
A instância de destino tem de ter a mesma versão da base de dados que a instância a partir da qual foi feita a cópia de segurança.
A capacidade de armazenamento da instância de destino tem de ser, pelo menos, tão grande quanto a capacidade da instância da qual está a ser feito uma cópia de segurança. A quantidade de armazenamento usado não tem importância. Pode ver a capacidade de armazenamento da instância na página Instâncias do Cloud SQL da consola. Este requisito aplica-se quer esteja ou não a fazer PITR de uma única base de dados.
A instância de destino tem de estar no estado
RUNNABLE.
Restaurar limitações de taxa
São permitidas, no máximo, três operações de restauro a cada 30 minutos por instância, por região e por projeto. Se uma operação de restauro falhar, não é contabilizada para esta quota. Se atingir o limite, a operação falha com uma mensagem de erro que indica quando pode executar a operação novamente.
O Cloud SQL usa tokens de um contentor para determinar quantas operações de restauro estão disponíveis em qualquer altura. Para cada cópia de segurança, existe um contentor para cada projeto de destino e região de destino. As instâncias de destino do mesmo projeto partilham um contentor se estiverem na mesma região. Existe um máximo de três tokens em cada contentor que pode usar para operações de restauro. A cada 10 minutos, é adicionado um novo token ao contentor. Se o limite for atingido, o token excede o limite.
Sempre que emite uma operação de restauro, é concedido um token do contentor. Se a operação for bem-sucedida, o token é removido do contentor. Se falhar, o token é devolvido ao depósito. O diagrama seguinte mostra como funciona:
Por exemplo, na figura seguinte, Backup1, Backup2 e Backup3 são as cópias de segurança da mesma instância de origem.
- Cada cópia de segurança (Backup1, Backup2 e Backup3) tem o seu próprio conjunto de tokens para operações de restauro que segmentam instâncias diferentes no projeto 1 na região A (Bucket11A, Bucket21A e Bucket31A). Uma vez que cada cópia de segurança tem o seu próprio contentor, pode restaurar cada cópia de segurança para a mesma instância três vezes a cada trinta minutos.
- Cada cópia de segurança tem um contentor para um projeto separado e para uma região separada.
Por exemplo, se existirem cinco projetos numa região, existem cinco contentores para essa cópia de segurança nessa região, um em cada projeto. Na figura anterior, temos dois projetos na região A: o projeto 1 e o projeto n.
- Backup1 tem dois contentores de tokens para operações de restauro na região A. Um contentor para o projeto 1 (Bucket11A) e um contentor para o projeto n (Bucket1nA).
- Da mesma forma, o Backup3 tem dois contentores para operações de restauro na região A. Um para o projeto 1 (Bucket31A) e um para o projeto n (Bucket3nA).
- Backup3 tem um contentor na região B, para o Project1, porque todas as instâncias no mesmo projeto de destino e na mesma região de destino partilham um contentor.