Realtime Compute for Apache Flink:Flink CDC FAQ

Posso configurar a implantação para cancelar em vez de reiniciar em caso de falha?

Defina uma estratégia de reinicialização na configuração da implantação. O exemplo a seguir limita as reinicializações a duas tentativas com intervalo de 10 segundos e cancela a implantação se ambas falharem.

restart-strategy: fixed-delay
restart-strategy.fixed-delay.attempts: 2
restart-strategy.fixed-delay.delay: 10 s

Tabelas source do MySQL CDC e do Hologres CDC não suportam window functions. Como implementar agregação por minuto?

Use DATE_FORMAT para converter timestamps em strings no nível de minuto e aplique GROUP BY nessas strings. O exemplo a seguir calcula a contagem de pedidos e a receita por loja a cada minuto:

SELECT
    shop_id,
    DATE_FORMAT(order_ts, 'yyyy-MM-dd HH:mm') AS window,
    COUNT(*) AS order_count,
    SUM(price) AS amount
FROM order_mysql_cdc
GROUP BY shop_id, window

Uma tabela MySQL CDC pode ser usada como tabela de dimensão ou tabela sink?

Não. Uma tabela MySQL CDC serve apenas como tabela source, pois lê dados completos e incrementais do MySQL. Para casos de uso de dimensão ou sink, utilize uma tabela MySQL comum (não CDC).

Por que o conector MySQL CDC para após ler os dados completos e nunca muda para o modo incremental?

Isso geralmente ocorre por um destes quatro motivos:

• Instâncias secundárias ou somente leitura do ApsaraDB RDS for MySQL V5.6: Essas instâncias não gravam dados em arquivos de binary log, então o conector não tem dados incrementais para ler. Use uma instância com capacidade de escrita ou atualize para uma versão posterior à V5.6.

• Compressão de transação de binary log ativada: Tabelas source do MySQL CDC não suportam compressão de transação de binary log. Desative esse recurso em clusters MySQL autogerenciados.

• Out-of-memory (OOM) durante a leitura de dados completos: Se o último shard for muito grande, um erro de OOM suspende a implantação após o failover. Aumente o paralelismo para acelerar a leitura dos dados completos.

• Intervalo de checkpoint muito longo: Depois que todas as subtarefas paralelas terminam a leitura dos dados completos, o conector aguarda um checkpoint antes de mudar para o modo incremental. Um intervalo de checkpoint de 20 minutos resulta em um atraso de 20 minutos. Defina um intervalo menor conforme suas necessidades.

Como confirmo que a sincronização de dados completos foi concluída?

Existem dois métodos:

• Métrica currentEmitEventTimeLag: Na aba Metrics da página Deployments, verifique essa métrica. Um valor ≤ 0 indica que a sincronização completa ainda está em andamento; um valor > 0 significa que o conector finalizou a sincronização completa e começou a ler dados do binary log.

  

• Log do TaskManager: Pesquise por BinlogSplitReader is created nos logs do TaskManager. Essa mensagem confirma que a leitura dos dados completos foi concluída.

  

A posição inicial muda quando reinicio uma implantação?

Depende da Starting Strategy selecionada na caixa de diálogo Deployment Starting Configuration:

• NONE: O conector relê a partir da posição inicial configurada.

• Latest State: O conector retoma da posição do binary log onde a implantação foi cancelada pela última vez.

Por exemplo, se a implantação foi configurada para iniciar em {file=mysql-bin.01, position=40} mas foi cancelada na posição 210, Latest State retoma em 210 e NONE reinicia a partir de 40.

Como funciona o conector MySQL CDC e qual seu impacto no banco de dados?

Quando scan.startup.mode está definido como initial (o padrão), o conector:

1. Conecta-se via JDBC e executa uma instrução SELECT para ler os dados completos, registrando a posição atual do binary log.

2. Após a leitura dos dados completos, alterna para o cliente de binlog para ler alterações incrementais a partir da posição registrada.

A leitura de dados completos aumenta a carga de consultas devido à instrução SELECT. Durante a leitura incremental, cada tabela source mantém uma conexão de binlog. Se você tiver muitas tabelas source, verifique o limite de conexões:

show variables like '%max_connections%';

Como ignorar a fase de snapshot e ler apenas dados de alteração?

