Use uma importação gerida para configurar a replicação a partir de bases de dados externas

Esta página descreve como configurar e usar uma importação gerida para dados quando faz a replicação de um servidor externo para o Cloud SQL.

Tem de concluir todos os passos nesta página. Quando terminar, pode administrar e monitorizar 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, conclua estes passos:

  1. Configure o servidor externo.

  2. Crie a instância de representação da origem.

  3. Configure a réplica do Cloud SQL.

Atualize os privilégios do utilizador de replicação

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

Privilégios necessários

Existem quatro tipos de combinações de migrações e despejos.

  • Tipo 1: migração contínua e descarga gerida
  • Tipo 2: migração contínua e descarga manual
  • Tipo 3: migração única e descarga gerida
  • Tipo 4: migração única e descarga manual

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

Tipo 1

A conta de utilizador tem de ter os seguintes privilégios:

Para a versão 8.0 e superior do MySQL, recomendamos que ignore o privilégio BACKUP ADMIN para um desempenho ideal.

Tipo 2

A conta de utilizador tem de ter os seguintes privilégios:

Tipo 3

A conta de utilizador tem de ter os seguintes privilégios:

Para a versão 8.0 e superior do MySQL, recomendamos que ignore o privilégio BACKUP ADMIN para um desempenho ideal.

Tipo 4

Não são necessários privilégios.

Atualize os privilégios

Para atualizar os privilégios, abra um terminal no servidor externo e introduza 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 quer alterar.
USERNAME A conta de utilizador de replicação no servidor externo.
GCP_USERNAME O nome de utilizador da conta de utilizador.
HOST O nome do anfitrião da conta de utilizador.

Valide as definições de replicação

Após a conclusão da configuração, certifique-se de que a réplica do Cloud SQL consegue replicar a partir do servidor externo.

As seguintes definições de sincronização externa têm de estar corretas.

  • Conetividade entre a réplica do Cloud SQL e o servidor externo
  • Privilégios do utilizador de replicação
  • Compatibilidade de versões
  • A réplica do Cloud SQL ainda não está a ser replicada
  • Os registos binários estão ativados no servidor externo
  • O GTID está ativado se estiver a tentar fazer uma sincronização externa a partir de um servidor externo do RDS e estiver a usar um contentor Google Cloud

Para validar estas definições, abra um terminal do Cloud Shell e introduza os seguintes 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 flags 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

Estas chamadas devolvem uma lista do tipo sql#externalSyncSettingErrorList.

Se a lista estiver vazia, não existem erros. Uma resposta sem erros é apresentada da seguinte forma:

  {
    "kind": "sql#externalSyncSettingErrorList"
  }
Propriedade Descrição
SYNC_MODE Certifique-se de que consegue manter a réplica do Cloud SQL e o servidor externo sincronizados 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 definição que controla a velocidade à qual os dados das tabelas de uma base de dados são transferidos. Estão disponíveis os seguintes valores:

  • min: Requer a menor quantidade de recursos de computação na base de dados. Esta é a velocidade mais lenta para transferir dados.
  • optimal: Oferece um desempenho equilibrado com um carregamento ideal na base de dados.
  • max: Oferece a velocidade mais elevada para transferir dados, mas isto pode causar um aumento da carga na base de dados.

Nota: o valor predefinido deste parâmetro é optimal porque esta definição oferece uma boa velocidade de transferência dos dados e tem um impacto razoável na base de dados. Recomendamos que use este valor.
SYNC_FLAGS Uma lista de flags de sincronização inicial a validar. Recomendado apenas se planear usar flags de sincronização personalizadas ao replicar a partir da origem. Para ver uma lista das flags permitidas, consulte o artigo Flags de sincronização inicial.
PROJECT_ID O ID do seu Google Cloud projeto.
REPLICA_INSTANCE_ID O ID da sua réplica do Cloud SQL.

Autorização de bloqueio de leitura global

Se não tiver autorização para aceder ao bloqueio de leitura global no servidor externo, como pode acontecer com o Amazon RDS e o Amazon Aurora, pause as gravações no servidor, conforme descrito nos passos seguintes:

  1. Aceda ao Logs Explorer e selecione a réplica do Cloud SQL na lista de recursos. É apresentada uma lista dos registos mais recentes da réplica do Cloud SQL. Ignore-as por agora.
  2. Abra um terminal e introduza os comandos em Iniciar replicação no servidor externo para replicar a partir do servidor externo.

  3. Regresse ao Explorador de registos. Quando vir o registo da seguinte forma, pare de escrever na base de dados no seu servidor externo. Na maioria dos casos, isto só é necessário durante alguns segundos.

       DUMP_IMPORT(START): Start importing data, please pause any write to the
   external primary database.

  4. Quando vir a seguinte entrada de registo no Explorador de registos, reative a escrita na base de dados no seu servidor externo.

       DUMP_IMPORT(SYNC): Consistent state on primary and replica. Writes to the
   external primary may resume.

