Mover uma instância

Nesta página, descrevemos como mover uma instância no Spanner.

É possível mover a instância do Spanner de qualquer configuração de instância para qualquer outra configuração de instância, incluindo configurações regionais, birregionais e multirregionais. A migração da instância não causa inatividade, e o Spanner continua fornecendo as garantias de transação habituais, incluindo consistência forte, durante a migração.

Também é possível mover a instância da configuração de origem para uma configuração personalizada (por exemplo, uma configuração de base nam3 com uma réplica somente leitura us-west2). Como não é possível atualizar a topologia das configurações de instância atuais, é necessário criar uma nova configuração de instância personalizada com a topologia desejada primeiro. Depois de criar a nova configuração de instância personalizada, é possível mover sua instância da configuração de instância de origem para a nova configuração de instância personalizada.

Por que mover sua instância do Spanner?

Os benefícios de mover sua instância incluem:

• Aumentar a disponibilidade: tenha 99,999% de disponibilidade sem tempo de inatividade depois de realizar uma migração regional para birregional ou multirregional.
• Reduzir a latência: reduza a latência e aumente a cobertura geográfica com réplicas extras somente leitura por meio de uma mudança de regional para birregional ou multirregional ou de multirregional para multirregional.
• Reduzir custos: reduza os custos por hora mudando de uma configuração birregional ou multirregional para uma configuração regional.
• Colocar o banco de dados no mesmo local: coloque o banco de dados do Spanner no mesmo local do aplicativo cliente movendo a instância para um local mais otimizado.

Preços

Ao mover uma instância, as configurações de origem e destino estão sujeitas a cobranças de computação e armazenamento por hora. Depois que a mudança for concluída, você vai receber uma cobrança pelo armazenamento da instância na configuração de destino.

Se você estiver movendo sua instância para uma nova configuração de instância regional, birregional ou multirregional, poderá estar sujeito a cobranças de transferência de dados de saída. Para mais informações, consulte os preços do Spanner.

Limitações

• Para mover sua instância, ela precisa ter pelo menos 1 nó (1.000 unidades de processamento).
• Não é possível mover a instância entre projetos ou contas do Google Cloud .
• Não é possível mover uma instância que usa a edição Standard diretamente de uma configuração de instância regional para uma configuração de instância birregional ou multirregional. Primeiro, faça upgrade da edição da instância para a edição Enterprise Plus e, em seguida, mova a instância.
• Se você tiver solicitações ativas usando um endpoint de serviço regional em qualquer um dos recursos da instância, a movimentação da instância vai afetar todas as solicitações que usam o endpoint regional, porque a restrição regional bloqueia o acesso a instâncias entre regiões. As solicitações que usam um endpoint global não são afetadas.
• Os backups e as programações de backup do Spanner são específicos de uma configuração de instância e não são incluídos ao mover uma instância. É necessário excluir todos os backups e programações de backup atuais na instância antes de iniciar a migração. Para mais informações, consulte Backups e programações de backup.
• As APIs a seguir são desativadas durante a migração de uma instância:
  • InstanceAdmin.DeleteInstance
  • InstanceAdmin.UpdateInstance
  • InstanceAdmin.CreateInstancePartition
  • InstanceAdmin.UpdateInstancePartition
  • InstanceAdmin.DeleteInstancePartition
  • DatabaseAdmin.CreateDatabase
  • DatabaseAdmin.UpdateDatabaseDdl (desativado se default_leader for especificado na solicitação).
  • DatabaseAdmin.RestoreDatabase
  • DatabaseAdmin.CreateBackup
  • DatabaseAdmin.CreateBackupSchedule
  • DatabaseAdmin.CopyBackup
• Se um banco de dados tiver um líder padrão modificado, a seleção será preservada se nomear uma região de leitura e gravação na configuração da instância de destino, e essa configuração for multirregional. Se a configuração de destino for regional ou não incluir a região de leitura e gravação nomeada, a seleção de líder padrão será limpa.
• Mover uma instância altera o atributo de configuração da instância. Se você gerencia seus recursos do Spanner por meio de automação, prepare-se para lidar com as inconsistências que podem surgir.
  • Por exemplo, se você usar o Terraform para gerenciar as instâncias e os bancos de dados do Spanner e ativar terraform apply --auto-approve para manter os recursos sincronizados, todas as instâncias e recursos filhos serão excluídos quando movermos a instância. Atualize a configuração para evitar a exclusão e a perda de dados. Consulte Opções de aplicação do Terraform para mais informações sobre o comando apply.