Defina scan.startup.mode na cláusula WITH como um dos seguintes valores: earliest-offset, latest-offset, specific-offset ou timestamp. Para mais detalhes, consulte a seção "Parameters in the WITH clause" em Create a MySQL CDC source table.

Como o MySQL CDC localiza a posição do binlog quando scan.startup.mode = timestamp?

Com o modo de inicialização timestamp, o MySQL CDC determina a posição inicial de consumo da seguinte forma:

1. Varre todos os arquivos de binlog e encontra o primeiro arquivo cuja hora da última modificação seja maior ou igual ao timestamp especificado.

2. Lê eventos de binlog desde o início desse arquivo.

3. Ignora eventos cujo timestamp seja anterior ao timestamp especificado.

4. Começa a consumir a partir do primeiro evento cujo timestamp seja maior ou igual ao timestamp especificado.

Casos limites:

• Se o timestamp especificado estiver no futuro, o consumo começa a partir da posição disponível mais recente, equivalente a latest-offset.

• Se o binlog correspondente ao timestamp especificado já tiver sido purgado, o consumo começa a partir da posição disponível mais antiga, equivalente a earliest-offset.

Como o conector lida com tabelas MySQL fragmentadas (sharded)?

Use o parâmetro table-name com uma expressão regular para corresponder a todos os shards. Por exemplo, para monitorar todas as tabelas com o prefixo user_:

'table-name' = 'user_.*'

Se todas as tabelas entre os shards tiverem o mesmo schema, use database-name com uma regex em vez disso.

O que fazer se vírgulas na regex de table-name causarem erros de parsing?

O Debezium usa vírgulas como delimitadores, então um padrão como t_process_wi_history_\d{1,2} falha.

Use alternância em vez disso:

'table-name' = '(t_process_wi_history_\d{1}|t_process_wi_history_\d{2})'

Múltiplas implantações MySQL CDC estão causando alta carga no banco de dados. O que posso fazer?

Existem duas abordagens:

• Descarregar para o Kafka: Sincronize a tabela source do MySQL CDC com uma tabela sink do ApsaraMQ for Kafka. Outras implantações passam a consumir do Kafka em vez de ler binary logs diretamente. Consulte Synchronize data from all tables in a MySQL database to Kafka.

• Mesclar implantações com server ID compartilhado: Se várias implantações CREATE TABLE AS compartilharem a mesma configuração, atribua o mesmo server ID para reutilizar a fonte de dados. Consulte Example 4: execution of multiple CREATE TABLE AS statements.

Uma pequena atualização causa uso de largura de banda anormalmente alto. Por quê?

Os arquivos de binary log contêm alterações de todos os bancos de dados e tabelas na instância MySQL, não apenas daqueles que sua implantação monitora. Se sua instância tiver três tabelas, o binary log carrega alterações das três, mesmo que sua implantação rastreie apenas uma.

Corrija isso reutilizando a tabela source do MySQL CDC para que múltiplas implantações compartilhem uma única conexão de binlog. Consulte a seção "Enabling of the reuse of a MySQL CDC source table" em MySQL connector.

Campos de timestamp mostram um deslocamento de 8 horas em relação ao fuso horário do servidor MySQL. Por quê?

Duas causas possíveis:

• O parâmetro server-time-zone na implantação CDC não corresponde ao fuso horário real do servidor MySQL. Atualize server-time-zone para corresponder.

• Um desserializador personalizado (MyDeserializer implements DebeziumDeserializationSchema) não define serverTimeZone. Defina serverTimeZone com base em como RowDataDebeziumDeserializeSchema analisa dados TIMESTAMP:

  private TimestampData convertToTimestamp(Object dbzObj, Schema schema) {
      if (dbzObj instanceof Long) {
          switch (schema.name()) {
              case Timestamp.SCHEMA_NAME:
                 return TimestampData.fromEpochMillis((Long) dbzObj);
              case MicroTimestamp.SCHEMA_NAME:
                 long micro = (long) dbzObj;
                 return TimestampData.fromEpochMillis(micro / 1000, (int) (micro % 1000 * 1000));
              case NanoTimestamp.SCHEMA_NAME:
                 long nano = (long) dbzObj;
                 return TimestampData.fromEpochMillis(nano / 1000_000, (int) (nano % 1000_000));
          }
      }
      LocalDateTime localDateTime = TemporalConversions.toLocalDateTime(dbzObj, serverTimeZone);
      return TimestampData.fromLocalDateTime(localDateTime);
  }

