Algumas ou todas as informações nesta página podem não se aplicar à Trusted Cloud by S3NS. Consulte o artigo Diferenças em relação ao Google Cloud para mais detalhes.

Esta página foi traduzida pela API Cloud Translation.

Migre para o Cloud SQL a partir de um ficheiro físico do XtraBackup

MySQL | PostgreSQL | SQL Server

Esta página descreve como migrar uma base de dados MySQL de um servidor externo para o Cloud SQL através de um ficheiro físico do Percona XtraBackup para MySQL.

O Cloud SQL suporta a migração de bases de dados MySQL em servidores externos para instâncias do Cloud SQL para MySQL através do Percona XtraBackup. Gera ficheiros físicos com o utilitário XtraBackup e, em seguida, carrega-os para o Cloud Storage. Ao usar ficheiros físicos, pode melhorar a velocidade geral da sua migração até 10 vezes em comparação com uma migração normal baseada em ficheiros de despejo lógico.

O Cloud SQL suporta a migração física baseada em ficheiros para o MySQL 5.7 e 8.0. O MySQL 5.6 e o 8.4 não são suportados. A migração de bases de dados do Amazon Aurora ou do MySQL no Amazon RDS não é suportada. Além disso, a instância de réplica de destino no Cloud SQL para MySQL tem de ser instalada com a mesma versão principal do MySQL que o seu servidor externo. No entanto, a réplica de destino pode usar uma versão secundária posterior. Por exemplo, se a sua base de dados externa estiver a usar o MySQL 8.0.31, a réplica de destino tem de ser o Cloud SQL para MySQL versão 8.0.31 ou posterior.

Antes de começar

Esta secção indica os passos que tem de seguir antes de migrar a sua base de dados MySQL para o Trusted Cloud.

Configure um Trusted Cloud projeto

In the Trusted Cloud console, on the project selector page, select or create a Trusted Cloud project.
Roles required to select or create a project
- Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
- Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.
Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector
Verify that billing is enabled for your Trusted Cloud project.
Enable the Cloud SQL Admin API.
Roles required to enable APIs
To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.
Enable the API

Certifique-se de que tem as funções de administrador do Cloud SQL, administrador do armazenamento e leitor do Compute na sua conta de utilizador.

Aceda à página IAM

Configure um contentor do Cloud Storage

Se ainda não o fez, crie um contentor do Cloud Storage.

Instale o Trusted Cloud SDK

Para usar comandos da CLI gcloud no seu servidor externo, instale o Trusted Cloud SDK.

Prepare o servidor externo para a migração

Instale uma das seguintes versões do utilitário XtraBackup no seu servidor externo.
- Para o MySQL 5.7, instale o Percona XtraBackup 2.4.
- Para o MySQL 8.0, instale o Percona XtraBackup 8.0.x.
Para o MySQL 8.0, tem de instalar uma versão do XtraBackup igual ou superior à versão do servidor de origem. Para mais informações, consulte a comparação entre a versão do servidor e a versão da cópia de segurança na documentação do Percona XtraBackup.
Certifique-se de que o seu servidor externo cumpre todos os requisitos necessários para a replicação. Para mais informações, consulte o artigo Configure o servidor externo para replicação.

Além dos requisitos do servidor externo para a replicação, a migração a partir de um ficheiro físico do XtraBackup tem os seguintes requisitos:
- A sua base de dados do MySQL tem de ser uma base de dados no local ou uma base de dados do MySQL autogerida numa VM do Compute Engine. A migração de bases de dados do Amazon Aurora ou do MySQL no Amazon RDS não é suportada.
- Tem de configurar o parâmetro innodb_data_file_path com apenas um ficheiro de dados que use o nome do ficheiro de dados predefinido ibdata1. Se a sua base de dados estiver configurada com dois ficheiros de dados ou tiver um ficheiro de dados com um nome diferente, não pode migrar a base de dados através de um ficheiro físico do XtraBackup. Por exemplo, uma base de dados configurada com innodb_data_file_path=ibdata01:50M:autoextend não é suportada para a migração.
- O parâmetro innodb_page_size na base de dados externa de origem tem de ser configurado com o valor predefinido 16384.
Se ainda não o fez, crie uma conta de utilizador de replicação. Precisa do nome de utilizador e da palavra-passe desta conta de utilizador.

Faça a migração

Conclua todos os passos nas secções seguintes para migrar a sua base de dados MySQL externa para o Cloud SQL.