• Enquanto a instância está sendo movida, as métricas e os gráficos de monitoramento do Spanner podem mostrar dados nas configurações da instância de origem e de destino ou refletir apenas o desempenho em uma configuração de instância.
• Se você tiver configurado a ferramenta de escalonador automático de código aberto, não será necessário desativá-la. Ela falha porque InstanceAdmin.UpdateInstance (usado para alterações de nó e unidade de processamento) está desativado.
• Não é possível mover uma instância se o recurso de escalonador automático gerenciado do Spanner estiver ativado nela. Antes de mover a instância, mude o escalonamento automático gerenciado para a alocação manual com nós ou unidades de processamento suficientes para dar suporte ao pico de uso da CPU (por exemplo, executando gcloud spanner instances update INSTANCE_ID --nodes=PEAK_NODES). Depois que a mudança for concluída, reative o escalonador automático gerenciado.
• Não é possível mover uma instância de teste sem custo financeiro do Spanner. É possível mover a instância depois de fazer upgrade para uma instância paga.
• Se a instância usar particionamento geográfico, mover a instância vai mover apenas a partição padrão, não as partições adicionais.

Considerações sobre desempenho

Quando uma instância está sendo movida, ela apresenta latências de leitura e gravação mais altas e uma taxa de cancelamento de transações mais alta. A utilização da CPU durante a movimentação pode chegar a 100% porque a movimentação da instância é realizada usando a CPU extra que você provisionou e que é usada para o tráfego de produção. No entanto, mover uma instância não causa inatividade. O tempo necessário para mover uma instância depende de vários fatores, incluindo o tamanho dos bancos de dados, o número de nós e o tipo de movimentação (por exemplo, regional para multirregional).

Por exemplo, para que uma migração seja concluída em até 24 horas, sua instância normalmente precisa atender a estes requisitos antes e durante a migração:

• Uso de CPU de alta prioridade: menos de 40% na configuração da instância de origem. Para mais informações, consulte Utilização da CPU.
• Armazenamento por nó: menos de 1 Tebibyte (TiB) por nó.

Depois de mover uma instância, o desempenho dela varia de acordo com os detalhes da configuração. Por exemplo, as configurações birregionais e multirregionais geralmente têm maior latência de gravação e menor latência de leitura do que as configurações regionais.

Backups e agendamentos de backup

Quando você move uma instância, os backups e as programações de backup na configuração original da instância não são movidos automaticamente para a nova configuração de destino. A movimentação da instância não será iniciada se houver backups ou programações de backup (incluindo programações de backup padrão) na instância quando você iniciar a movimentação. Copie seus backups e considere seu plano de recuperação de dados antes de mover sua instância.

Se houver backups na configuração original da instância que você precisa manter, recomendamos que você copie seus backups para duas instâncias temporárias pequenas (100 PU), placeholder-source e placeholder-dest:

• placeholder-source: uma instância com a mesma configuração da configuração original da instância em movimento. Isso permite restaurar os backups para a configuração original se você precisar cancelar a migração.

• placeholder-dest: uma instância com a mesma configuração da instância de destino. Isso garante que você tenha um backup prontamente disponível na nova configuração imediatamente após a conclusão da migração.

O recurso de restauração não é compatível com restaurações entre configurações. Portanto, essas instâncias de marcador de posição são essenciais para uma reversão ou recuperação rápida na nova configuração, se necessário, fornecendo uma rede de segurança em caso de problemas com a instância movida.

Depois de copiar os backups para placeholder-source e placeholder-dest, é necessário excluir todos os backups e programações de backup atuais na instância em movimento antes de iniciar a migração. Consulte Copiar backups para instâncias de marcador de posição e excluir backups e programações de backup atuais para ver os comandos exatos. Depois que a movimentação da instância for concluída, você já terá uma cópia do backup na configuração de destino e poderá recriar as programações de backup e criar um novo backup.