O conector MySQL CDC pode escutar bancos de dados secundários?

Sim. Adicione o seguinte à configuração do banco de dados secundário para que os dados sincronizados do primário sejam gravados no binary log do secundário:

log-slave-updates = 1

Se o modo Global Transaction Identifier (GTID) estiver habilitado no primário, habilite-o também no secundário:

gtid_mode = on
enforce_gtid_consistency = on

Como capturo eventos DDL?

Use a DataStream API com MySqlSource e defina includeSchemaChanges(true):

MySqlSource<xxx> mySqlSource =
    MySqlSource.<xxx>builder()
        .hostname(...)
        .port(...)
        .databaseList("<databaseName>")
        .tableList("<databaseName>.<tableName>")
        .username(...)
        .password(...)
        .serverId(...)
        .deserializer(...)
        .includeSchemaChanges(true) // Capture DDL events
        .build();
// Add downstream processing logic

O MySQL CDC suporta a sincronização de todas as tabelas de um banco de dados de uma só vez?

Sim. Use a instrução CREATE TABLE AS ou CREATE DATABASE AS. Consulte CREATE TABLE AS statement ou CREATE DATABASE AS statement.

Instâncias do ApsaraDB RDS for MySQL V5.6 não gravam alterações incrementais em arquivos de binary log, portanto o conector não consegue ler dados incrementais dessas instâncias.

Dados incrementais de uma tabela específica não estão sendo sincronizados. Por quê?

Um filtro de binary log no servidor MySQL pode estar excluindo esse banco de dados. Execute o comando a seguir para verificar:

show master status;

Verifique as colunas Binlog_Ignore_DB e Binlog_Do_DB na saída:

+------------------+----------+--------------+------------------+----------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |  Executed_Gtid_Set   |
+------------------+----------+--------------+------------------+----------------------+
| mysql-bin.000006 |     4594 |              |                  | xxx:1-15             |
+------------------+----------+--------------+------------------+----------------------+

Como configuro tableList ao usar a DataStream API para MySQL CDC?

O valor de tableList deve incluir tanto o nome do banco de dados quanto o nome da tabela, no formato yourDatabaseName.yourTableName.

O conector pode retomar de um checkpoint se a implantação falhar durante a leitura de dados completos?

Sim. Defina 'scan.incremental.snapshot.enabled' = 'true' na cláusula WITH para ativar a recuperação baseada em checkpoint durante a leitura de dados completos.

O MongoDB CDC suporta a leitura apenas de dados incrementais?

Por padrão, o conector lê dados completos e incrementais. Para pular os dados completos e ler apenas alterações incrementais, defina 'scan.startup.mode' = 'latest-offset' na cláusula WITH.

Posso assinar apenas coleções específicas?

Não. O conector faz a assinatura no nível do banco de dados. Defina 'database' = 'mgdb' e 'collection' = '' na cláusula WITH para assinar todas as coleções do banco de dados.

O MongoDB CDC suporta leitura concorrente?

Sim, durante a fase inicial de snapshot. Defina scan.incremental.snapshot.enabled como true para ativar a leitura concorrente.

Quais versões do MongoDB são suportadas?

MongoDB 3,6 e posteriores (change streams foram introduzidos na versão 3,6). Recomenda-se o MongoDB 4,0 ou superior. Em versões anteriores à 3,6, o conector retorna o erro "Unrecognized pipeline stage name: '$changeStream'".

Quais arquiteturas do MongoDB são suportadas?

O conector exige um replica set ou sharded cluster, pois change streams funcionam apenas nesses modos. Para testes locais, converta o MongoDB para um replica set de nó único usando rs.initiate(). Sem isso, o conector retorna "The $changestage is only supported on replica sets".

O MongoDB CDC suporta parâmetros do Debezium?

Não. O conector MongoDB CDC é desenvolvido independentemente no Flink CDC e não depende do Debezium.

A autenticação falha mesmo com credenciais corretas. Por quê?

As credenciais do usuário têm escopo restrito a um banco de dados específico. Adicione 'connection.options' = 'authSource=<database_the_user_belongs_to>' à cláusula WITH.

O conector pode retomar de um checkpoint após a reinicialização da implantação?

Sim. Checkpoints armazenam tokens de retomada para change streams. Quando a implantação reinicia, o conector lê o token de retomada e continua a partir da posição correspondente na coleção oplog.rs.

