Resolver problemas

Execute o comando gcloud sql operations list para listar todas as operações da instância do Cloud SQL especificada.

Procure nos registos e filtre por texto para encontrar o utilizador. Pode ter de usar registos de auditoria para informações privadas. Os ficheiros de registo relevantes incluem:

• cloudsql.googlapis.com/mysql-general.log
• cloudsql.googleapis.com/mysql.err
• Se os registos de auditoria do Google Cloud estiverem ativados e tiver as autorizações necessárias para os ver, o cloudaudit.googleapis.com/activity também pode estar disponível.

Se eliminar uma instância sem fazer uma cópia de segurança final dos dados, não é possível recuperar os dados. No entanto, se restaurar a instância, o Cloud SQL também restaura as cópias de segurança. Para mais informações sobre a recuperação de uma instância eliminada, consulte o artigo Mantenha as cópias de segurança após a eliminação da instância.

Se tiver feito uma operação de exportação, crie uma nova instância e, em seguida, faça uma operação de importação para recriar a base de dados. As exportações são escritas no Cloud Storage e as importações são lidas a partir daí.

Se realmente precisar de cancelar a operação, pode pedir ao apoio ao cliente que force restart a instância.

Crie os utilizadores da base de dados antes de restaurar o despejo SQL.

Para manter as cópias de segurança indefinidamente, pode criar uma cópia de segurança a pedido, uma vez que não são eliminadas da mesma forma que as cópias de segurança automáticas. As cópias de segurança a pedido permanecem indefinidamente. Ou seja, permanecem até serem eliminados ou a instância à qual pertencem ser eliminada. Uma vez que esse tipo de cópia de segurança não é eliminado automaticamente, pode afetar a faturação.

• Defina o valor de cópia de segurança final para corresponder à configuração de cópia de segurança existente da instância.
• Deixe o campo de cópia de segurança final vazio quando eliminar a instância. Se deixar o campo vazio, o Cloud SQL usa a configuração de cópia de segurança final definida nas definições da instância para fazer uma cópia de segurança final e definir a respetiva retenção.

Está a tentar cancelar uma operação de importação ou exportação que foi concluída, falhou ou foi cancelada. Se a operação estiver em execução, pode cancelá-la.

O Cloud SQL não suporta o cancelamento da operação porque tem um tipo de operação diferente de IMPORT ou EXPORT.

De momento, o Cloud SQL não pode cancelar a operação de importação ou exportação. Tente novamente dentro de alguns segundos. Se o problema persistir, contacte o Trusted Cloud by S3NS apoio técnico.

Remova todas as entradas de Authorized Networks da instância do Cloud SQL, se possível. Caso contrário, crie uma réplica sem entradas Authorized Networks.

Está a tentar usar a Trusted Cloud consola para clonar uma instância com um endereço IP privado, mas não especificou o intervalo de IP alocado que quer usar, e a instância de origem não foi criada com o intervalo especificado. Como resultado, a instância clonada é criada num intervalo aleatório.

Use gcloud para clonar a instância e fornecer um valor para o parâmetro
--allocated-ip-range-name. Para mais informações, consulte o artigo Clonar uma instância com um IP privado.

• Instabilidade de rede.
• Nenhuma resposta aos comandos TCP keep-alive (o cliente ou o servidor não está a responder, possivelmente sobrecarregado)
• O tempo de vida da ligação do motor da base de dados foi excedido e o servidor termina a ligação.

As aplicações têm de tolerar falhas de rede e seguir as práticas recomendadas , como a pool de ligações e a repetição. A maioria dos agrupadores de ligações deteta estes erros sempre que possível. Caso contrário, a aplicação tem de tentar novamente ou falhar sem problemas.

Para repetir a ligação, recomendamos os seguintes métodos:

1. Retirada exponencial. Aumente o intervalo de tempo entre cada nova tentativa de forma exponencial.
2. Adicione também uma repetição aleatória.

A combinação destes métodos ajuda a reduzir a limitação.

Os certificados de cliente expiraram ou o caminho para os certificados não está correto.

Regenerar os certificados recriando-os.

• O tamanho do intervalo de IP atribuído para a ligação de serviço privada é inferior a /24.
• A dimensão do intervalo de IP atribuído para a ligação de serviço privado é demasiado pequena para o número de instâncias do Cloud SQL.
• O requisito relativo ao tamanho do intervalo de IPs atribuído é maior se forem criadas instâncias em várias regiões. Veja a dimensão do intervalo atribuído