Inicie a replicação no servidor externo

Depois de confirmar que pode fazer a replicação a partir do servidor externo, inicie a replicação. A velocidade de execução da replicação para o processo de importação inicial é de até 500 GB por hora. No entanto, esta velocidade pode variar consoante o nível da máquina, o tamanho do disco de dados, o débito da rede e a natureza da sua base de dados.

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

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 flags 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 Verifique se consegue manter a réplica do Cloud SQL e o servidor externo sincronizados após a configuração da replicação.
SKIP_VERIFICATION Se deve ignorar o passo de validação incorporado antes de sincronizar os seus dados. Este parâmetro só é recomendado se já tiver validado as definições de replicação.
SYNC_PARALLEL_LEVEL

Fornecer uma definição que controla a velocidade à qual os dados das tabelas de uma base de dados são transferidos. Estão disponíveis os seguintes valores:

  • min: Requer a menor quantidade de recursos de computação na base de dados. Esta é a velocidade mais lenta para transferir dados.
  • optimal: Oferece um desempenho equilibrado com um carregamento ideal na base de dados.
  • max: Oferece a velocidade mais elevada para transferir dados, mas isto pode causar um aumento da carga na base de dados.

Nota: o valor predefinido deste parâmetro é optimal porque esta definição oferece uma boa velocidade de transferência dos dados e tem um impacto razoável na base de dados. Recomendamos que use este valor.
SYNC_FLAGS Uma lista de flags de sincronização inicial a validar. Recomendado apenas se planear usar flags de sincronização personalizadas ao replicar a partir da origem. Para ver uma lista das flags permitidas, consulte o artigo Flags de sincronização inicial.
PROJECT_ID O ID do seu Google Cloud projeto.
REPLICA_INSTANCE_ID O ID da sua réplica do Cloud SQL.

Sinalizações de sincronização inicial

Para migrar com flags de base de dados personalizadas, pode usar 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 ver os valores permitidos, consulte os documentos públicos do MySQL.

Monitorize a migração

Depois de iniciar a replicação a partir do servidor externo, tem de monitorizar a replicação. Para saber mais, consulte o artigo Monitorizar a replicação. Em seguida, pode concluir a migração.

Resolver problemas

Considere as seguintes opções de resolução de problemas:

Problema Resolução de problemas
A réplica de leitura não começou a ser replicada na criação. Provavelmente, existe um erro mais específico nos ficheiros de registo. Inspeccione os registos nos Registos na nuvem para encontrar o erro real.
Não é possível criar uma réplica de leitura: erro invalidFlagValue. Uma das flags no pedido é inválida. Pode ser uma flag que forneceu explicitamente ou uma que foi definida para um valor predefinido.

Primeiro, verifique se o valor da flag max_connections é superior ou igual ao valor no registo principal.

Se a flag max_connections estiver definida corretamente, inspecione os registos no Cloud Logging para encontrar o erro real.
Não é possível criar uma réplica de leitura: erro desconhecido. Provavelmente, existe um erro mais específico nos ficheiros de registo. Inspeccione os registos nos Registos na nuvem 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. Esta 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 para a atualizar para um tamanho de disco maior.
A instância da réplica está a usar demasiada memória. A réplica usa memória temporária para colocar em cache operações de leitura pedidas com frequência, o que pode fazer com que 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.
A replicação foi interrompida. O limite máximo de armazenamento foi atingido e o aumento automático do armazenamento não está ativado.

Edite a instância para ativar a autorização automatic storage increase.
O atraso de replicação é consistentemente elevado. A carga de escrita é demasiado elevada para a réplica processar. O atraso de replicação ocorre quando o segmento SQL numa réplica não consegue acompanhar o segmento de E/S. Alguns tipos de consultas ou cargas de trabalho podem causar um atraso de replicação elevado temporário ou permanente para um determinado esquema. Algumas das causas típicas do atraso na replicação são:
  • Consultas lentas na réplica. Encontre-os e corrija-os.
  • Todas as tabelas têm de ter uma chave exclusiva/principal. Cada atualização numa tabela sem uma chave única/primária provoca análises completas da tabela na réplica.
  • As consultas como DELETE ... WHERE field < 50000000 causam um atraso na replicação com a replicação baseada em linhas, uma vez que um grande número de atualizações é acumulado na réplica.