Se o token de retomada não existir mais em oplog.rs — uma coleção de capacidade fixa que rotaciona quando cheia — aumente o tamanho do oplog para evitar rotação prematura. Consulte Change the Oplog Size of Self-Managed Replica Set Members.

O MongoDB CDC suporta mensagens UPDATE_BEFORE (imagens pré-atualização)?

Depende da versão do MongoDB:

• MongoDB 6,0 e posteriores com pre-image/post-image habilitado: Defina 'scan.full-changelog' = 'true'. O MongoDBSource gera mensagens UPDATE_BEFORE diretamente.

• MongoDB anterior à versão 6,0: A coleção oplog.rs inclui os tipos INSERT, UPDATE, REPLACE e DELETE, mas não UPDATE_BEFORE. Ao usar MongoDBTableSource com modo SQL, o planner do Flink aplica automaticamente o operador ChangelogNormalize para gerar mensagens UPDATE_BEFORE, mas esse operador armazena todos os estados de chave e adiciona sobrecarga. Se você usar a DataStream API com MongoDBSource (sem a otimização do planner do Flink), o ChangelogNormalize não é aplicado automaticamente. Gerencie o estado manualmente ou use MongoDBTableSource e converta para um changelog stream:

  tEnv.executeSql("CREATE TABLE orders ( ... ) WITH ( 'connector'='mongodb-cdc', ... )");
  
  Table table = tEnv.from("orders").select($("*"));
  
  tEnv.toChangelogStream(table)
      .print()
      .setParallelism(1);
  
  env.execute();

Como filtro valores de data inválidos?

Adicione um dos seguintes parâmetros à cláusula WITH:

• 'debezium.event.deserialization.failure.handling.mode' = 'warn': Ignora registros inválidos e os registra como avisos.

• 'debezium.event.deserialization.failure.handling.mode' = 'ignore': Ignora registros inválidos silenciosamente.

Dados TOAST estão ausentes nas atualizações. Por quê?

O comportamento depende da configuração REPLICA IDENTITY da tabela:

• REPLICA IDENTITY FULL: Os valores das colunas TOAST aparecem nos campos before e after dos eventos de alteração, assim como qualquer outra coluna.

• REPLICA IDENTITY DEFAULT (o padrão): Colunas TOAST inalteradas são omitidas dos eventos UPDATE. Quando 'debezium.schema.refresh.mode' = 'columns_diff_exclude_unchanged_toast' é usado, o plugin wal2json omite dados TOAST inalterados, de modo que essas colunas só aparecem nos logs WAL quando a replica identity é FULL.

Para corrigir a ausência de dados TOAST, defina a replica identity como FULL:

ALTER TABLE your_table_name REPLICA IDENTITY FULL;

Logs WAL não estão sendo liberados e o uso de disco está alto. Por quê?

O conector PostgreSQL CDC atualiza o log sequence number (LSN) nos slots de replicação apenas quando um checkpoint do Flink é concluído. Se o uso de disco estiver alto, verifique:

• Se o checkpointing está habilitado para a implantação.

• Se algum slot de replicação está sem uso ou apresenta um grande atraso de sincronização.

O que acontece quando a precisão DECIMAL excede a precisão declarada da coluna?

O valor é retornado como null. Para preservar o valor original, defina 'debezium.decimal.handling.mode' = 'string' para ler dados DECIMAL como strings.

Como configuro tableList ao usar a DataStream API para PostgreSQL CDC?

O valor de tableList deve incluir tanto o nome do schema quanto o nome da tabela, no formato my_schema.my_table.

Por que não consigo baixar flink-sql-connector-mysql-cdc-2.2-SNAPSHOT.jar?

Versões SNAPSHOT correspondem a branches de desenvolvimento e não são publicadas no repositório central do Maven. Compile a partir do source para usar uma versão SNAPSHOT ou utilize uma versão estável, como flink-sql-connector-mysql-cdc-2.1.0.jar, disponível no repositório central do Maven.

Qual a diferença entre flink-sql-connector-xxx.jar e flink-connector-xxx.jar?

• flink-sql-connector-xxx: Um fat JAR que inclui o código do conector e todas as dependências com shade. Adicione-o ao diretório lib para implantações SQL.