Crie e prepare o ficheiro físico do XtraBackup

No servidor externo, use o XtraBackup para fazer uma cópia de segurança completa da base de dados de origem. Para mais informações sobre como fazer uma cópia de segurança completa, consulte o artigo Crie uma cópia de segurança completa na documentação do Percona XtraBackup.

Outros tipos de cópias de segurança, como cópias de segurança incrementais e parciais, não são suportados.

Para melhorar o desempenho do processo de cópia de segurança, faça o seguinte:
- Copie vários ficheiros em paralelo durante o passo de cópia de segurança usando --parallel=threads
- Aumente a atribuição de memória durante o passo de preparação usando --use-memory=size
Por exemplo:
```
sudo xtrabackup --backup \
--target-dir=XTRABACKUP_PATH \
--user=USERNAME \
--password=PASSWORD \
--parallel=THREADS
```
Substitua as seguintes variáveis:
- XTRABACKUP_PATH: a localização do ficheiro de cópia de segurança de saída
- USERNAME: um utilizador que tem privilégios de BACKUP_ADMIN na base de dados de origem
- PASSWORD: a palavra-passe do utilizador
- THREADS: o número de threads a usar quando copiar vários ficheiros de dados em simultâneo durante a criação de uma cópia de segurança
Use o utilitário XtraBackup para preparar o ficheiro de cópia de segurança. O ficheiro tem de estar num estado consistente. Para mais informações sobre como preparar uma cópia de segurança completa, consulte o artigo Prepare uma cópia de segurança completa. Por exemplo:
```
sudo xtrabackup --prepare --target-dir=XTRABACKUP_PATH \
    --use-memory=MEMORY
```
Substitua as seguintes variáveis:
- XTRABACKUP_PATH: a localização do ficheiro de cópia de segurança de saída
- MEMORY: a memória alocada para a preparação. Especifique entre 1 GB e 2 GB. Para mais informações sobre a opção -use-memory, consulte a documentação do Percona XtraBackup.
O tempo necessário para preparar o ficheiro de cópia de segurança pode variar consoante o tamanho da base de dados.

Carregue o ficheiro físico do XtraBackup para o Cloud Storage

Use a CLI gcloud para carregar o ficheiro de cópia de segurança para o Cloud Storage.

  gcloud storage rsync XTRABACKUP_PATH CLOUD_STORAGE_BUCKET --recursive

Substitua XTRABACKUP_PATH pela localização do ficheiro de cópia de segurança de saída e CLOUD_STORAGE_BUCKET pelo caminho do contentor do Cloud Storage.

Não existe um limite para o tamanho dos seus ficheiros do XtraBackup. No entanto, existe um limite de 5 TB para o tamanho de cada ficheiro que pode carregar para um contentor do Cloud Storage.

Defina a instância de representação de origem

Crie um ficheiro source.json que defina a instância de representação da origem para o seu servidor externo. Uma instância de representação de origem fornece metadados para o servidor externo no Cloud SQL.

No ficheiro source.json, faculte as seguintes informações básicas acerca do seu servidor externo.

{
"name": "SOURCE_NAME",
 "region": "REGION",
 "databaseVersion": "DATABASE_VERSION",
 "onPremisesConfiguration": {
    "hostPort": "SOURCE_HOST:3306",
    "username": "REPLICATION_USER_NAME",
    "password": "REPLICATION_USER_PASSWORD",
    "dumpFilePath": "CLOUD_STORAGE_BUCKET"
    "caCertificate": "SOURCE_CERT",
    "clientCertificate": "CLIENT_CERT",
    "clientKey": "CLIENT_KEY"
  }
}

Propriedade	Descrição
`SOURCE_NAME`	O nome da instância de representação da origem a criar.
`REGION`	A região onde quer que a instância de representação de origem resida. Especifique a mesma região onde vai criar a instância de réplica do Cloud SQL de destino.
`DATABASE_VERSION`	A versão da base de dados em execução no seu servidor externo. As únicas opções suportadas são `MYSQL_5_7` ou `MYSQL_8_0`.
`SOURCE_HOST`	O endereço IPv4 e a porta do servidor externo ou o endereço DNS do servidor externo. Se usar um endereço DNS, este pode conter até 60 carateres.
`USERNAME`	A conta de utilizador de replicação no servidor externo.
`PASSWORD`	A palavra-passe da conta de utilizador de replicação.
`CLOUD_STORAGE_BUCKET`	O nome do contentor do Cloud Storage que contém o ficheiro físico do XtraBackup.
`CLIENT_CA_CERT`	O certificado da AC no servidor externo. Inclua apenas se o SSL/TLS for usado no servidor externo.
`CLIENT_CERT`	O certificado de cliente no servidor externo. Obrigatório apenas para autenticação de servidor-cliente. Inclua apenas se o SSL/TLS for usado no servidor externo.
`CLIENT_KEY`	O ficheiro de chave privada para o certificado de cliente no servidor externo. Obrigatório apenas para a autenticação cliente-servidor. Inclua apenas se o SSL/TLS for usado no servidor externo.