Ao seguir essa abordagem, você mantém a continuidade dos negócios e minimiza possíveis inatividades ou perdas de dados durante o processo de movimentação da instância.

Como mover uma instância

É possível mover uma instância usando o console do Google Cloud ou a CLI gcloud. Siga estas quatro fases para preparar, executar, monitorar e finalizar a mudança de instância:

• Fase 1: preparar a instância para a mudança
• Fase 2: iniciar a transferência da instância
• Fase 3: monitorar a transferência da instância
• Fase 4: concluir as tarefas pós-transferência

Fase 1: preparar a instância para a migração

Antes de mover a instância, leia as seções Limitações e Considerações de desempenho e conclua cada etapa desta lista de verificação pré-movimentação:

1. Verifique as permissões, a edição e a cota de destino:

   • Confirme se o operador que está executando a movimentação tem a permissão do IAM spanner.instances.update na instância em movimento.
   • Verifique se o projeto tem cota de nós suficiente na configuração da instância de destino para dar suporte à capacidade de pico. Para mais informações, consulte Cotas e limites do Spanner.
   • Se você estiver movendo uma instância da edição Standard de uma configuração regional para uma configuração birregional ou multirregional, faça upgrade da edição para a edição Enterprise Plus primeiro.

2. Validar a integridade da carga de trabalho, planejar o posicionamento do cliente e testar em um ambiente que não seja de produção:

   • Mova primeiro uma instância de não produção (como teste ou preparo) que espelhe sua instância de produção para estimar a duração da mudança e observar o efeito de desempenho na carga de trabalho.
   • Verifique se não há pontos de acesso nos bancos de dados usando o Key Visualizer. Resolver pontos de acesso antes da migração ajuda a evitar latência elevada e cancelamentos de transações enquanto os dados estão sendo copiados.
   • Se a configuração de destino tiver uma região líder padrão diferente da origem, a latência de gravação poderá aumentar após a migração. Para evitar isso, planeje implantar ou rotear os aplicativos cliente com muitas gravações na região líder de destino ou perto dela.

3. Mude do escalonamento automático gerenciado para a alocação e o tamanho manuais para a migração:

   • Para ajudar a concluir a migração em 24 horas e minimizar o impacto da latência, provisione capacidade de computação suficiente para que o pico de utilização da CPU de alta prioridade seja inferior a 40% e o armazenamento por nó seja inferior a 1 TiB durante a migração. Verifique os gráficos de Uso da CPU e Armazenamento total em Insights do sistema para determinar o número de nós necessários para sua carga de trabalho de pico. Como o Spanner usa a CPU extra para mover dados, aumentar a capacidade de computação aumenta a velocidade da movimentação da instância. Para confirmar a capacidade de computação ideal para sua carga de trabalho, teste a migração em um ambiente em pré-produção ou de preparo.

   • Se o escalonador automático gerenciado estiver ativado na instância, mude a instância para alocação manual antes de iniciar a migração, usando o número de nós que você determinou que é necessário para manter o pico de utilização da CPU de alta prioridade abaixo de 40%:

     gcloud spanner instances update INSTANCE_ID \
       --nodes=PEAK_NODES
     

4. Copie os backups para instâncias de marcador de posição e exclua os backups e as programações de backup atuais:

   • Crie as instâncias temporárias placeholder-source e placeholder-dest discutidas na seção Backups e programações de backup e copie os backups críticos para elas usando o comando gcloud spanner backups copy:

     gcloud spanner backups copy \
       --source-instance=INSTANCE_ID \
       --source-backup=SOURCE_BACKUP_ID \
       --destination-instance=PLACEHOLDER_INSTANCE_ID \
       --destination-backup=DESTINATION_BACKUP_ID \
       --expiration-date=EXPIRATION_DATE
     

   • Verifique se todas as operações de cópia de backup nas instâncias de marcador de posição foram concluídas antes de excluir os backups na instância em movimento:

     gcloud spanner operations list \
       --instance=PLACEHOLDER_INSTANCE_ID \
       --type=BACKUP
     

   • Exclua todos os backups e todas as programações de backup em cada banco de dados na instância em movimento:

     gcloud spanner backups delete BACKUP_ID \
       --instance=INSTANCE_ID
     

     gcloud spanner backup-schedules delete SCHEDULE_ID \
       --instance=INSTANCE_ID \
       --database=DATABASE_ID
     