Para resolver este problema, pode expandir o intervalo de IPs atribuído existente ou atribuir um intervalo de IPs adicional à ligação de serviço privado. Para mais informações, consulte o artigo Atribua um intervalo de endereços IP.

Se usou a flag --allocated-ip-range-name ao criar a instância do Cloud SQL, só pode expandir o intervalo de IP especificado.

Se estiver a atribuir um novo intervalo, certifique-se de que a atribuição não se sobrepõe a nenhuma atribuição existente.

Depois de criar um novo intervalo de IPs, atualize o peering de VPC com o seguinte comando:

gcloud services vpc-peerings update \
--service=servicenetworking.googleapis.com \
--ranges=OLD_RESERVED_RANGE_NAME,NEW_RESERVED_RANGE_NAME \
--network=VPC_NETWORK \
--project=PROJECT_ID \
--force
    

Se estiver a expandir uma atribuição existente, tenha cuidado para aumentar apenas o intervalo de atribuição e não o diminuir. Por exemplo, se a atribuição original for 10.0.10.0/24, faça a nova atribuição, pelo menos, em 10.0.10.0/23.

Em geral, se começar com uma atribuição /24, diminuir a máscara em 1 para cada condição (grupo de tipos de instâncias adicional, região adicional) é uma boa regra geral. Por exemplo, se tentar criar grupos de tipos de instâncias em simultâneo na mesma atribuição, passar de /24 para /23 é suficiente.

Depois de expandir um intervalo de IP existente, atualize a interligação de VPC com o seguinte comando:

gcloud services vpc-peerings update \
--service=servicenetworking.googleapis.com \
--ranges=RESERVED_RANGE_NAME \
--network=VPC_NETWORK \
--project=PROJECT_ID
    

Ative a API Service Networking através do seguinte comando e tente criar novamente a instância do Cloud SQL.

gcloud services enable servicenetworking.googleapis.com \
--project=PROJECT_ID
    

Verifique se os nomes DNS que quer adicionar ao certificado do servidor de uma instância do Cloud SQL cumprem os seguintes critérios:

• Não têm carateres universais.
• Não têm pontos finais.
• Cumprem as especificações da RFC 1034.

Use exportações de CSV para exportar apenas o que precisa.

Use a transferência de exportação. A um nível elevado, na descarga de exportação, em vez de emitir uma exportação na instância de origem, o Cloud SQL inicia uma instância de descarga para realizar a exportação. A transferência da exportação tem várias vantagens, incluindo um aumento do desempenho na instância de origem e o desbloqueio de operações administrativas enquanto a exportação está em execução. Com a transferência da exportação, a latência total pode aumentar pela quantidade de tempo que demora a apresentar a instância de transferência. Geralmente, para exportações de tamanho razoável, a latência não é significativa. No entanto, se a exportação for suficientemente pequena, pode notar o aumento na latência.

Pode criar o seu próprio sistema de exportação automatizado usando produtos como o Cloud Scheduler, o Pub/Sub e as funções do Cloud Run, semelhantes a este artigo sobre a automatização de cópias de segurança. Trusted Cloud by S3NS

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

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.

• Verifique as métricas de replicação da instância da réplica na secção do Cloud Monitoring da Trusted 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

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.

Crie um novo ficheiro de despejo com as definições de flags corretas e configure a réplica externa com esse ficheiro

1. Ligue-se ao seu cliente mysql através de uma instância do Compute Engine.
2. Execute mysqldump e use as flags --master-data=1 e --flush-privileges.

   Importante: não inclua a --set-gtid-purged=OFF sinalização.

   Saiba mais.

3. Certifique-se de que o ficheiro de despejo acabado de criar contém a linha SET @@GLOBAL.GTID_PURGED='...'.
4. Carregue o ficheiro de despejo para um contentor do Cloud Storage e configure a réplica com o ficheiro de despejo.

Edite a instância para atualizar para um tamanho de máquina maior e ter mais CPUs e memória.

Feche operações não usadas. Verifique a utilização de memória e CPU da sua instância do Cloud SQL para se certificar de que existem muitos recursos disponíveis. A melhor forma de garantir o máximo de recursos para a importação é reiniciar a instância antes de começar a operação.

Um reinício:

• Fecha todas as ligações.
• Termina todas as tarefas que possam estar a consumir recursos.

Crie os utilizadores da base de dados antes da importação.

Opções que pode testar:

Adicione a seguinte linha no início do ficheiro de despejo:

SET FOREIGN_KEY_CHECKS=0;
  

Além disso, adicione esta linha no final do ficheiro de despejo:

SET FOREIGN_KEY_CHECKS=1;
  

Estas definições desativam as verificações de integridade de dados enquanto a operação de importação está em curso e reativam-nas após o carregamento dos dados. Isto não afeta a integridade dos dados na base de dados, porque os dados já foram validados durante a criação do ficheiro de despejo.

Por exemplo, um utilizador foi eliminado, mas não consegue saber quem o fez. Os registos mostram que a operação foi iniciada, mas não fornecem mais informações. Tem de ativar o registo de auditoria para que informações de identificação pessoal (PII) detalhadas e pessoais como estas sejam registadas.

Associe à base de dados e execute estes comandos para ver detalhes sobre cada tipo:

SHOW VARIABLES LIKE 'innodb_log_file%';

SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2),2)
AS GB from mysql.general_log;

SHOW BINARY LOGS;
    

Para transferir os registos como JSON:

gcloud logging read \
"resource.type=cloudsql_database \
AND logName=projects/PROJECT_ID \
/logs/cloudsql.googleapis.com%2FLOG_NAME" \
--format json \
--project=PROJECT_ID \
--freshness="1d" \
> downloaded-log.json
    

Para transferir os registos como TEXTO:

gcloud logging read \
"resource.type=cloudsql_database \
AND logName=projects/PROJECT_ID \
/logs/cloudsql.googleapis.com%2FLOG_NAME" \
--format json \
--project=PROJECT_ID \
--freshness="1d"| jq -rnc --stream 'fromstream(1|truncate_stream(inputs)) \
| .textPayload' \
--order=asc
> downloaded-log.txt
   

Pode saber o tamanho dos registos gerais estabelecendo ligação à base de dados e executando esta consulta:

Opções que pode testar:

• Pode verificar o armazenamento ocupado pelos registos binários através do seguinte comando na interface de linha de comandos do MySQL: SHOW BINARY LOGS;
• As tabelas temporárias também podem estar a ocupar uma quantidade significativa de espaço de armazenamento. Para verificar a utilização do espaço temporário, use o seguinte comando: SELECT * FROM INFORMATION_SCHEMA.FILES WHERE TABLESPACE_NAME='innodb_temporary'\G.
• O seguinte comando permite-lhe verificar o tamanho do registo de repetição: SHOW VARIABLES LIKE 'innodb_log_file%';
• Pode verificar o tamanho do general_log, se estiver ativado, com a ajuda deste comando: SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2)),2) AS GB from mysql.general_log;
• Se necessário, pode truncar as tabelas de registo através da API. Para mais informações, consulte a página de referência instances.truncateLog.
• Saiba mais sobre como definir e configurar registos de consultas lentas.

Associe à base de dados e execute esta consulta:

SHOW PROCESSLIST.

O primeiro item na lista pode ser o que está a reter o bloqueio, pelo qual os itens subsequentes estão à espera.

A consulta SHOW INNODB STATUS também pode ser útil.

SELECT * FROM INFORMATION_SCHEMA.FILES WHERE TABLESPACE_NAME='innodb_temporary'\G

Associe à base de dados e execute a seguinte consulta:

SELECT TABLE_SCHEMA, TABLE_NAME, sum(DATA_LENGTH+INDEX_LENGTH)/pow(1024,2) FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA NOT IN ('PERFORMANCE_SCHEMA','INFORMATION_SCHEMA','SYS','MYSQL') GROUP BY TABLE_SCHEMA, TABLE_NAME;

Fragmente a instância se possível. Usar muitas instâncias do Cloud SQL mais pequenas é melhor do que uma instância grande.

O reinício elimina os ficheiros temporários, mas não reduz o armazenamento. Apenas o apoio ao cliente pode repor o tamanho da instância.

Procure nos registos a hora da eliminação e verifique se existe um script malicioso em execução a partir de um painel de controlo ou de outro processo automatizado.

Algumas explicações possíveis incluem:

• Está em curso outra operação. As operações do Cloud SQL não são executadas em simultâneo. Aguarde pela conclusão da outra operação.
• O aviso INSTANCE_RISKY_FLAG_CONFIG é acionado sempre que estiver a ser usada, pelo menos, uma flag beta. Remova as definições de sinalização de risco e reinicie a instância

Infelizmente, não pode reduzir o tamanho do ficheiro ibtmp1 por nenhum método, exceto reiniciando o serviço.

Uma opção de mitigação é criar a tabela temporária com ROW_FORMAT=COMPRESSED, para que seja armazenada em espaços de tabelas de ficheiros por tabela no diretório de ficheiros temporários. No entanto, a desvantagem são os custos de desempenho associados à criação e remoção de um tablespace de ficheiro por tabela para cada tabela temporária.

Se a sua instância ficar sem armazenamento e a capacidade de aumento automático do armazenamento não estiver ativada, a instância fica offline. Para evitar este problema, pode editar a instância para ativar o aumento automático do armazenamento.

Ao ter ligações com uma duração inferior a 60 segundos, é possível evitar a maioria dos encerramentos não limpos, incluindo ligações a partir da linha de comandos da base de dados. Se mantiver estas ligações abertas durante horas ou dias, os encerramentos podem não ser limpos.

Descubra que objetos dependem do utilizador e, em seguida, elimine ou reatribua esses objetos a outro utilizador.

Consulte, em particular, as dicas de desempenho geral.

Para inserções, atualizações ou eliminações lentas na base de dados, considere as seguintes ações:

• Se ativar a long_query_timeflag, pode verificar os registos de consultas lentas. Aceda à página Explorador de registos do seu projeto e execute uma consulta como esta:

  resource.type="cloudsql_database"
  resource.labels.database_id="INSTANCE-ID"
  log_name="projects/PROJECT-ID/logs/cloudsql.googleapis.com%2Fmysql-slow.log"
        

  Pode transferir os registos no formato JSON ou TEXT para processamento local.

• Verifique as localizações do escritor e da base de dados. O envio de dados a uma longa distância introduz latência.
• Verifique a localização do leitor e da base de dados. A latência afeta o desempenho de leitura ainda mais do que o desempenho de escrita

Para reduzir a latência, recomendamos que localize os recursos de origem e de destino na mesma região.

Existem outros fatores, além da sua carga de trabalho, que podem afetar a utilização de memória, como o número de ligações ativas e os processos internos gerais. Estas nem sempre se refletem nos gráficos de monitorização.

Certifique-se de que a instância tem sobrecarga suficiente para ter em conta a sua carga de trabalho, além de alguma sobrecarga adicional.

Para preservar os seus dados, exporte-os para o Cloud Storage antes de eliminar uma instância.

A função de administrador do Cloud SQL inclui a autorização para eliminar a instância. Para evitar a eliminação acidental, conceda esta função apenas quando necessário.

Existem outras formas de atingir o objetivo criando uma nova instância.

• Pode clonar a instância que quer mudar o nome e definir um novo nome para a instância clonada. Isto permite-lhe criar a nova instância sem ter de importar dados manualmente. Tal como quando cria uma nova instância, a instância clonada tem um novo endereço IP.
• Pode exportar dados da sua instância para um contentor do Cloud Storage, criar uma nova instância com o novo nome pretendido e, em seguida, importar os dados para a nova instância.

Em ambos os casos, pode eliminar a instância antiga após a conclusão da operação. Recomendamos que opte pela clonagem, uma vez que não tem impacto no desempenho e não requer que refaça as definições de configuração da instância, como flags, tipo de máquina, tamanho do armazenamento e memória.

