Usar uma importação gerenciada para configurar a replicação de bancos de dados externos

MySQL | PostgreSQL | SQL Server

Nesta página, descrevemos como configurar e usar uma importação gerenciada para dados ao replicar de um servidor externo para o Cloud SQL.

É necessário concluir todas as etapas nesta página. Quando terminar, você poderá administrar e monitorar a instância de representação de origem da mesma forma que faria com qualquer outra instância do Cloud SQL.

Antes de começar

Antes de começar, siga estas etapas:

Atualizar privilégios do usuário de replicação

O usuário de replicação no servidor externo está configurado para aceitar conexões de qualquer host (%). Atualize esta conta de usuário para que ela possa ser usada apenas com a réplica do Cloud SQL.

Privilégios necessários

Há quatro tipos de combinações de migrações e despejos.

Tipo 1: migração contínua e despejo gerenciado
Tipo 2: migração contínua e despejo manual
Tipo 3: migração única e despejo gerenciado
Tipo 4: migração única e despejo manual

Os privilégios para cada tipo de combinação de migração e despejo estão listados abaixo.

Tipo 1

A conta de usuário precisa ter os seguintes privilégios:

REPLICATION SLAVE
EXECUTE
SELECT
SHOW VIEW
REPLICATION CLIENT
ATUALIZAR
TRIGGER
(Somente para migração do Amazon RDS e do Amazon Aurora) LOCK TABLES

No MySQL versão 8.0 e posterior, é recomendável pular o privilégio BACKUP ADMIN para otimizar o desempenho.

Tipo 2

A conta de usuário precisa ter os seguintes privilégios:

Tipo 3

A conta de usuário precisa ter os seguintes privilégios:

SELECT
SHOW VIEW
TRIGGER
(Somente para migração de origens com a configuração GTID_MODE = ON) RELOAD

No MySQL versão 8.0 e posterior, é recomendável pular o privilégio BACKUP ADMIN para otimizar o desempenho.

Tipo 4

Nenhum privilégio necessário.

Atualizar privilégios

Para atualizar privilégios, abra um terminal no servidor externo e digite os seguintes comandos.

Cliente MySQL

Para GTID:

    UPDATE mysql.user
      SET Host='NEW_HOST'
      WHERE Host='OLD_HOST'
      AND User='USERNAME';
    GRANT REPLICATION SLAVE, EXECUTE, SELECT, SHOW VIEW, REPLICATION_CLIENT,
    RELOAD ON . TO
    'USERNAME'@'HOST';
    FLUSH PRIVILEGES;

Para binlog:

    UPDATE mysql.user
    SET Host='NEW_HOST'
    WHERE Host='OLD_HOST'
    AND User='USERNAME';
    GRANT REPLICATION SLAVE, EXECUTE, SELECT, SHOW VIEW, REPLICATION CLIENT,
    RELOAD ON . TO 'GCP_USERNAME'@'HOST';
    FLUSH PRIVILEGES;

exemplo

UPDATE mysql.user
  SET Host='192.0.2.0'
  WHERE Host='%'
  AND User='replicationUser';
GRANT REPLICATION SLAVE, EXECUTE, SELECT, SHOW VIEW, REPLICATION CLIENT,
RELOAD ON *.* TO 'username'@'host.com';
FLUSH PRIVILEGES;

Propriedade	Descrição
`NEW_HOST`	Especifique o IP de saída da réplica do Cloud SQL.
`OLD_HOST`	O valor atual atribuído a `Host` que você quer alterar.
`USERNAME`	A conta do usuário de replicação no servidor externo.
`GCP_USERNAME`	O nome de usuário da conta de usuário.
`HOST`	O nome do host da conta de usuário.

Verificar as configurações de replicação

Após a conclusão da configuração, verifique se a réplica do Cloud SQL pode ser replicada do servidor externo.

As configurações de sincronização externa a seguir precisam estar corretas.