Crie a instância de representação de origem fazendo um pedido à API Admin do Cloud SQL com o seguinte comando curl. Nos dados do pedido, faculte o ficheiro source.json que criou.

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
    --header 'Content-Type: application/json' \
    --data @./source.json \
    -X POST \
https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances

Propriedade	Descrição
`PROJECT_ID`	O ID do seu projeto em Trusted Cloud.

Identifique uma instância de réplica de destino

Crie um ficheiro que identifique a réplica de destino no Cloud SQL para a migração. Pode migrar dados para uma nova instância criando uma réplica ou pode usar uma instância do Cloud SQL existente rebaixando uma réplica.

Opção 1: crie uma instância de réplica

Para criar uma instância de réplica, use o seguinte ficheiro replica.json:

{
"name": "REPLICA_NAME",
"region": "REGION",
"databaseVersion": "DB_VERSION",
"settings": {
   "tier": "INSTANCE_TIER",
   "dataDiskSizeGb": "DISK_SIZE_GB",
   "edition": "EDITION_NAME"
},
"masterInstanceName": "SOURCE_NAME"
}

Propriedade	Descrição
`REPLICA_NAME`	O nome da réplica do Cloud SQL a criar.
`REGION`	Especifique a mesma região que atribuiu à instância de representação de origem.
`DATABASE_VERSION`	A versão da base de dados a usar com a réplica do Cloud SQL. As opções para esta versão são `MYSQL_5_7` ou `MYSQL_8_0`. Esta versão principal da base de dados tem de corresponder à versão da base de dados que especificou para o servidor externo. Também pode especificar uma versão secundária, mas esta tem de ser igual ou posterior à versão instalada no servidor externo. Para ver uma lista de strings disponíveis para o MySQL, consulte SqlDatabaseVersion.
`INSTANCE_TIER`	O tipo de máquina para alojar a instância da réplica. Tem de especificar um tipo de máquina que corresponda à edição da sua instância e ao tipo de arquitetura do seu servidor externo. Por exemplo, se selecionar `ENTERPRISE_PLUS` para o campo `edition`, tem de especificar um tipo de máquina otimizado para o desempenho da base de dados. Para ver uma lista dos tipos de máquinas suportados, consulte o artigo Tipo de máquina.
`DISK_SIZE_GB`	O tamanho do armazenamento da réplica do Cloud SQL, em GB. Importante: tem de especificar um tamanho de armazenamento superior ao tamanho do ficheiro físico que carregou para o Cloud Storage.
`EDITION_NAME`	A edição do Cloud SQL a usar para a réplica. Os valores possíveis são `ENTERPRISE_PLUS` (apenas no MySQL 8.0) ou `ENTERPRISE`.
`SOURCE_NAME`	O nome que atribuiu à instância de representação da origem.

Crie a instância de réplica de destino fazendo um pedido à API Admin do Cloud SQL com o seguinte comando curl. Nos dados do pedido, faculte o ficheiro JSON que criou.

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
    --header 'Content-Type: application/json' \
    --data @./replica.json \
    -X POST \
https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances

Propriedade	Descrição
`PROJECT_ID`	O ID do seu projeto em Trusted Cloud.

Opção 2: use uma instância de réplica existente

Certifique-se de que a instância da réplica existente tem os seguintes atributos:
- O mesmo tipo de arquitetura (x86 ou ARM) que o servidor externo.
- Pelo menos, a mesma quantidade de espaço livre no disco que os ficheiros físicos que carregou para o contentor do Cloud Storage. A instância tem de ter disco suficiente para transferir a mesma quantidade de dados do Cloud Storage.
Para usar uma instância de réplica existente, use o seguinte exemplo de ficheiro:replica.json
```
{
"demoteContext": {
    "sourceRepresentativeInstanceName": "SOURCE_NAME"
  }
}
```
Propriedade Descrição