5. Exportar tags do Data Catalog, pausar a automação e congelar as mudanças de instância e esquema:

   • Mover uma instância exclui todas as tags de instância criadas no Data Catalog. Exporte suas tags antes da mudança para que você possa importá-las depois. Para mais informações, consulte Exportar e importar tags.
   • Verifique seus fluxos de trabalho de CI/CD, jobs programados ou repositórios do GitOps em busca de pipelines de infraestrutura automatizados (como execuções programadas de terraform apply --auto-approve) que gerenciam seus recursos do Spanner e pause-os para que não entrem em conflito com a movimentação em andamento.
   • Informe à sua organização que as mudanças de instância e esquema (incluindo atualizações de contagem de nós, atualizações de DDL, criação ou exclusão de banco de dados e operações de backup) precisam ser pausadas até que a migração seja concluída.

6. Somente bancos de dados com CMEK: verifique as regiões de destino e as chaves do Cloud Key Management Service (Cloud KMS):

   • Inspecione a configuração da instância de destino para identificar todas as regiões de leitura/gravação, somente leitura e testemunha:

     gcloud spanner instance-configs describe TARGET_CONFIG
     

   • Verifique se você provisionou chaves do Cloud KMS em todas as regiões constituintes da configuração de destino e concedeu o papel do Identity and Access Management (IAM) roles/cloudkms.cryptoKeyEncrypterDecrypter em cada chave de destino ao agente de serviço do Spanner.

Se a instância atender a essas diretrizes, a migração geralmente será concluída em até 24 horas. Dependendo do tamanho do banco de dados e da carga de trabalho do aplicativo, o tempo de conclusão pode ser maior ou menor.

Fase 2: iniciar a movimentação da instância

gcloud spanner instances move INSTANCE_ID \
--target-config=TARGET_CONFIG

  gcloud spanner instances move test-instance --target-config=nam3

gcloud spanner instances move INSTANCE_ID \
  --target-config=TARGET_CONFIG \
  --target-database-move-configs=^:^database-id=DATABASE_ID_1:kms-key-names=KMS_KEY_1[, KMS_KEY_2 ... ] \
  [--target-database-move-configs=^:^database-id=DATABASE_ID_2:kms-key-names=KMS_KEY_1 ... ]

gcloud spanner instances move INSTANCE_ID \
  --target-config=TARGET_CONFIG \
  --target-database-move-configs=CONFIG_FILE_PATH

[
  {
    "database-id": "database-1",
    "kms-key-names": "projects/PROJECT_ID/locations/us-east4/keyRings/KEY_RING/cryptoKeys/KEY_NAME,projects/PROJECT_ID/locations/us-east1/keyRings/KEY_RING/cryptoKeys/KEY_NAME,projects/PROJECT_ID/locations/us-central1/keyRings/KEY_RING/cryptoKeys/KEY_NAME"
  },
  {
    "database-id": "database-2",
    "kms-key-names": "projects/PROJECT_ID/locations/us-east4/keyRings/KEY_RING/cryptoKeys/KEY_NAME,projects/PROJECT_ID/locations/us-east1/keyRings/KEY_RING/cryptoKeys/KEY_NAME,projects/PROJECT_ID/locations/us-central1/keyRings/KEY_RING/cryptoKeys/KEY_NAME"
  }
]

Fase 3: monitorar a transferência da instância

Use gcloud spanner operations describe e um painel personalizado do Cloud Monitoring para monitorar o progresso de uma movimentação ou cancelamento de instância.

Ver o progresso da operação de movimentação e cancelamento

Para acompanhar o progresso de uma operação de movimentação ou cancelamento de movimentação de instância, use o comando gcloud spanner operations describe. Esse comando requer o ID da operação de movimentação de instância em andamento.