Conectividade entre a réplica do Cloud SQL e o servidor externo
Privilégios de usuário de replicação
Compatibilidade de versões
A réplica do Cloud SQL ainda não está replicando
Os registros binários estão ativados no servidor externo
GTID é ativado se você estiver tentando fazer uma sincronização externa de um servidor externo no RDS e estiver usando um bucket do Google Cloud

Para verificar essas configurações, abra um terminal do Cloud Shell e insira estes comandos:

curl

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",
         "syncParallelLevel": "SYNC_PARALLEL_LEVEL",
         "mysqlSyncConfig": {
           "initialSyncFlags": "SYNC_FLAGS"
         }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_INSTANCE_ID/verifyExternalSyncSettings

exemplo

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal"
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/myproject/instances/myreplica/verifyExternalSyncSettings

exemplo com sinalizações de sincronização

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal"
         "mysqlSyncConfig": {
             "initialSyncFlags": [{"name": "max-allowed-packet", "value": "1073741824"}, {"name": "hex-blob"}, {"name": "compress"}]
             }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/replica-instance/verifyExternalSyncSettings

Essas chamadas retornam uma lista do tipo sql#externalSyncSettingErrorList.

Se a lista estiver vazia, não há erros. Uma resposta sem erros é exibida desta forma:

  {
    "kind": "sql#externalSyncSettingErrorList"
  }

Propriedade	Descrição
`SYNC_MODE`	Garante que você possa manter a réplica do Cloud SQL e o servidor externo em sincronia após a configuração da replicação. Os modos de sincronização incluem `EXTERNAL_SYNC_MODE_UNSPECIFIED`, `ONLINE` e `OFFLINE`.
`SYNC_PARALLEL_LEVEL`	Verifique a configuração que controla a velocidade com que os dados das tabelas de um banco de dados são transferidos. Os seguintes valores estão disponíveis: `min:` usa a menor quantidade de recursos de computação no banco de dados. Essa é a velocidade mais lenta para a transferência de dados. `optimal:` Proporciona um desempenho equilibrado com uma carga ideal no banco de dados. `max:` Fornece a velocidade mais alta para a transferência de dados, mas isso pode causar um aumento da carga no banco de dados. Observação:o valor padrão desse parâmetro é `optimal`, porque essa configuração fornece uma boa velocidade para transferir os dados e tem um impacto razoável no banco de dados. Recomendamos que você use esse valor padrão.
`SYNC_FLAGS`	Uma lista de sinalizações de sincronização inicial para verificar. Recomendado apenas se você planeja usar sinalizações de sincronização personalizadas ao replicar pela origem. Para uma lista de sinalizações permitidas, consulte Flags de sincronização inicial.
`PROJECT_ID`	o ID do seu projeto do Google Cloud;
`REPLICA_INSTANCE_ID`	O código da sua réplica do Cloud SQL.

Permissão de bloqueio de leitura global

Se você não tiver permissão para acessar o bloqueio de leitura global no servidor externo, como pode ser o caso com o Amazon RDS e o Amazon Aurora, pause as gravações no seu servidor conforme descrito nas etapas a seguir:

Acesse o Explorador de registros e selecione a réplica do Cloud SQL na lista de recursos. Você precisa ver uma lista dos registros mais recentes da sua réplica do Cloud SQL. Ignore-os por enquanto.
Abra um terminal e insira os comandos em Iniciar replicação no servidor externo para replicar a partir do servidor externo.
Retorne ao Explorador de registros. Quando o registro aparecer assim, pare de gravar no banco de dados no servidor externo. Na maioria dos casos, isso é necessário apenas por alguns segundos.
```
   DUMP_IMPORT(START): Start importing data, please pause any write to the
   external primary database.
```
Quando você vir a seguinte entrada de registro no Explorador de registros, reative a gravação no banco de dados no servidor externo.
```
   DUMP_IMPORT(SYNC): Consistent state on primary and replica. Writes to the
   external primary may resume.
```

Iniciar replicação no servidor externo

Depois de verificar se é possível replicar usando o servidor externo, inicie a replicação. A velocidade para executar a replicação do processo de importação inicial é de até 500 GB por hora. No entanto, essa velocidade pode variar de acordo com a camada da máquina, o tamanho do disco de dados, a capacidade da rede e a natureza do banco de dados.