1. Verifique o estado do ponto final.

   gcloud

   Para verificar o estado, use o comando
   gcloud compute forwarding-rules describe.

   gcloud compute forwarding-rules describe ENDPOINT_NAME \
   --project=PROJECT_ID \
   --region=REGION_NAME \
   | grep pscConnectionStatus

   Faça as seguintes substituições:

   • ENDPOINT_NAME: o nome do ponto final
   • PROJECT_ID: o ID ou o número do projeto do projeto Trusted Cloud que contém o ponto final
   • REGION_NAME: o nome da região do ponto final

   REST

   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 projeto Trusted Cloud que contém o ponto final do Private Service Connect
   • REGION_NAME: o nome da região
   • ENDPOINT_NAME: o nome do ponto final

   Método HTTP e URL:

   GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME

   Para enviar o seu pedido, expanda uma destas opções:

   curl (Linux, macOS ou Cloud Shell)

   Execute o seguinte comando:

   curl -X GET \
        -H "Authorization: Bearer $(gcloud auth print-access-token)" \
        "https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME"

   PowerShell (Windows)

   Execute o seguinte comando:

   $cred = gcloud auth print-access-token
   $headers = @{ "Authorization" = "Bearer $cred" }
   
   Invoke-WebRequest `
       -Method GET `
       -Headers $headers `
       -Uri "https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME" | Select-Object -Expand Content

   Deve receber uma resposta JSON semelhante à seguinte:

   {
     "kind": "compute#forwardingRule",
     "id": "ENDPOINT_ID",
     "creationTimestamp": "2024-05-09T12:03:21.383-07:00",
     "name": "ENDPOINT_NAME",
     "region": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME",
     "IPAddress": "IP_ADDRESS",
     "target": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/serviceAttachments/SERVICE_ATTACHMENT_NAME",
     "selfLink": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME",
     "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/default",
     "serviceDirectoryRegistrations": [
       {
         "namespace": "goog-psc-default"
       }
     ],
     "networkTier": "PREMIUM",
     "labelFingerprint": "LABEL_FINGERPRINT_ID",
     "fingerprint": "FINGERPRINT_ID",
     "pscConnectionId": "CONNECTION_ID",
     "pscConnectionStatus": "ACCEPTED",
     "allowPscGlobalAccess": true
   }
   

2. Verifique se o estado do ponto final é ACCEPTED. Se o estado for PENDING, a instância não está a permitir o projeto Trusted Cloud que contém o ponto final. Certifique-se de que o projeto de rede no qual o ponto final é criado é permitido. Para mais informações, consulte o artigo Edite uma instância com o Private Service Connect ativado.

A rede de consumo não está configurada corretamente ou não está configurada de todo e, por isso, não está disponível nenhum ponto final para estabelecer ligação. Para se ligar ao ponto final, tem de verificar o estado do ponto final e corrigir o erro antes de tentar estabelecer ligação novamente.
Para verificar o estado de um ponto final, consulte Obtenha o ponto final. O estado do ponto final pode ser um dos seguintes:

• CONNECTION_POLICY_MISSING: não existe uma política de ligação de serviço correspondente na rede do consumidor. As políticas de ligação de serviços são configuradas por rede e por região. Para reconfigurar a rede, consulte o artigo Atualize uma política de ligação de serviço.
• CONSUMER_INSTANCE_PROJECT_NOT_ALLOWLISTED: existe uma política de ligação de serviço correspondente, mas a instância de serviço não está configurada para permitir a ligação a esta instância. Para reconfigurar a política de ligação de serviços, consulte o artigo Atualize uma política de ligação de serviços.
• POLICY_LIMIT_REACHED: a política de ligação de serviço atingiu o respetivo limite de pontos finais. Para resolver o problema, tem de aumentar o limite de pontos finais atualizando a política de ligação ao serviço.

Não tem as autorizações necessárias para criar uma política de ligação de serviço. Para criar uma política de ligação de serviço, precisa da função Compute Network Admin IAM. Para mais informações, consulte o artigo Funções e autorizações.

Se a sua rede externa não conseguir aceitar ligações da interface do Private Service Connect, as políticas de ligação na associação da rede podem não estar configuradas corretamente.

Os anexos de rede têm de ser configurados para aceitar todas as ligações automaticamente ou configurados manualmente com uma lista de ligações aceites. Para mais informações, consulte as políticas de ligação.

Use o seguinte comando para validar as associações aceites no anexo de rede:

      gcloud compute network-attachments describe default
      --region=REGION_ID

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.

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.

Reinicie a instância da réplica para recuperar o espaço de memória temporário.

Edite a instância para ativar a autorização automatic storage increase.

• 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:

• Configurar a replicação paralela.
• Defina o sinalizador innodb_flush_log_at_trx_commit na réplica de leitura como 2.

  Consulte as Sugestões para trabalhar com flags para mais informações sobre esta flag.

• Edite a instância para aumentar o tamanho da réplica.
• Reduza a carga na base de dados.
• Envie tráfego de leitura para a réplica de leitura.
• Indexe as tabelas.
• Identifique e corrija consultas de escrita lentas.
• Recrie a 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

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

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