Esta página descreve como usar a recuperação num determinado momento (PITR) para restaurar a instância principal do Cloud SQL.
Para saber mais acerca da PITR, consulte o artigo Recuperação pontual (PITR).
Se criar uma instância da edição Enterprise Plus do Cloud SQL, a PITR é ativada por predefinição, independentemente do método usado para a criação. Se quiser desativar a funcionalidade, tem de o fazer manualmente.
Se criar uma instância da edição Enterprise do Cloud SQL na Trusted 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. Neste caso, se quiser ativar a funcionalidade, tem de o fazer manualmente.
Armazenamento de registos para PITR
O Cloud SQL usa registos binários para a PITR.A 11 de agosto de 2023, 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 binários 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 a PITR ativada antes de 11 de agosto de 2023 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 11 de agosto de 2023 continuam a armazenar os respetivos registos para PITR no disco.
Se atualizar uma instância da edição Cloud SQL Enterprise após 1 de abril 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 11 de agosto de 2023 armazenam registos usados para a PITR no Cloud Storage.
Para mais informações sobre como verificar a localização de armazenamento dos registos de transações usados para a PITR, consulte o artigo Verifique a localização de armazenamento dos registos de transações usados para a PITR.
Para instâncias que armazenam registos binários 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 sem incorrer em qualquer tempo de inatividade. Para mais informações, consulte o artigo Mude o armazenamento do registo de transações para o Cloud Storage.
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 predefinido dos registos de transações é 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 binários usados para PITR no Cloud Storage, a instância também mantém um número menor de registos binários 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 binários para a PITR
no Cloud Storage. O Cloud SQL também define o valor das flags expire_logs_days
e binlog_expire_logs_seconds
como o equivalente a um dia automaticamente. Isto traduz-se num dia de registos no disco.
Para registos binários de 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 pelo 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_days
ou a bandeirabinlog_expire_logs_seconds
O Cloud SQL não define valores para estas flags se os registos binários estiverem armazenados no disco, estiverem a ser comutados para o Cloud Storage ou já tiverem sido comutados 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 está 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.
Para
instâncias com a chave de encriptação gerida pelo cliente (CMEK) ativada, os registos binários são encriptados com a versão mais recente da CMEK. Para fazer um restauro, todas as versões da chave que foram as versões mais recentes durante o número de dias que configurou para o parâmetro
retained-transaction-log-days
têm de estar disponíveis.
Registos e utilização do disco
Os registos são gerados regularmente e usam espaço de armazenamento. Os registos binários são eliminados automaticamente com a respetiva cópia de segurança automática, o que acontece após o valor definido para transactionLogRetentionDays
ser atingido.
Para saber a quantidade de espaço em disco que está a ser usado pelos registos binários,
verifique a métrica bytes_used_by_data_type
para a instância. O valor do tipo de dados binlog
devolve o tamanho dos registos binários no disco. Para instâncias que armazenam registos de transações
usados para PITR no disco,
o Cloud SQL limpa os dados do disco diariamente para cumprir a
transactionLogRetentionDays
definição de PITR,
conforme descrito em Cópia de segurança automática e retenção de registos de transações.
No entanto, se definir a flag expire_logs_days
ou binlog_expire_logs_seconds
para um valor inferior aos dias de retenção do registo de transações, o Cloud SQL pode limpar os registos binários mais cedo.
Se o tamanho dos registos binários estiver a causar um problema na sua instância:
- Verifique se a sua instância está a armazenar registos no disco. Pode mudar a localização de armazenamento dos registos que o Cloud SQL usa para a PITR do disco para o Cloud Storage sem tempo de inatividade através da CLI gcloud ou da API Cloud SQL Admin. Se estiver a usar a edição Enterprise do Cloud SQL, também pode atualizar para a edição Enterprise Plus do Cloud SQL para alterar a localização de armazenamento dos seus registos de PITR.
Pode aumentar o tamanho do armazenamento da instância. No entanto, o aumento do tamanho do registo binário na utilização do disco pode ser temporário.
Recomendamos que ative o aumento automático do armazenamento para evitar problemas de armazenamento inesperados.
Se quiser eliminar registos e recuperar espaço de armazenamento no disco, pode desativar a PITR sem a reativar. No entanto, a diminuição do armazenamento usado não reduz o tamanho do disco aprovisionado para a instância.
Os registos são eliminados uma vez por dia e não de forma contínua. A definição da retenção de registos para dois dias significa que são retidos, pelo menos, dois dias de registos e, no máximo, três dias de registos. Recomendamos que defina o número de cópias de segurança como um valor superior ao número de dias de retenção de registos.
Por exemplo, se especificar
7
para o valor do parâmetrotransactionLogRetentionDays
, para o parâmetrobackupRetentionSettings
, defina o número deretainedBackups
como8
.
Para mais informações sobre a PITR, consulte o artigo Recuperação pontual (PITR).
Depois de concluir a mudança da localização de armazenamento dos registos de transações para o Cloud Storage,
pode libertar espaço em disco reduzindo os valores das flags
expire_logs_days
ou binlog_expire_logs_seconds
. Para verificar o estado do comutador, consulte o artigo
Verifique a localização de armazenamento dos registos de transações usados para PITR.
Se quiser que estejam disponíveis registos adicionais no disco, por exemplo, para procurar os registos binários com a utilidade mysqlbinlog
, aumente os valores destas flags. O Cloud SQL retém registos binários no disco durante o mínimo dos dias de retenção do registo de transações ou os valores definidos para as flags. Para mais informações sobre como os registos da PITR são armazenados após a mudança e como libertar espaço em disco, consulte o artigo Registos após a mudança para o Cloud Storage.
Ative a PITR
Quando cria uma nova instância na Trusted Cloud consola, as opções Cópias de segurança automáticas e Ativar recuperação num ponto específico no tempo são ativadas automaticamente.O procedimento seguinte ativa a PITR numa instância principal existente.
Consola
-
Na Trusted Cloud consola, aceda à página Instâncias do Cloud SQL.
- Abra o menu de mais ações
para a instância na qual quer ativar a PITR e clique em Editar.
- Em Personalize a sua instância, expanda a secção Proteção de dados.
- Selecione a caixa de verificação Ativar recuperação num ponto específico no tempo.
- No campo Dias de registos, introduza o número de dias para reter registos, de 1 a 35 para a edição Cloud SQL Enterprise Plus ou de 1 a 7 para a edição Cloud SQL Enterprise.
- Clique em Guardar.
gcloud
- Apresente a vista geral da instância:
gcloud sql instances describe INSTANCE_NAME
- Se vir
enabled: false
na secçãobackupConfiguration
, ative as cópias de segurança agendadas:gcloud sql instances patch INSTANCE_NAME \ --backup-start-time=HH:MM
Especifique o parâmetro
backup-start-time
com a hora no formato de 24 horas no fuso horário UTC±00. - Ativar PITR:
gcloud sql instances patch INSTANCE_NAME \ --enable-bin-log
Se estiver a ativar a PITR numa instância principal, também pode configurar o número de dias durante os quais quer reter os registos de transações adicionando o seguinte parâmetro:
--retained-transaction-log-days=RETAINED_TRANSACTION_LOG_DAYS
- Confirme a alteração:
gcloud sql instances describe INSTANCE_NAME
Na secção
backupConfiguration
, vêbinaryLogEnabled: true
se a alteração foi bem-sucedida.
Terraform
Para ativar a PITR, use um recurso do Terraform.
Aplique as alterações
Para aplicar a configuração do Terraform num Trusted Cloud projeto, conclua os passos nas secções seguintes.
Prepare o Cloud Shell
- Inicie o Cloud Shell.
-
Defina o Trusted Cloud projeto predefinido onde quer aplicar as suas configurações do Terraform.
Só tem de executar este comando uma vez por projeto e pode executá-lo em qualquer diretório.
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
As variáveis de ambiente são substituídas se definir valores explícitos no ficheiro de configuração do Terraform.
Prepare o diretório
Cada ficheiro de configuração do Terraform tem de ter o seu próprio diretório (também denominado módulo raiz).
-
No Cloud Shell, crie um diretório e um novo ficheiro nesse diretório. O nome do ficheiro tem de ter a extensão
.tf
, por exemplo,main.tf
. Neste tutorial, o ficheiro é denominadomain.tf
.mkdir DIRECTORY && cd DIRECTORY && touch main.tf
-
Se estiver a seguir um tutorial, pode copiar o código de exemplo em cada secção ou passo.
Copie o exemplo de código para o ficheiro
main.tf
criado recentemente.Opcionalmente, copie o código do GitHub. Isto é recomendado quando o fragmento do Terraform faz parte de uma solução completa.
- Reveja e modifique os parâmetros de exemplo para aplicar ao seu ambiente.
- Guarde as alterações.
-
Inicialize o Terraform. Só tem de fazer isto uma vez por diretório.
terraform init
Opcionalmente, para usar a versão mais recente do fornecedor Google, inclua a opção
-upgrade
:terraform init -upgrade
Aplique as alterações
-
Reveja a configuração e verifique se os recursos que o Terraform vai criar ou
atualizar correspondem às suas expetativas:
terraform plan
Faça correções à configuração conforme necessário.
-
Aplique a configuração do Terraform executando o seguinte comando e introduzindo
yes
no comando:terraform apply
Aguarde até que o Terraform apresente a mensagem "Apply complete!" (Aplicação concluída!).
- Abra o seu Trusted Cloud projeto para ver os resultados. Na Trusted Cloud consola, navegue para os seus recursos na IU para se certificar de que o Terraform os criou ou atualizou.
Eliminar as alterações
Para eliminar as alterações, faça o seguinte:
- Para desativar a proteção contra eliminação, no ficheiro de configuração do Terraform, defina o argumento
deletion_protection
comofalse
.deletion_protection = "false"
- Aplique a configuração do Terraform atualizada executando o seguinte comando e
introduzindo
yes
no comando:terraform apply
-
Remova os recursos aplicados anteriormente com a sua configuração do Terraform executando o seguinte comando e introduzindo
yes
no comando:terraform destroy
REST v1
Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:
- PROJECT_ID: o ID ou o número do projeto do Trusted Cloud projeto que contém a instância
- INSTANCE_NAME: o nome da instância principal ou de réplica de leitura que está a configurar para alta disponibilidade
- START_TIME: a hora (em horas e minutos)
Método HTTP e URL:
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME
Corpo JSON do pedido:
{ "settings": { "backupConfiguration": { "startTime": "START_TIME", "enabled": true, "binaryLogEnabled": true } } }
Para enviar o seu pedido, expanda uma destas opções:
Deve receber uma resposta JSON semelhante à seguinte:
REST v1beta4
Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:
- PROJECT_ID: o ID ou o número do projeto do Trusted Cloud projeto que contém a instância
- INSTANCE_NAME: o nome da instância principal ou de réplica de leitura que está a configurar para alta disponibilidade
- START_TIME: a hora (em horas e minutos)
Método HTTP e URL:
PATCH https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME
Corpo JSON do pedido:
{ "settings": { "backupConfiguration": { "startTime": "START_TIME", "enabled": true, "binaryLogEnabled": true } } }
Para enviar o seu pedido, expanda uma destas opções:
Deve receber uma resposta JSON semelhante à seguinte:
Efetue a PITR numa instância indisponível
Consola
Recomendamos que recupere uma instância que não está disponível para uma zona diferente pelos seguintes motivos:
- A zona na qual a instância está configurada não está acessível. Esta instância tem um estado
FAILED
. - A instância está a ser alvo de manutenção. Esta instância tem um estado
MAINTENANCE
.
Para recuperar uma instância indisponível, conclua os seguintes passos:
-
Na Trusted Cloud consola, aceda à página Instâncias do Cloud SQL.
- Encontre a linha da instância a clonar.
- Na coluna Ações, clique no menu Mais ações.
- Clique em Criar clone.
- Na página Criar um clone, conclua as seguintes ações:
- No campo ID da instância, atualize o ID da instância, se necessário.
- Clique em Clonar a partir de um ponto anterior no tempo.
- No campo Ponto no tempo, selecione uma data e uma hora a partir das quais quer clonar os dados. Esta ação recupera o estado da instância a partir desse momento.
- Clique em Criar clone.
Enquanto o clone é inicializado, regressa à página de listagem de instâncias.
gcloud
Pode querer recuperar uma instância que não está disponível para uma zona diferente porque a zona na qual a instância está configurada não está acessível.
gcloud sql instances clone SOURCE_INSTANCE_NAME TARGET_INSTANCE_NAME \ --point-in-time DATE_AND_TIME_STAMP \ --preferred-zone ZONE_NAME \ --preferred-secondary-zone SECONDARY_ZONE_NAME
O utilizador ou a conta de serviço que está a executar o comando gcloud sql instances clone
tem de ter a autorização cloudsql.instances.clone
. Para mais informações sobre as autorizações necessárias para executar comandos da CLI gcloud, consulte o artigo Autorizações do Cloud SQL.
REST v1
Pode querer recuperar uma instância que não está disponível para uma zona diferente porque a zona na qual a instância está configurada não está acessível.
Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:
- PROJECT_ID: o ID do projeto
- SOURCE_INSTANCE_ID: o ID da instância da origem
- TARGET_INSTANCE_ID: o ID da instância de destino
Método HTTP e URL:
POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/SOURCE_INSTANCE_NAME/clone
Corpo JSON do pedido:
{ "cloneContext": { "destinationInstanceName": "TARGET_INSTANCE_ID" } }
Para enviar o seu pedido, expanda uma destas opções:
Deve receber uma resposta JSON semelhante à seguinte:
O utilizador ou a conta de serviço que está a usar o método da API instances.clone
tem de ter a autorização cloudsql.instances.clone
. Para mais informações sobre as autorizações necessárias para usar métodos da API, consulte o artigo Autorizações do Cloud SQL.
REST v1beta4
Pode querer recuperar uma instância que não está disponível para uma zona diferente porque a zona na qual a instância está configurada não está acessível.
Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:
- PROJECT_ID: o ID do projeto
- SOURCE_INSTANCE_ID: o ID da instância da origem
- TARGET_INSTANCE_ID: o ID da instância de destino
Método HTTP e URL:
POST https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/SOURCE_INSTANCE_NAME/clone
Corpo JSON do pedido:
{ "cloneContext": { "destinationInstanceName": "TARGET_INSTANCE_ID" } }
Para enviar o seu pedido, expanda uma destas opções:
Deve receber uma resposta JSON semelhante à seguinte:
O utilizador ou a conta de serviço que está a usar o método da API instances.clone
tem de ter a autorização cloudsql.instances.clone
. Para mais informações sobre as autorizações necessárias para usar métodos da API, consulte o artigo Autorizações do Cloud SQL.
Se tentar criar um clone de PITR num momento posterior à hora recuperável mais recente, é apresentada a seguinte mensagem de erro:
The timestamp for point-in-time recovery is after the latest recovery time of Timestamp of latest recovery time. Clone the instance with a time that's earlier than this recovery time.
Obtenha o tempo de recuperação mais cedo e mais tarde
Para uma instância disponível, pode executar a PITR para qualquer data/hora no período da PITR da instância. O período de PITR começa na hora de recuperação mais antiga e termina na hora de recuperação mais recente. Se a instância estiver indisponível e os registos da instância estiverem armazenados no Cloud Storage, ou se a instância tiver sido eliminada e tiver a retenção de PITR ativada, pode obter a hora de recuperação mais antiga e mais recente, e executar a PITR para qualquer data/hora nesse período. Em todos os casos, pode restaurar a instância para uma zona principal ou secundária diferente fornecendo valores para as zonas preferenciais.
gcloud
Instância indisponível
Para saber a hora mais antiga e mais recente até à qual pode recuperar uma instância do Cloud SQL que não esteja disponível, execute o seguinte comando:
gcloud sql instances get-latest-recovery-time INSTANCE_NAME
Substitua o seguinte:
INSTANCE_NAME
: o nome da instância para a qual quer encontrar o tempo de recuperação mais recente.
Instância eliminada
Para saber a hora mais antiga e mais recente até à qual pode recuperar uma instância eliminada do Cloud SQL, execute o seguinte comando:
gcloud sql instances get-latest-recovery-time INSTANCE_NAME
--source-instance-deletion-time='SOURCE_INSTANCE_DELETION_TIMESTAMP'
Substitua o seguinte:
INSTANCE_NAME
: o nome da instância para a qual quer encontrar o tempo de recuperação mais recente.SOURCE_INSTANCE_DELETION_TIMESTAMP
: a indicação de tempo UTC para a hora em que a instância de origem foi eliminada, no formato RFC 3339. Por exemplo, 2012-11-15T16:19:00.094Z.
REST v1
Instância indisponível
Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:
- PROJECT_ID: o ID do projeto
- INSTANCE_NAME: o nome da instância para a qual está a consultar o tempo de recuperação mais recente
Método HTTP e URL:
GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME/getLatestRecoveryTime
Para enviar o seu pedido, expanda uma destas opções:
Deve receber uma resposta JSON semelhante à seguinte:
{ "kind": "sql#getLatestRecoveryTime", "earliestRecoveryTime": "2023-06-10T17:23:59.648821586Z", "latestRecoveryTime": "2023-06-20T17:23:59.648821586Z" }
Instância eliminada
Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:
- PROJECT_ID: o ID do projeto
- INSTANCE_NAME: o nome da instância de origem para a qual está a consultar o tempo de recuperação mais recente
- SOURCE_INSTANCE_DELETION_TIME: a hora em que a instância de origem foi eliminada
Método HTTP e URL:
GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME/getLatestRecoveryTime
Para enviar o seu pedido, expanda uma destas opções:
Deve receber uma resposta JSON semelhante à seguinte:
{ "kind": "sql#getLatestRecoveryTime", "earliestRecoveryTime": "2023-06-10T17:23:59.648821586Z", "latestRecoveryTime": "2023-06-20T17:23:59.648821586Z" }
REST v1beta4
Instância indisponível
Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:
- PROJECT_ID: o ID do projeto
- INSTANCE_NAME: o nome da instância para a qual está a consultar o tempo de recuperação mais recente
Método HTTP e URL:
GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME/getLatestRecoveryTime
Para enviar o seu pedido, expanda uma destas opções:
Deve receber uma resposta JSON semelhante à seguinte:
{ "kind": "sql#getLatestRecoveryTime", "earliestRecoveryTime": "2023-06-10T17:23:59.648821586Z", "latestRecoveryTime": "2023-06-20T17:23:59.648821586Z" }
Instância eliminada
Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:
- PROJECT_ID: o ID do projeto
- INSTANCE_NAME: o nome da instância de origem para a qual está a consultar o tempo de recuperação mais recente
- SOURCE_INSTANCE_DELETION_TIME: a hora em que a instância de origem foi eliminada
Método HTTP e URL:
GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME/getLatestRecoveryTime
Para enviar o seu pedido, expanda uma destas opções:
Deve receber uma resposta JSON semelhante à seguinte:
{ "kind": "sql#getLatestRecoveryTime", "earliestRecoveryTime": "2023-06-10T17:23:59.648821586Z", "latestRecoveryTime": "2023-06-20T17:23:59.648821586Z" }
Faça uma PITR usando uma indicação de tempo
A utilização de uma data/hora é a abordagem recomendada para realizar a PITR.
O Cloud SQL usa o utilitário mysqlbinlog
para restaurar instâncias até a uma hora específica. Para mais informações sobre a mysqlbinlog
utilidade, consulte a documentação de referência do MySQL.
Para concluir a tarefa seguinte, tem de ter o seguinte:
- Registo binário e cópias de segurança ativados para a instância, com registos binários contínuos desde a última cópia de segurança antes do evento a partir do qual quer recuperar. Para mais informações, consulte o artigo Ative o registo binário.
- Uma data/hora para definir o ponto de recuperação. Os eventos que ocorrem a partir desta indicação de tempo não se refletem na nova instância.
Consola
-
Na Trusted Cloud consola, aceda à página Instâncias do Cloud SQL.
- Abra o menu de mais ações
para a instância que quer recuperar e clique em Criar clone.
- Opcionalmente, na página Criar um clone, atualize o ID do novo clone.
- Selecione Clonar a partir de um ponto anterior no tempo.
- Introduza uma hora de PITR.
- Clique em Criar clone.
gcloud
Crie um clone através da PITR.
Substitua o seguinte:
- SOURCE_INSTANCE_NAME - Nome da instância a partir da qual está a fazer a restauração.
- NEW_INSTANCE_NAME: nome do clone.
- TIMESTAMP: fuso horário UTC da instância de origem no formato RFC 3339. Por exemplo, 2012-11-15T16:19:00.094Z.
gcloud sql instances clone SOURCE_INSTANCE_NAME \ NEW_INSTANCE_NAME \ --point-in-time 'TIMESTAMP'
REST v1
Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:
- project-id: o ID do projeto
- target-instance-id: o ID da instância de destino
- source-instance-id: o ID da instância de origem
- restore-timestamp O ponto no tempo até ao qual restaurar
Método HTTP e URL:
POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone
Corpo JSON do pedido:
{ "cloneContext": { "kind": "sql#cloneContext", "destinationInstanceName": "target-instance-id", "pointInTime": "restore-timestamp" } }
Para enviar o seu pedido, expanda uma destas opções:
Deve receber uma resposta JSON semelhante à seguinte:
REST v1beta4
Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:
- project-id: o ID do projeto
- target-instance-id: o ID da instância de destino
- source-instance-id: o ID da instância de origem
- restore-timestamp O ponto no tempo até ao qual restaurar
Método HTTP e URL:
POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone
Corpo JSON do pedido:
{ "cloneContext": { "kind": "sql#cloneContext", "destinationInstanceName": "target-instance-id", "pointInTime": "restore-timestamp" } }
Para enviar o seu pedido, expanda uma destas opções:
Deve receber uma resposta JSON semelhante à seguinte:
Realize a PITR através do cofre de cópias de segurança
Se a sua instância do Cloud SQL estiver ativada para usar cópias de segurança melhoradas, pode fazer uma recuperação num ponto específico no tempo para a sua instância através do cofre de cópias de segurança.
Consola
Na Trusted Cloud consola, aceda à página Instâncias do Cloud SQL.
Abra o menu de mais ações
para a instância que quer recuperar e clique em Criar clone.
Selecione Clonar a partir de um ponto anterior no tempo.
Introduza uma hora de PITR.
Clique em Criar clone.
gcloud
Para fazer uma PITR numa instância a partir do cofre de cópias de segurança, tem de encontrar o
data-source
da cópia de segurança mais próxima da hora em que quer fazer a
PITR. Para encontrar a cópia de segurança, consulte o artigo
Liste todas as cópias de segurança no cofre de cópias de segurança de uma instância. Depois de identificar a cópia de segurança, execute o seguinte comando para realizar a PITR:
gcloud sql instances point-in-time-restore DATA_SOURCE
PITR_TIMESTAMP
--project=TARGET_PROJECT
Substitua o seguinte:
- DATA_SOURCE: o caminho do
data-source
para a cópia de segurança mais próxima da data/hora da PITR para a qual quer fazer a recuperação. - PITR_TIMESTAMP: a data/hora UTC do registo PITR da instância de origem para o qual quer restaurar a instância, no formato RFC 3339. Por exemplo, 2012-11-15T16:19:00.094Z.
- TARGET_PROJECT: o ID do projeto da sua instância do Cloud SQL.
REST v1
REST v1beta4
Execute a PITR numa instância eliminada
Para usar a PITR para restaurar uma instância eliminada, precisa do seguinte:
- A data/hora da PITR (
timestamp
) para a qual quer restaurar a sua instância - O nome da instância de destino
- A hora em que a instância da origem foi eliminada (
source-instance-deletion-time
)
Só pode usar a PITR numa instância eliminada através da CLI gcloud ou da API Cloud SQL. Para mais informações, consulte o artigo Restaure uma instância eliminada através da PITR.
gcloud
Encontre a sua janela PITR
Para encontrar o período de PITR da instância eliminada, obtenha a hora de recuperação mais antiga e mais recente da instância. Pode selecionar uma data/hora em qualquer altura nesta janela para fazer uma PITR.
Encontre a hora de eliminação da instância de origem e os dias de retenção dos registos
O source-instance-deletion-time
e o log-retention-days
da instância eliminada são armazenados com as cópias de segurança retidas da sua instância após a eliminação. Para encontrar estes valores para a sua instância eliminada, consulte o artigo
Liste as cópias de segurança retidas.
Restaure com a PITR
Para restaurar a instância eliminada através da PITR, execute o seguinte comando:
gcloud sql instances clone SOURCE_INSTANCE_NAME \
NEW_INSTANCE_NAME \
--point-in-time='PITR_TIMESTAMP' \
--source-instance-deletion-time=SOURCE_INSTANCE_DELETION_TIMESTAMP
Substitua o seguinte:
SOURCE_INSTANCE_NAME
: o nome da instância de origem que quer restaurar.NEW_INSTANCE_NAME
: o nome da nova instância.PITR_TIMESTAMP
: a data/hora UTC do registo PITR da instância de origem para o qual quer restaurar a instância, no formato RFC 3339. Por exemplo, 2012-11-15T16:19:00.094Z.SOURCE_INSTANCE_DELETION_TIMESTAMP
: a indicação de tempo UTC para a hora em que a instância de origem foi eliminada, no formato RFC 3339. Por exemplo, 2012-11-15T16:19:00.094Z.
REST v1
Encontre a sua janela PITR
Para encontrar o período de PITR da instância eliminada, obtenha a hora de recuperação mais antiga e mais recente da instância. Pode selecionar uma data/hora em qualquer altura nesta janela para fazer uma PITR.
Encontre a hora de eliminação da instância de origem e os dias de retenção dos registos
O source-instance-deletion-time
e o log-retention-days
da instância eliminada são armazenados com as cópias de segurança retidas da sua instância após a eliminação. Para encontrar estes valores para a sua instância eliminada, consulte o artigo
Liste as cópias de segurança retidas.
Restaure com a PITR
Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:
- project-id: o ID do projeto
- target-instance-id: o ID da instância de destino
- source-instance-id: o ID da instância da origem
- source-instance-deletion-time: a hora de eliminação da instância da origem
- restore-timestamp o momento específico em que quer restaurar a instância
Método HTTP e URL:
POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone
Corpo JSON do pedido:
{ "cloneContext": { "kind": "sql#cloneContext", "destinationInstanceName": "target-instance-id", "sourceInstanceDeletionTime: "source-instance-deletion-time", "pointInTime": "restore-timestamp" } }
Para enviar o seu pedido, expanda uma destas opções:
Deve receber uma resposta JSON semelhante à seguinte:
REST v1beta4
Encontre a sua janela PITR
Para encontrar o período de PITR da instância eliminada, obtenha a hora de recuperação mais antiga e mais recente da instância. Pode selecionar uma data/hora em qualquer altura nesta janela para fazer uma PITR.
Encontre a hora de eliminação da instância de origem e os dias de retenção dos registos
O source-instance-deletion-time
e o log-retention-days
da instância eliminada são armazenados com as cópias de segurança retidas da sua instância após a eliminação. Para encontrar estes valores para a sua instância eliminada, consulte o artigo
Liste as cópias de segurança retidas.
Restaure com a PITR
Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:
- project-id: o ID do projeto
- target-instance-id: o ID da instância de destino
- source-instance-id: o ID da instância da origem
- source-instance-deletion-time: a hora de eliminação da instância da origem
- restore-timestamp o momento específico em que quer restaurar a instância
Método HTTP e URL:
POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone
Corpo JSON do pedido:
{ "cloneContext": { "kind": "sql#cloneContext", "destinationInstanceName": "target-instance-id", "sourceInstanceDeletionTime: "source-instance-deletion-time", "pointInTime": "restore-timestamp" } }
Para enviar o seu pedido, expanda uma destas opções:
Deve receber uma resposta JSON semelhante à seguinte:
Desative a PITR
Consola
-
Na Trusted Cloud consola, aceda à página Instâncias do Cloud SQL.
- Abra o menu Mais ações
para a instância que quer desativar e selecione Editar.
- Em Personalize a sua instância, expanda a secção Proteção de dados.
- Desmarque a opção Ativar recuperação pontual.
- Clique em Guardar.
gcloud
- Desative a recuperação pontual:
gcloud sql instances patch INSTANCE_NAME \ --no-enable-bin-log
- Confirme a alteração:
gcloud sql instances describe INSTANCE_NAME
Na secção
backupConfiguration
, vêbinaryLogEnabled: false
se a alteração foi bem-sucedida.
REST v1
Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:
- project-id: o ID do projeto
- instance-id: o ID da instância
Método HTTP e URL:
PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id
Corpo JSON do pedido:
{ "settings": { "backupConfiguration": { "enabled": false, "binaryLogEnabled": false } } }
Para enviar o seu pedido, expanda uma destas opções:
Deve receber uma resposta JSON semelhante à seguinte:
REST v1beta4
Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:
- project-id: o ID do projeto
- instance-id: o ID da instância
Método HTTP e URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id
Corpo JSON do pedido:
{ "settings": { "backupConfiguration": { "enabled": false, "binaryLogEnabled": false } } }
Para enviar o seu pedido, expanda uma destas opções:
Deve receber uma resposta JSON semelhante à seguinte:
Verifique a localização de armazenamento dos registos de transações usados para PITR
Pode verificar onde a sua instância do Cloud SQL está a armazenar os registos de transações usados para a PITR.
gcloud
Para determinar se a sua instância armazena registos para PITR no disco ou no Cloud Storage, use o seguinte comando:
gcloud sql instances describe INSTANCE_NAME
Substitua INSTANCE_NAME pelo nome da instância.
Para várias instâncias no mesmo projeto, também pode verificar a localização de armazenamento dos registos de transações. Para determinar a localização de várias instâncias, use o seguinte comando:
gcloud sql instances list --show-transactional-log-storage-state
Exemplo de resposta:
NAME DATABASE_VERSION LOCATION TRANSACTIONAL_LOG_STORAGE_STATE my_01 MYSQL_8_0 us-central-1 DISK my_02 MYSQL_8_0 us-central-1 CLOUD_STORAGE ...
Na saída do comando, o campo transactionalLogStorageState
ou a coluna TRANSACTIONAL_LOG_STORAGE_STATE
fornece
informações sobre onde os registos
de transações para PITR são armazenados para a instância.
Os estados de armazenamento possíveis do registo de transações são os seguintes:
DISK
: a instância armazena os registos de transações usados para PITR no disco. Se atualizar uma instância da edição Cloud SQL Enterprise para a edição Cloud SQL Enterprise Plus, o processo de atualização muda automaticamente a localização do armazenamento de registos 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. Também pode optar por mudar a localização do armazenamento através da CLI gcloud ou da API Cloud SQL Admin sem atualizar a edição da sua instância e sem incorrer em tempo de inatividade. Para mais informações, consulte o artigo Mude o armazenamento do registo de transações para o Cloud Storage.SWITCHING_TO_CLOUD_STORAGE
: a instância está a mudar a localização de armazenamento dos registos de transações PITR para o Cloud Storage.SWITCHED_TO_CLOUD_STORAGE
: a instância concluiu a mudança da localização de armazenamento dos registos de transações PITR do disco para o Cloud Storage.CLOUD_STORAGE
: a instância armazena os registos de transações usados para PITR no Cloud Storage.
Mude o armazenamento do registo de transações para o Cloud Storage
Se a sua instância armazenar os respetivos registos de transações usados para PITR no disco, pode mudar a localização de armazenamento para o Cloud Storage sem incorrer em qualquer período de inatividade. O processo geral de mudança da localização de armazenamento demora aproximadamente o período de retenção do registo de transações (dias) a ser concluído. Assim que iniciar a mudança, os registos de transações começam a acumular-se no Cloud Storage. Durante a operação, pode verificar o estado do processo geral através do comando em Verifique a localização de armazenamento dos registos de transações usados para PITR.
Após a conclusão do processo geral de mudança para o Cloud Storage, o Cloud SQL usa registos de transações do Cloud Storage para a PITR.
gcloud
Para mudar a localização do armazenamento para o Cloud Storage, use o seguinte comando:
gcloud sql instances patch INSTANCE_NAME \ --switch-transaction-logs-to-cloud-storage
Substitua INSTANCE_NAME pelo nome da instância. A instância tem de ser uma instância principal e não uma instância de réplica. A resposta é semelhante à seguinte:
The following message is used for the patch API method. {"name": "INSTANCE_NAME", "project": "PROJECT_NAME", "switchTransactionalLogsToCloudStorageEnabled": "true"} Patching Cloud SQL instance...done. Updated [https://sqladmin.prod.googleapis.com/v1/projects/PROJECT_NAME/instances/INSTANCE_NAME].
Se o comando devolver um erro, consulte o artigo Resolva problemas com a mudança para o armazenamento na nuvem para ver possíveis passos seguintes.
REST v1
Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:
- PROJECT_ID: o ID do projeto.
- INSTANCE_ID: o ID da instância. A instância tem de ser uma instância principal e não uma instância de réplica.
Método HTTP e URL:
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID
Corpo JSON do pedido:
{ "switchTransactionLogsToCloudStorageEnabled": true }
Para enviar o seu pedido, expanda uma destas opções:
Deve receber uma resposta JSON semelhante à seguinte:
Se o pedido devolver um erro, consulte o artigo Resolva problemas da mudança para o Google Cloud Storage para possíveis passos seguintes.
REST v1beta4
Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:
- PROJECT_ID: o ID do projeto.
- INSTANCE_ID: o ID da instância. A instância tem de ser uma instância principal e não uma instância de réplica.
Método HTTP e URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID
Corpo JSON do pedido:
{ "switchTransactionLogsToCloudStorageEnabled": true }
Para enviar o seu pedido, expanda uma destas opções:
Deve receber uma resposta JSON semelhante à seguinte:
Se o pedido devolver um erro, consulte o artigo Resolva problemas da mudança para o Google Cloud Storage para possíveis passos seguintes.
Armazenamento e configuração do registo de transações após a mudança
Para fins de replicação, o Cloud SQL continua a reter cópias dos registos binários no disco.
Se quiser procurar registos binários com o utilitário mysqlbinlog
, é útil armazenar registos binários no disco.
Se configurou as flags expire_logs_days
ou binlog_expire_logs_seconds
na sua instância antes da mudança, os valores configurados permanecem intactos.
Após a mudança, uma vez que os registos binários usados para executar a PITR são agora armazenados no Cloud Storage, certifique-se de que os valores das flags refletem a retenção dos registos de transações no disco que espera. O Cloud SQL só retém registos no disco durante o valor mínimo de um dos seguintes:
- a definição de configuração da
transactionLogRetentionDays
PITR antes da mudança. O valor predefinido para esta definição é de 7 dias. - As flags
expire_logs_days
oubinlog_expire_logs_seconds
que definiu manualmente na sua instância.
Se quiser poupar espaço em disco, após a conclusão do processo de mudança, configure o valor das flags expire_logs_days
ou binlog_expire_logs_seconds
para 1 dia para reduzir o tamanho do disco alocado e os custos de armazenamento em disco. Para mais informações sobre o armazenamento de registos de transações e a PITR, consulte o artigo Armazenamento de registos para PITR.
Para mais informações sobre como verificar a utilização do disco, consulte o artigo Registos e utilização do disco.
Defina a retenção do registo de transações
Para definir o número de dias de retenção dos registos binários:
Consola
-
Na Trusted Cloud consola, aceda à página Instâncias do Cloud SQL.
- Abra o menu Mais ações
para a instância na qual quer ativar o registo de transações e selecione Editar.
- Em Personalize a sua instância, expanda a secção Proteção de dados.
- Na secção Ativar recuperação num ponto específico no tempo, expanda as Opções avançadas.
- Introduza o número de dias para reter registos, de 1 a 35 para a edição Cloud SQL Enterprise Plus ou de 1 a 7 para a edição Cloud SQL Enterprise.
- Clique em Guardar.
gcloud
Edite a instância para definir o número de dias de retenção dos registos binários.
Substitua o seguinte:
- INSTANCE_NAME: o nome da instância na qual quer definir o registo de transações.
DAYS_TO_RETAIN: o número de dias dos registos de transações a manter. Para a edição Cloud SQL Enterprise Plus, o intervalo válido é entre 1 e 35 dias, com um valor predefinido de 14 dias. Para a edição Cloud SQL Enterprise, o intervalo válido é entre 1 e 7 dias, com um valor predefinido de 7 dias.
Se não especificar um valor, o Cloud SQL usa o valor predefinido. Isto só é válido quando a PITR está ativada. Manter mais dias de registos de transações requer um tamanho de armazenamento maior.
gcloud sql instances patch INSTANCE_NAME
--retained-transaction-log-days=DAYS_TO_RETAIN
REST v1
Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:
- PROJECT_ID: o ID do projeto.
- INSTANCE_ID: o ID da instância.
DAYS_TO_RETAIN: o número de dias para reter os registos de transações. Para a edição Cloud SQL Enterprise Plus, o intervalo válido é entre 1 e 35 dias, com um valor predefinido de 14 dias. Para a edição Cloud SQL Enterprise, o intervalo válido é entre 1 e 7 dias, com um valor predefinido de 7 dias.
Se não for especificado nenhum valor, é usado o valor predefinido. Isto só é válido quando a PITR está ativada. Manter mais dias de registos de transações requer um tamanho de armazenamento maior.
Método HTTP e URL:
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID
Corpo JSON do pedido:
{ "settings": { "backupConfiguration": { "transactionLogRetentionDays": "DAYS_TO_RETAIN" } } }
Para enviar o seu pedido, expanda uma destas opções:
Deve receber uma resposta JSON semelhante à seguinte:
REST v1beta4
Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:
- PROJECT_ID: o ID do projeto.
- INSTANCE_ID: o ID da instância.
DAYS_TO_RETAIN: o número de dias para reter os registos de transações. Para a edição Cloud SQL Enterprise Plus, o intervalo válido é entre 1 e 35 dias, com um valor predefinido de 14 dias. Para a edição Cloud SQL Enterprise, o intervalo válido é entre 1 e 7 dias, com um valor predefinido de 7 dias.
Se não for especificado nenhum valor, é usado o valor predefinido. Isto só é válido quando a PITR está ativada. Manter mais dias de registos de transações requer um tamanho de armazenamento maior.
Método HTTP e URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID
Corpo JSON do pedido:
{ "settings": { "backupConfiguration": { "transactionLogRetentionDays": "DAYS_TO_RETAIN" } } }
Para enviar o seu pedido, expanda uma destas opções:
Deve receber uma resposta JSON semelhante à seguinte:
Execute a PITR através de posições de registo binário
Embora recomendemos que execute a PITR através de indicações de tempo, conforme descrito em Execute a PITR através de uma indicação de tempo, também pode executar a PITR fornecendo uma posição específica do registo binário ou uma posição do evento num ficheiro de registo binário.
Para mais informações sobre a PITR com posições do registo binário, consulte o artigo PITR com o registo binário.
Antes de começar
Antes de concluir esta tarefa, tem de ter:
O registo binário e as cópias de segurança estão ativados para a instância, com registos binários contínuos desde a última cópia de segurança antes do evento do qual quer recuperar. Para mais informações, consulte o artigo Ative o registo binário.
Os registos binários têm de estar disponíveis no disco para que possa procurar eventos nos mesmos. Para verificar o período de retenção dos registos binários no disco, consulte o artigo Período de retenção de registos. Não pode procurar registos binários armazenados no Cloud Storage com a utilidade
mysqlbinlog
.Um nome de ficheiro de registo binário e a posição do evento a partir do qual quer recuperar (esse evento e todos os eventos que ocorreram depois não são refletidos na nova instância). Para mais informações, consulte o artigo Identifique a posição do registo binário.
Depois de identificar o nome do ficheiro e a posição do registo binário, execute a PITR com posições de eventos de registo binário.
Identifique a posição de recuperação
Use o cliente MySQL para estabelecer ligação à instância para a qual quer fazer o restauro.
Para o fazer, use o Cloud Shell ou a sua máquina cliente local. Para mais informações, consulte o artigo Opções de ligação para aplicações externas.
Mostrar os ficheiros de registo binários da instância:
SHOW BINARY LOGS;
Apresentar os primeiros 100 eventos no ficheiro de registo binário mais recente:
SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' LIMIT 100;
Pode ajustar o número de linhas a apresentar, mas não apresentar todos os eventos no ficheiro até saber o tamanho do ficheiro. A apresentação de um grande número de eventos pode afetar o desempenho do sistema.
Se o evento que procura não for apresentado, use a última posição apresentada como ponto de partida para pesquisar o conjunto seguinte de eventos:
SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' FROM <POSITION> LIMIT 100;
Quando encontrar o evento que marca o ponto no tempo até ao qual quer restaurar, registe a posição (apresentada como
Pos
) e o nome do ficheiro de registo binário.O nome do ficheiro de registo binário e a posição são os valores que usa para o PITR.
Segue-se um exemplo de saída do comando SHOW BINLOG EVENTS
:
+------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+ | mysql-bin.000011 | 4 | Format_desc | 88955285 | 120 | Server ver: 5.6.30-log, Binlog ver: 4 | | mysql-bin.000011 | 120 | Query | 88955285 | 211 | create database db1 | | mysql-bin.000011 | 211 | Query | 88955285 | 310 | use `db1`; CREATE TABLE t (c CHAR(20)) | | mysql-bin.000011 | 310 | Query | 88955285 | 381 | BEGIN | | mysql-bin.000011 | 381 | Table_map | 88955285 | 426 | table_id: 18 (db1.t) | | mysql-bin.000011 | 310 | Query | 88955285 | 381 | BEGIN | | mysql-bin.000011 | 426 | Write_rows | 88955285 | 464 | table_id: 18 flags: STMT_END_F | | mysql-bin.000011 | 464 | Xid | 88955285 | 495 | COMMIT /* xid=56 */ | | mysql-bin.000011 | 495 | Query | 88955285 | 566 | BEGIN | | mysql-bin.000011 | 566 | Table_map | 88955285 | 611 | table_id: 18 (db1.t) | | mysql-bin.000011 | 611 | Write_rows | 88955285 | 649 | table_id: 18 flags: STMT_END_F | | mysql-bin.000011 | 649 | Xid | 88955285 | 680 | COMMIT /* xid=57 */ | | mysql-bin.000011 | 680 | Query | 88955285 | 751 | BEGIN | | mysql-bin.000011 | 751 | Table_map | 88955285 | 796 | table_id: 18 (db1.t) | | mysql-bin.000011 | 796 | Write_rows | 88955285 | 834 | table_id: 18 flags: STMT_END_F | | mysql-bin.000011 | 834 | Xid | 88955285 | 865 | COMMIT /* xid=58 */ | | mysql-bin.000011 | 865 | Query | 88955285 | 977 | use `db1`; DROP TABLE `t` /* generated by server */ | +------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+ 16 rows in set (0.04 sec)
Para restaurar até à declaração DROP TABLE
, apresentada a negrito no exemplo anterior, usaria 865
em mysql-bin.000011
como posição de recuperação. A declaração DROP TABLE
e todas as operações posteriores não são refletidas na nova instância.
Realize a PITR com posições de eventos de registo binário
gcloud
Use o comando
gcloud sql instances clone
com as flags
--bin-log-file-name
e --bin-log-position
.
-
Crie a nova instância com o nome do ficheiro de registo binário e a posição de recuperação.
Substitua o seguinte:
- SOURCE_INSTANCE_NAME: nome da instância a partir da qual está a fazer a restauração.
- NEW_INSTANCE_NAME: nome do clone.
- BINLOG_FILE_NAME: nome do registo binário, como
mysql-bin.187288
. - POSITION: a posição no registo binário a restaurar até, como
50001356
.
gcloud sql instances clone SOURCE_INSTANCE_NAME \ NEW_INSTANCE_NAME \ --bin-log-file-name="BINLOG_FILE_NAME" \ --bin-log-position=POSITION
Por exemplo, um comando
gcloud sql instances clone
pode ter um aspeto semelhante ao seguinte:gcloud sql instances clone instance1 \ instance1-clone \ --bin-log-file-name=mysql-bin.0000031 \ --bin-log-position=107 \
- Use o ID da operação devolvido pelo comando
clone
para verificar o estado da operação de restauro.gcloud sql operations describe OPERATION_ID
Quando a operação está em curso, é devolvido um estado de
RUNNING
. Quando a operação estiver concluída, é devolvido um estado deDONE
.
REST v1
Crie a nova instância com o nome do ficheiro de registo binário e a posição de recuperação que identificou:
Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:
- project-id: o ID do projeto
- target-instance-id: o ID da instância de destino
- source-instance-id: o ID da instância de origem
- binary-log-file-name O nome do ficheiro de registo binário
- binary-log-position A posição no ficheiro de registo binário
Método HTTP e URL:
POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone
Corpo JSON do pedido:
{ "cloneContext": { "kind": "sql#cloneContext", "destinationInstanceName": "target-instance-id", "binLogCoordinates": { "kind": "sql#binLogCoordinates", "binLogFileName": "binary-log-file-name", "binLogPosition": "binary-log-position" } } }
Para enviar o seu pedido, expanda uma destas opções:
Deve receber uma resposta JSON semelhante à seguinte:
REST v1beta4
Crie a nova instância com o nome do ficheiro de registo binário e a posição de recuperação que identificou:
Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:
- project-id: o ID do projeto
- target-instance-id: o ID da instância de destino
- source-instance-id: o ID da instância de origem
- binary-log-file-name O nome do ficheiro de registo binário
- binary-log-position A posição no ficheiro de registo binário
Método HTTP e URL:
POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone
Corpo JSON do pedido:
{ "cloneContext": { "kind": "sql#cloneContext", "destinationInstanceName": "target-instance-id", "binLogCoordinates": { "kind": "sql#binLogCoordinates", "binLogFileName": "binary-log-file-name", "binLogPosition": "binary-log-position" } } }
Para enviar o seu pedido, expanda uma destas opções:
Deve receber uma resposta JSON semelhante à seguinte:
Resolver problemas
Problema | Resolução de problemas |
---|---|
OU
|
A data/hora que indicou é inválida. |
OU
|
A data/hora que indicou corresponde a um momento em que não foi possível encontrar cópias de segurança nem coordenadas binlog. |
Resolva problemas na mudança para o Cloud Storage
A tabela seguinte apresenta os possíveis erros que podem ser devolvidos com o código INVALID REQUEST
quando muda a localização de armazenamento dos registos de transações do disco para o armazenamento na nuvem.
Problema | Resolução de problemas |
---|---|
Switching the storage location of the transaction logs
used for PITR is not supported for instances with database type %s.
|
Certifique-se de que está a executar o comando da CLI gcloud ou a fazer o pedido de API numa instância do Cloud SQL para MySQL ou Cloud SQL para PostgreSQL. A mudança da localização de armazenamento dos registos de transações através da CLI gcloud ou da API Cloud SQL Admin não é suportada para o Cloud SQL para SQL Server. |
MySQL transactional logging is not enabled on this instance.
|
O MySQL usa o registo binário como os registos de transações para a recuperação num determinado momento (PITR). Para suportar a PITR, o MySQL requer que ative o registo binário na instância. Para mais informações sobre como ativar o registo binário, consulte Ative a PITR. |
This command is not supported on replica instances.
Run the command on the primary instance instead.
|
Certifique-se de que especifica uma instância principal quando executar o comando ou fizer o pedido da API. |
This instance is already storing transaction logs used for PITR in
Cloud Storage
|
Para validar a localização de armazenamento dos registos de transações, execute o comando em Verifique a localização de armazenamento dos registos de transações usados para PITR. |
The instance is already switching transaction logs used for PITR from disk
to Cloud Storage.
|
Aguarde pela conclusão da operação de mudança. Para verificar o estado da operação e a localização de armazenamento dos registos de transações, execute o comando em Verifique a localização de armazenamento dos registos de transações usados para PITR. |
O que se segue?
- Configure as flags no clone