Durante o processo de importação inicial, não execute nenhuma operação DDL no servidor externo. Isso pode causar inconsistências durante a importação. Após a conclusão do processo de importação, a réplica usará os registros binários no servidor externo para alcançar o estado atual desse servidor.

curl

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": "SKIP_VERIFICATION",
         "syncParallelLevel": "SYNC_PARALLEL_LEVEL",
         "mysqlSyncConfig": {
           "initialSyncFlags": "SYNC_FLAGS"
         }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_INSTANCE_ID/startExternalSync

exemplo

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal"
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/replica-instance/startExternalSync

exemplo com sinalizações de sincronização

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal"
         "skipVerification": false,
         "mysqlSyncConfig": {
             "initialSyncFlags": [{"name": "max-allowed-packet", "value": "1073741824"}, {"name": "hex-blob"}, {"name": "compress"}]
             }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/replica-instance/startExternalSync

Propriedade	Descrição
`SYNC_MODE`	Garante que você possa manter a réplica do Cloud SQL e o servidor externo em sincronia após a configuração da replicação.
`SKIP_VERIFICATION`	Define se a etapa de verificação integrada deve ser ignorada antes de sincronizar seus dados. Esse parâmetro é recomendado apenas se você já tiver verificado as configurações de replicação.
`SYNC_PARALLEL_LEVEL`	Forneça uma configuração que controle a velocidade com que os dados das tabelas de um banco de dados são transferidos. Os seguintes valores estão disponíveis: `min:` usa a menor quantidade de recursos de computação no banco de dados. Essa é a velocidade mais lenta para a transferência de dados. `optimal:` Proporciona um desempenho equilibrado com uma carga ideal no banco de dados. `max:` Fornece a velocidade mais alta para a transferência de dados, mas isso pode causar um aumento da carga no banco de dados. Observação:o valor padrão desse parâmetro é `optimal`, porque essa configuração fornece uma boa velocidade para transferir os dados e tem um impacto razoável no banco de dados. Recomendamos que você use esse valor padrão.
`SYNC_FLAGS`	Uma lista de sinalizações de sincronização inicial para verificar. Recomendado apenas se você planeja usar sinalizações de sincronização personalizadas ao replicar pela origem. Para uma lista de sinalizações permitidas, consulte Flags de sincronização inicial.
`PROJECT_ID`	o ID do seu projeto do Google Cloud;
`REPLICA_INSTANCE_ID`	O código da sua réplica do Cloud SQL.

Flags iniciais de sincronização

Para migrar com flags personalizadas de banco de dados, use as seguintes flags permitidas:

--add-drop-database
--add-drop-table
--add-drop-trigger
--add-locks
--allow-keywords
--all-tablespaces
--apply-slave-statements
--column-statistics
--comments
--compact
--compatible
--complete-insert
--compress
--compression-algorithms
--create-options
--default-character-set
--delayed-insert
--disable-keys
--dump-date
--events
--extended-insert
--fields-enclosed-by
--fields-escaped-by
--fields-optionally-enclosed-by
--fields-terminated-by
--flush-logs
--flush-privileges
--force
--get-server-public-key
--hex-blob
--ignore-error
--ignore-read-lock-error
--ignore-table
--insert-ignore
--lines-terminated-by
--lock-all-tables
--lock-tables
--max-allowed-packet
--net-buffer-length
--network-timeout
--no-autocommit
--no-create-db
--no-create-info
--no-data
--no-defaults
--no-set-names
--no-tablespaces
--opt
--order-by-primary
--pipe
--quote-names
--quick
--replace
--routines
--secure-auth
--set-charset
--shared-memory-base-name
--show-create-skip-secondary-engine
--skip-opt
--ssl-cipher
--ssl-fips-mode
--ssl-verify-server-cert
--tls-ciphersuites
--tls-version
--triggers
--tz-utc
--verbose
--xml
--zstd-compression-level

Para valores permitidos, consulte os documentos públicos do MySQL.