Algumas soluções possíveis incluem:
O atraso de replicação aumenta subitamente. Isto deve-se a transações de longa duração. Quando uma transação (declaração única ou várias declarações) é confirmada na instância de origem, a hora de início da transação é registada no registo binário. Quando a réplica recebe este evento binlog, compara essa data/hora com a data/hora atual para calcular o atraso da replicação. Assim, uma transação de longa duração na origem resultaria num grande atraso de replicação imediato na réplica. Se a quantidade de alterações de linhas na transação for grande, a réplica também demoraria muito tempo a executá-la. Durante este período, o atraso na replicação está a aumentar. Quando a réplica concluir esta transação, o período de sincronizaçã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, algumas soluções possíveis incluem:

  • Dividir a transação em várias transações pequenas
  • Divida uma única consulta de escrita grande em lotes mais pequenos
  • Tente separar as consultas SELECT longas de uma transação misturada com DMLs
A alteração das flags de replicação paralela resulta num erro. Foi definido um valor incorreto para uma ou mais destas flags.

Na instância principal que está a apresentar a mensagem de erro, defina as flags de replicação paralela:

  1. Modifique as flags binlog_transaction_dependency_tracking e transaction_write_set_extraction:
    • binlog_transaction_dependency_tracking=COMMIT_ORDER
    • transaction_write_set_extraction=OFF
  2. Adicione a flag slave_pending_jobs_size_max:

    slave_pending_jobs_size_max=33554432

  3. Modifique a flag transaction_write_set_extraction:

    transaction_write_set_extraction=XXHASH64

  4. Modifique a flag binlog_transaction_dependency_tracking:

    binlog_transaction_dependency_tracking=WRITESET
A criação de réplicas falha devido ao limite de tempo. As transações não comprometidas de longa duração na instância principal podem fazer com que a criação de réplicas de leitura falhe.

Recrie a réplica depois de parar todas as consultas em execução.

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

Problema Resolução de problemas
Lost connection to MySQL server during query when dumping table. A origem pode ter ficado indisponível ou o despejo continha pacotes demasiado grandes.

Certifique-se de que o dispositivo principal externo está disponível para ligação. Também pode modificar os valores das flags net_read_timeout e net_write_timeout na instância de origem para parar o erro. Para mais informações sobre os valores permitidos para estas flags, consulte o artigo Configure flags da base de dados.

Para saber mais sobre a utilização de flags mysqldumppara a migração de importações geridas, consulte o artigo Flags de sincronização inicial permitidas e predefinidas
A migração de dados inicial foi bem-sucedida, mas não está a ser feita a replicação de dados. Uma possível causa principal pode ser a base de dados de origem ter definido flags de replicação que resultam na não replicação de algumas ou todas as alterações da base de dados.

Certifique-se de que as flags de replicação, como binlog-do-db, binlog-ignore-db, replicate-do-db ou replicate-ignore-db, não estão definidas de forma conflituosa.

Execute o comando show master status na instância principal para ver as definições atuais.
A migração de dados inicial foi bem-sucedida, mas a replicação de dados deixa de funcionar após algum tempo. Opções que pode testar:

  • Verifique as métricas de replicação da instância da réplica na secção do Cloud Monitoring da Google Cloud consola.
  • Pode encontrar os erros do thread de E/S do MySQL ou do thread SQL em Cloud Logging nos ficheiros mysql.err log.
  • O erro também pode ser encontrado quando se liga à 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 da réplica. Pode aumentar manualmente o tamanho do disco ou ativar o aumento automático do armazenamento.

Reveja os registos de replicação

Quando valida as definições de replicação, são gerados registos.

Pode ver estes registos através dos seguintes passos:

  1. Aceda ao visualizador de registos na Google Cloud consola.

    Aceda ao visualizador de registos

  2. Selecione a réplica do Cloud SQL no menu pendente Instância.
  3. Selecione o ficheiro de registo replication-setup.log.

Se a réplica do Cloud SQL não conseguir estabelecer ligação ao servidor externo, confirme o seguinte:

  • Qualquer firewall no servidor externo está configurada para permitir ligações a partir do endereço IP de saída da réplica do Cloud SQL.
  • A sua configuração SSL/TLS está correta.
  • O utilizador, o anfitrião e a palavra-passe da replicação estão corretos.

O que se segue?