SOURCE_NAME O nome que atribuiu à instância de representação da origem.
Rebaixe a instância de réplica de destino existente fazendo um pedido à API Admin do Cloud SQL com o seguinte comando curl. Nos dados do pedido, faculte o ficheiro JSON que criou.
```
gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
    --header 'Content-Type: application/json' \
    --data @./replica.json \
    -X POST \
https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/EXISTING_INSTANCE_ID/demote
```
Propriedade Descrição

PROJECT_ID O ID do seu projeto em Trusted Cloud.

EXISTING_INSTANCE_ID O ID da instância de réplica existente que quer usar para a migração.

Propriedade	Descrição
`SOURCE_NAME`	O nome que atribuiu à instância de representação da origem.

Valide as definições de migração

Verifique se as suas instâncias estão configuradas corretamente para a migração executando o seguinte comando.

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
             "syncMode": "SYNC_MODE",
             "skipVerification": false,
             "migrationType": "PHYSICAL"
               }' \
     -X POST \
https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/verifyExternalSyncSettings

Propriedade	Descrição
`SYNC_MODE`	Especifique `offline` para configurar a migração como um processo único. Para configurar a replicação contínua a partir do servidor externo, especifique `online`.
`PROJECT_ID`	O ID do seu projeto em Trusted Cloud.
`REPLICA_NAME`	O nome que atribuiu à instância de réplica de destino.

Como resposta inicial, este passo de validação devolve uma conta de serviço. Tem de conceder autorizações do Cloud Storage a esta conta de serviço para continuar com o processo de migração. A mensagem de erro de autorizações insuficientes é esperada. Segue-se um exemplo de resposta:

{
    "kind": "sql#externalSyncSettingError",
    "type": "INSUFFICIENT_GCS_PERMISSIONS",
    "detail": "Service account
              p703314288590-df3om0@my-project.s3ns.iam.gserviceaccount.com
              is missing necessary permissions storage.objects.list and
              storage.objects.get to access Google Cloud Storage bucket"
}

Adicione autorizações do Cloud Storage à conta de serviço devolvida

Para adicionar as autorizações necessárias, faça o seguinte:

Na Trusted Cloud consola, aceda à página Recipientes do Cloud Storage.

Aceda a Recipientes
Clique no separador Autorizações.
Clique em Conceder acesso.
No campo Novos membros, introduza o nome da conta de serviço devolvido na resposta de validação. Por exemplo, na saída de exemplo do passo anterior, o nome da conta de serviço devolvido é p703314288590-df3om0@my-project.s3ns.iam.gserviceaccount.com.
No menu pendente Selecionar uma função, selecione a função Storage Object Viewer.
Clique em Guardar.

Execute a validação novamente

Depois de adicionar as autorizações necessárias à conta de serviço, volte a executar o passo de validação para se certificar de que a conta de serviço tem acesso ao contentor do Cloud Storage.

O passo de validação verifica o seguinte:

A conetividade entre a réplica do Cloud SQL e o servidor externo está presente, mas apenas se a migração for contínua
Os privilégios do utilizador de replicação são suficientes
As versões são compatíveis
A réplica do Cloud SQL ainda não está a ser replicada
Os registos binários estão ativados no servidor externo

Se forem detetados problemas, o Cloud SQL devolve uma mensagem de erro.

Adicione utilizadores à réplica do Cloud SQL

Não pode importar nem migrar contas de utilizadores da base de dados do servidor externo. Se precisar de adicionar contas de utilizador da base de dados à réplica do Cloud SQL, adicione as contas antes de iniciar a replicação. Para mais informações, consulte o artigo Faça a gestão dos utilizadores com a autenticação integrada.

Inicie a migração

Depois de concluir a validação e não serem devolvidos erros, está tudo pronto para iniciar a migração. Para migrar o seu servidor externo, use a API startExternalSync.

Use o seguinte comando:

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
               "syncMode": "SYNC_MODE",
               "skipVerification": false,
               "migrationType": "PHYSICAL"
              }' \
     -X POST \
https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/startExternalSync

Propriedade	Descrição
`SYNC_MODE`	Especifique `offline` para configurar a migração como um processo único. Para configurar a replicação contínua a partir do servidor externo, especifique `online`.
`PROJECT_ID`	O ID do seu projeto em Trusted Cloud.
`REPLICA_NAME`	O nome que atribuiu à instância de réplica de destino.

Monitorize a migração