Monitorar a migração

Depois de iniciar a replicação pelo servidor externo, é necessário monitorar a replicação. Para saber mais, consulte Como monitorar a replicação. Em seguida, conclua a migração.

Resolver problemas

Considere estas opções de solução de problemas:

Problema	Solução de problemas
A réplica de leitura não começou a ser replicada na criação.	Provavelmente há um erro mais específico nos arquivos de registro. Inspecione os registros no Cloud Logging para encontrar o erro real.
Não foi possível criar a réplica de leitura: erro invalidFlagValue.	Uma das sinalizações na solicitação é inválida. Pode ser uma sinalização fornecida explicitamente ou uma que foi definida como um valor padrão. Primeiro, verifique se o valor da sinalização `max_connections` é maior ou igual ao valor na instância principal. Se a sinalização `max_connections` estiver definida corretamente, inspecione os registros no Cloud Logging para encontrar o erro real.
Não foi possível criar a réplica de leitura: erro desconhecido.	Provavelmente há um erro mais específico nos arquivos de registro. Inspecione os registros no Cloud Logging para encontrar o erro real. Se o erro for: `set Service Networking service account as servicenetworking.serviceAgent role on consumer project`, desative e reative o `Service Networking API`. Essa ação cria a conta de serviço necessária para continuar com o processo.
O disco está cheio.	O tamanho do disco da instância principal pode ficar cheio durante a criação da réplica. Edite a instância principal com upgrade para um tamanho de disco maior.
A instância da réplica está usando memória demais.	A réplica usa memória temporária para armazenar em cache as operações de leitura solicitadas com frequência, o que pode fazer com que ela use mais memória do que a instância principal. Reinicie a instância da réplica para recuperar o espaço de memória temporário.
Replicação interrompida.	O limite máximo de armazenamento foi atingido e o aumento automático de armazenamento não está ativado. Edite a instância para ativar `automatic storage increase`.
O atraso da replicação é consistentemente alto.	A carga de gravação é alta demais para a réplica processar. O atraso de replicação ocorre quando a linha de execução SQL em uma réplica não consegue acompanhar a linha de execução de E/S. Alguns tipos de consultas ou cargas de trabalho podem causar um atraso de replicação temporário ou permanente para um determinado esquema. Estas são algumas das causas comuns do atraso de replicação: Consultas lentas na réplica. Encontre e corrija esses problemas. Todas as tabelas precisam ter uma chave primária/exclusiva. Cada atualização em uma tabela sem uma chave exclusiva/principal resulta em varreduras completas na tabela da réplica. Consultas como `DELETE ... WHERE field < 50000000` causam atraso de replicação com base em linha, já que um grande número de atualizações é acumulado na réplica. Algumas soluções possíveis incluem: Configure a replicação paralela. Defina a sinalização innodb_flush_log_at_trx_commit na réplica de leitura como 2. Para mais informações, consulte Dicas para trabalhar com sinalizações. Editar a instância para aumentar o tamanho da réplica. Reduza a carga no banco de dados. Envia o tráfego de leitura para a réplica de leitura. Inclua as tabelas em um índice. Identifique e corrija consultas de gravação lentas. Recrie a réplica.
De repente, o atraso de replicação aumenta.	Isso é causado por transações de longa duração. Quando uma transação (instrução única ou várias instruções) é confirmada na instância de origem, o horário de início da transação é gravado no registro binário. Quando a réplica recebe esse evento do binlog, ela compara esse carimbo de data/hora com aquele atual para calcular o atraso da replicação. Dessa forma, uma transação de longa duração na origem resultaria em um grande atraso de replicação imediato na réplica. Se a quantidade de mudanças de linhas na transação for grande, a réplica também levará muito tempo para executá-la. Durante esse período, o atraso da replicação está aumentando. Quando a réplica termina essa transação, o período de recuperação depende da carga de trabalho de gravação na origem e da velocidade de processamento da réplica. Para evitar uma transação longa, veja algumas soluções possíveis: Dividir a transação em várias transações pequenas Divida uma única consulta de gravação grande em lotes menores Tente separar consultas de SELECT longas de uma transação combinada com DMLs.
Alterar sinalizações paralelas de replicação resulta em um erro.	Um valor incorreto é definido para uma ou mais dessas sinalizações. Na instância principal exibindo a mensagem de erro, defina as sinalizações de replicação paralela: Modifique as sinalizações `binlog_transaction_dependency_tracking` e `transaction_write_set_extraction`: `binlog_transaction_dependency_tracking=COMMIT_ORDER` `transaction_write_set_extraction=OFF` Adicione a sinalização `slave_pending_jobs_size_max`: `slave_pending_jobs_size_max=33554432` Modifique a sinalização `transaction_write_set_extraction`: `transaction_write_set_extraction=XXHASH64` Modifique a sinalização `binlog_transaction_dependency_tracking`: `binlog_transaction_dependency_tracking=WRITESET`
A criação da réplica falha com o tempo limite.	Transações não confirmadas de longa duração na instância primária podem causar falha na criação da réplica de leitura. Recrie a réplica depois de interromper todas as consultas em execução.