• flink-connector-xxx: Contém apenas o código do conector, sem dependências. Use-o para implantações DataStream e gerencie as dependências de terceiros manualmente, incluindo a resolução de conflitos com operações exclude e shade.

Por que não encontro um pacote de conector Flink CDC 2.x no repositório Maven?

A partir do Flink CDC 2.0.0, o group ID mudou de com.alibaba.ververica para com.ververica. O caminho Maven para pacotes 2.x é /com/ververica/.

Campos numéricos são retornados como strings ao usar JsonDebeziumDeserializationSchema. Como corrijo isso?

Configure as propriedades de tratamento numérico do Debezium ao construir a source:

Properties properties = new Properties();
properties.setProperty("bigint.unsigned.handling.mode", "long");
properties.setProperty("decimal.handling.mode", "double");

MySqlSource.<String>builder()
    .hostname(config.getHostname())
    // ...
    .debeziumProperties(properties);

Para detalhes sobre como o Debezium converte tipos numéricos, consulte Debezium connector for MySQL.

"Replication slot 'xxxx' is active"

Após o término de uma implantação PostgreSQL CDC, seu slot de replicação pode não ser liberado automaticamente. Libere-o manualmente:

select pg_drop_replication_slot('rep_slot');

Se o slot estiver mantido por um processo ativo, encerre o processo primeiro:

select pg_terminate_backend(162564);
select pg_drop_replication_slot('rep_slot');

Alternativamente, adicione 'debezium.slot.drop.on.stop' = 'true' à configuração da source do PostgreSQL para remover o slot automaticamente quando a implantação for cancelada.

"binlog probably contains events generated with statement or mixed based replication format"

Tabelas source do MySQL CDC suportam apenas binary logs no formato ROW. Se o formato for STATEMENT ou MIXED, o conector falhará.

1. Verifique o formato atual:

   show variables like "binlog_format";
   -- To check the global setting:
   show global variables like "binlog_format";

2. Altere o formato para ROW. Consulte Setting the binary log format.

3. Reinicie a implantação.

"Encountered change event for table xxx.xxx whose schema isn't known to this connector"

Três causas comuns:

• Permissões ausentes: A conta não tem acesso a todos os bancos de dados usados na implantação. Conceda as permissões necessárias. Consulte Configure a MySQL database.

• debezium.snapshot.mode definido como never: Ler desde o início dos binary logs significa que o schema da tabela registrado lá pode não corresponder ao schema atual. Evite essa configuração. Para tolerar incompatibilidades de schema, adicione 'debezium.inconsistent.schema.handling.mode' = 'warn'.

• Sintaxe DDL não suportada: O Debezium não consegue interpretar certas expressões, como DEFAULT (now()). Verifique o log WARN de io.debezium.connector.mysql.MySqlSchema para identificar a instrução problemática.

"The connector is trying to read binlog starting at GTIDs ..., but this is no longer available on the server"

O arquivo de binary log necessário para o conector foi excluído. Causas comuns e correções:

<table> <thead> <tr> <th><b>Causa</b></th> <th><b>Correção</b></th> </tr> </thead> <tbody> <tr> <td>Período de retenção de binary log muito curto</td> <td>Aumente o período de retenção, por exemplo, para 7 dias: <code>set global expire_logs_days=7;</code></td> </tr> <tr> <td>Implantação consumindo binlogs muito lentamente (backpressure em um operador downstream)</td> <td>Otimize a configuração de recursos para reduzir o backpressure</td> </tr> <tr> <td>ApsaraDB RDS for MySQL: logs retidos por no máximo 18 horas e até 30% do armazenamento</td> <td>Ajuste a política de expiração de binary log para o RDS</td> </tr> <tr> <td>Instância somente leitura do ApsaraDB RDS for MySQL: binlog local retido por no mínimo 10 segundos antes do upload para o Object Storage Service (OSS)</td> <td>Evite usar instâncias somente leitura (hostname começa com <code>rr</code>) para CDC; use instâncias regulares (hostname começa com <code>rm</code>)</td> </tr> <tr> <td>Migração interna de dados na instância RDS</td> <td>Reinicie a implantação para reler os dados</td> </tr> </tbody> </table>

"EventDataDeserializationException: Failed to deserialize data of EventHeaderV4"

O servidor MySQL fechou uma conexão de binlog ociosa. O parâmetro net_write_timeout controla esse tempo limite (padrão: 60 segundos). Conexões inativas devido a backpressure ou problemas de rede são desconectadas.