Para verificar o estado da sua migração, pode fazer o seguinte:

Obtenha o ID da operação da tarefa de migração a partir da resposta da API startExternalSync. Por exemplo:

{
"kind": "sql#operation",
 "targetLink": "https://sqladmin.googleapis.com/v1/projects/my-project/instances/replica-instance",
 "status": "PENDING",
 "user": "user@example.com",
 "insertTime": "******",
 "operationType": "START_EXTERNAL_SYNC",
 "name": "******",
 "targetId": "replica-instance",
 "selfLink": "https://sqladmin.googleapis.com/v1/projects/my-project/operations/OPERATION_ID",
 "targetProject": "my-project"
}

Use o ID da operação no seguinte comando.

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
    --header 'Content-Type: application/json' \
    -X GET \
https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/START_EXTERNAL_SYNC_OPERATION_ID

Propriedade	Descrição
`PROJECT_ID`	O ID do seu projeto em Trusted Cloud.
`START_EXTERNAL_SYNC_OPERATION_ID`	O ID da operação da sua tarefa de migração.

Monitorize a replicação

Quando a instância de réplica de destino no Cloud SQL terminar o carregamento de dados inicial, a instância liga-se ao servidor externo e aplica todas as atualizações feitas após a operação de exportação.

Para monitorizar o estado da replicação, consulte o artigo Confirme o estado da replicação.

Depois de a réplica do Cloud SQL receber todas as alterações do servidor externo e não existir um atraso na replicação na réplica do Cloud SQL, ligue-se à sua base de dados. Execute os comandos da base de dados adequados para se certificar de que o conteúdo é o esperado quando comparado com o servidor externo.

Depois de promover a réplica de destino para uma instância autónoma, pode eliminar os ficheiros físicos do XtraBackup no seu contentor do Cloud Storage. Mantenha o seu servidor externo até que as validações necessárias estejam concluídas.

Limitações

Esta secção apresenta as limitações do processo de migração do XtraBackup:

Tem de usar o Percona XtraBackup para fazer uma cópia de segurança dos seus dados para o contentor do Cloud Storage. Outras utilidades de cópia de segurança não são suportadas.
A migração não é suportada para versões principais ou secundárias anteriores da base de dados. Por exemplo, não pode migrar do MySQL 8.0 para o 5.7 nem do MySQL 8.0.36 para o 8.0.16.
A migração de bases de dados a partir de um ficheiro físico do XtraBackup só é suportada para bases de dados MySQL nas instalações ou uma base de dados MySQL autogerida em execução numa VM do Compute Engine. A migração do Amazon Aurora ou do MySQL em bases de dados do Amazon RDS não é suportada.
Só pode migrar a partir de uma cópia de segurança completa. Outros tipos de cópias de segurança, como cópias de segurança incrementais ou parciais, não são suportados.
A migração da base de dados não inclui utilizadores nem privilégios da base de dados.
Tem de definir o formato de registo binário como ROW. Se configurar o registo binário para qualquer outro formato, como STATEMENT ou MIXED, a replicação pode falhar.
O Cloud Storage limita o tamanho de um ficheiro que pode carregar para um contentor a 5 TB.
Não pode migrar plug-ins da sua base de dados externa.
Se tiver configurado a alta disponibilidade para a sua instância, a SLA não se aplica até que a fase inicial da migração seja concluída. Esta fase é considerada concluída quando todos os dados dos ficheiros físicos do XtraBackup tiverem sido importados para a instância do Cloud SQL.
Não pode migrar para nem a partir de uma base de dados MySQL 8.4.
A migração de bases de dados entre máquinas com tipos de arquitetura diferentes não é suportada. Por exemplo, não pode migrar uma base de dados MySQL alojada numa máquina com arquitetura ARM para uma máquina com arquitetura x86.

Resolver problemas

Esta secção apresenta cenários comuns de resolução de problemas.

Falha na importação

Se encontrar uma mensagem de erro semelhante a Attempt 1/2: import failed quando migrar, tem de especificar PHYSICAL para o migrationType quando iniciar a migração.

Se não especificar um migrationType, o tipo é predefinido como LOGICAL.

Cancele ou pare uma migração

Se precisar de cancelar ou parar uma migração, pode executar o seguinte comando:

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
    -X POST \
https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/restart

Propriedade	Descrição
`PROJECT_ID`	O ID do seu projeto em Trusted Cloud.
`REPLICA_NAME`	O nome que atribuiu à instância de réplica de destino.