Além disso, para o MySQL, considere também as seguintes opções:

Problema	Solução de problemas
`Lost connection to MySQL server during query when dumping table`.	A origem pode ter ficado indisponível ou o dump continha pacotes muito grandes. Verifique se a instância principal externa está disponível para conexão. Também é possível modificar os valores das sinalizações net_read_timeout e net_write_timeout na instância de origem para interromper o erro. Para mais informações sobre os valores permitidos para essas sinalizações, consulte Configurar sinalizações do banco de dados. Para saber mais sobre como usar sinalizações `mysqldump` para migração de importação gerenciada, consulte Sinalizações de sincronização inicial permitidas e padrão
A migração inicial dos dados foi bem-sucedida, mas nenhum dado está sendo replicado.	Uma possível causa raiz pode ser sinalizações de replicação definidas pelo banco de dados de origem, o que faz com que algumas ou todas as alterações do banco de dados não sejam replicadas. Verifique se as sinalizações de replicação, como `binlog-do-db`, `binlog-ignore-db`, `replicate-do-db` ou `replicate-ignore-db` não estão definidas de maneira conflitante. Execute o comando `show master status` na instância principal para ver as configurações atuais.
A migração inicial de dados foi bem-sucedida, mas a replicação de dados deixa de funcionar após um tempo.	O que tentar Verifique as métricas de replicação da instância de réplica na seção Cloud Monitoring do console do Google Cloud. Os erros da linha de execução de E/S do MySQL ou do SQL podem ser encontrados no Cloud Logging nos arquivos `mysql.err log`. O erro também pode ser encontrado ao se conectar à instância da réplica. Execute o comando `SHOW SLAVE STATUS` e verifique os seguintes campos na saída: Slave_IO_Running Slave_SQL_Running Last_IO_Error Last_SQL_Error
`mysqld check failed: data disk is full`.	O disco de dados da instância da réplica está cheio. Aumente o tamanho do disco da instância de réplica. Aumente o tamanho do disco manualmente ou ative o aumento automático de armazenamento.

Analisar os registros de replicação

Ao verificar as configurações de replicação, os registros são gerados.

Para visualizar esses registros, siga estas etapas:

Acesse o visualizador de registros no console do Google Cloud:

Acessar o Visualizador de registros
Selecione a réplica do Cloud SQL na lista suspensa Instância.
Selecione o arquivo de registro replication-setup.log.

Se a réplica do Cloud SQL não conseguir se conectar ao servidor externo, confirme o seguinte:

Qualquer firewall no servidor do banco de dados de origem é configurado para permitir conexões usando o endereço IP de saída da réplica do Cloud SQL.
Sua configuração SSL/TLS está correta.
Seu usuário, host e senha de replicação estão corretos.

A seguir

Saiba mais sobre como atualizar uma instância.
Saiba mais sobre o gerenciamento de réplicas.
Saiba mais sobre como monitorar instâncias.
Saiba mais sobre como promover sua réplica do Cloud SQL.