• Adicione 'debezium.connect.keep.alive.interval.ms' = '40000' à configuração da tabela source do MySQL CDC ou aumente net_write_timeout no banco de dados. Consulte Optimize instance parameters.

• Se o erro for causado por backpressure, ajuste a configuração de recursos da implantação.

• O Ververica Runtime (VVR) 8.0.7 e posteriores tentam novas conexões automaticamente em erros causados por backpressure.

"The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs"

A leitura de dados completos demorou tanto que a posição GTID registrada no início da sincronização completa foi excluída do servidor antes que o conector mudasse para a leitura incremental.

Aumente o período de retenção do binary log ou o tamanho máximo do arquivo:

mysql> show variables like 'expire_logs_days';
mysql> set global expire_logs_days=7;

"The 'before' field of UPDATE/DELETE message is null"

A REPLICA IDENTITY da tabela PostgreSQL não está definida como FULL. Execute:

ALTER TABLE yourTableName REPLICA IDENTITY FULL;

Se o erro persistir após reiniciar a implantação, adicione a instrução ao código da implantação.

"Can't find any matched tables, please check your configured database-name and table-name"

Duas causas possíveis:

• O nome da tabela não existe no banco de dados. Verifique o nome da tabela configurado.

• A conta não tem permissões em bancos de dados específicos da implantação. Conceda as permissões necessárias em todos os bancos de dados.

"The primary key is necessary when enable 'scan.incremental.snapshot.enabled'"

Esse erro ocorre no VVR 4.0.x quando uma tabela source do MySQL CDC é criada sem uma chave primária na cláusula DDL WITH. Adicione a definição da chave primária à instrução DDL.

"java.io.EOFException: SSL peer shut down incorrectly" {#javaioeofe-xception-ssl-peer-shut-down-incorrectly}

O MySQL 8.0.27 habilita conexões SSL por padrão, mas o driver JDBC não consegue conectar via SSL com a configuração padrão.

• Se estiver usando VVR 6.0.2 ou posterior, adicione 'jdbc.properties.useSSL' = 'false' à cláusula WITH.

• Se a tabela for usada apenas como tabela de dimensão, defina o conector como rds e adicione characterEncoding=utf-8&useSSL=false à URL:

  'url' = 'jdbc:mysql://***.***.***.***:3306/test?characterEncoding=utf-8&useSSL=false'

"A slave with the same server_uuid/server_id as this slave has connected to the master"

Cada subtarefa paralela de uma tabela source do MySQL CDC deve ter um server ID exclusivo. Se subtarefas paralelas na mesma implantação — ou em múltiplas implantações — compartilharem o mesmo server ID, esse erro ocorrerá.

Especifique um server ID globalmente exclusivo para cada subtarefa paralela. Para mais detalhes, consulte a seção "Precautions" em Create a MySQL CDC source table.

"NullPointerException" após adicionar uma coluna durante a leitura de dados completos

A implantação registra o schema da tabela na inicialização e o armazena nos checkpoints. Adicionar uma coluna enquanto a leitura de dados completos está em andamento causa uma incompatibilidade de schema, o que aciona uma NullPointerException.

Cancele a implantação, exclua a tabela downstream e reinicie a implantação sem estados.

"Mysql8.0 Public Key Retrieval is not allowed"

O usuário do MySQL está configurado com autenticação de senha SHA256, que exige TLS. Alterne o usuário para autenticação de senha nativa:

ALTER USER 'username'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password';
FLUSH PRIVILEGES;

"sub account not auth permission"

Ao usar o ApsaraDB RDS for MySQL como source CDC, o usuário RAM não tem permissão para baixar arquivos de binary log do Object Storage Service (OSS). Conceda as permissões necessárias. Consulte Authorize a RAM user with read-only permissions to download backup files.

"DELETE command denied to user 'userName'@'\.\.\.\' for table 'table_name'"

Quando uma cláusula WHERE filtra fluxos de dados CDC, o Realtime Compute for Apache Flink emite tanto um registro BEFORE UPDATE quanto um AFTER UPDATE para cada operação UPDATE. O sink downstream trata o registro BEFORE UPDATE como um DELETE. Conceda a permissão DELETE ao usuário do banco de dados que realiza operações na tabela de resultados.