1. Para receber o ID da operação de movimentação de instância, execute:

   gcloud spanner operations list --instance="INSTANCE_ID"
   

   Substitua:

   • INSTANCE_ID: o identificador permanente da instância que você quer mover.

   A saída mostra uma lista de operações de longa duração, incluindo a operação de movimentação da instância.

2. Execute o comando gcloud spanner operations describe para conferir a porcentagem de progresso e o status:

   gcloud spanner operations describe OPERATION_ID --instance=INSTANCE_ID
   

   Substitua:

   • OPERATION_ID: o ID da operação de movimentação de instância que você quer verificar.
   • INSTANCE_ID: o ID da instância que você quer verificar.

Monitorar uma operação de movimentação de instância

É possível criar um painel personalizado do Cloud Monitoring para exibir e monitorar métricas durante a movimentação da instância, uma operação de longa duração com possíveis implicações de serviço.

Os gráficos Armazenamento total e Armazenamento total do banco de dados por bancos de dados no painel são úteis para monitorar o progresso da migração. É possível ver o armazenamento na configuração de origem diminuir gradualmente, enquanto o armazenamento na configuração de destino aumenta.

Fase 4: concluir as tarefas pós-transferência

Depois que a operação de movimentação de longa duração for concluída (done: true), siga esta lista de verificação pós-movimentação para restaurar sua configuração operacional:

1. Reative o escalonador automático gerenciado: se você tiver mudado do escalonamento automático gerenciado para a alocação manual antes da mudança, reative o escalonador automático gerenciado com os limites mínimo e máximo de capacidade de computação (por exemplo, executando gcloud spanner instances update INSTANCE_ID com as flags de escalonamento automático ou no console do Google Cloud ).
2. Recrie as programações de backup e crie um backup: recrie as programações de backup e crie um novo backup para os bancos de dados na configuração da instância de destino.
3. Importar tags do Data Catalog: se você exportou tags do Data Catalog antes da mudança, importe-as de volta para a instância movida.
4. Atualize as configurações de automação, o posicionamento do cliente e as cargas de trabalho downstream:
   • Se você gerencia seus recursos do Spanner usando ferramentas de automação, como o Terraform, atualize os arquivos de configuração para refletir a nova configuração da instância de destino antes de reativar as implantações automatizadas.
   • Se a região líder mudou após a migração, implante ou encaminhe os aplicativos cliente dentro ou perto da nova região líder (ou modifique a região líder padrão do banco de dados, se estiver usando uma configuração birregional ou multirregional) para minimizar a latência de gravação e verifique a conectividade e a latência em aplicativos e pipelines downstream.
5. Exclua as instâncias de marcador temporárias: depois de verificar a instância movida e criar novos backups na configuração de destino, exclua as instâncias temporárias placeholder-source e placeholder-dest se não precisar mais dos backups copiados.

Como cancelar a movimentação de uma instância

Só é possível cancelar uma movimentação de instância que ainda está em andamento. Se você quiser reverter uma movimentação de instância já concluída, será necessário iniciar uma nova movimentação.

Use gcloud spanner operations cancel para cancelar operações de movimentação de instâncias. O cancelamento não é instantâneo e leva aproximadamente o mesmo tempo que o tempo decorrido desde o início da movimentação. Isso ocorre porque os dados precisam ser movidos de volta para a configuração da instância de origem.

Esse comando requer o ID da operação de movimentação de instância em andamento.

1. Para receber o ID da operação, execute:

   gcloud spanner operations list --type=INSTANCE --instance="INSTANCE_ID"
   --filter="done:False AND metadata.@type:MoveInstanceMetadata"
   

   Substitua:

   • INSTANCE_ID: o identificador permanente da instância que você quer mover.

   A saída mostra uma lista de operações de movimentação de instâncias em andamento.

2. Execute o comando gcloud spanner operations cancel para cancelar a movimentação da instância:

   gcloud spanner operations cancel OPERATION_ID
   

   Substitua:

   • OPERATION_ID: o ID da operação de movimentação de instância que você quer cancelar.

A seguir

• Saiba mais sobre as configurações regionais, birregionais e multirregionais do Spanner.
• Saiba mais sobre Google Cloud regiões e zonas.