Flink da entrada ao abandono (nove) - dez mil palavras para explicar o design do CDC (1)

1. Preparação

Antes de começar a estudar o princípio do Flink CDC (este artigo primeiro apresenta a versão CDC1.0 e estenderá a introdução das funções do 2.0 posteriormente), as seguintes tarefas precisam ser realizadas (este artigo começa com o ambiente Flink1.12 )

Abra o site oficial do Flink (veja a introdução do módulo Connector)
Abra o Github e baixe o código-fonte (o link não pode ser colocado no momento, os leitores podem pesquisar no github sozinhos)

apache-flink

conectores flink-cdc

dívida

começar a afundar

2. Proposta de Projeto

2.1. Motivação do projeto

CDC (Change data Capture, capture change data) é um modelo relativamente popular em empresas, usado principalmente em sincronização de dados, índice de pesquisa, atualização de cache e outros cenários; a comunidade inicial precisa oferecer suporte à capacidade de extrair e interpretar diretamente os logs de alteração na Tabela API e funções SQL para ampliar os cenários de uso do Flink .

Por outro lado, o conceito de "tabela dinâmica" foi proposto anteriormente e dois modos em fluxos foram definidos: append mode e update mode . O Flink já suporta o modo append que converte o stream em uma tabela dinâmica, mas ainda não suporta o modo update, então a interpretação do changelog é preencher a peça que faltava no quebra-cabeça para obter um conceito completo de tabela dinâmica. Claro, não apenas a atualização é suportada agora, mas também o modo de retração é suportado, o que será explicado separadamente mais tarde.

2.2, seleção de ferramenta CDC

Os esquemas comuns de CDC são comparados da seguinte forma:

foto

1. Função perfeita

Para ferramentas CDC, existem atualmente muitas opções, como Debezium, Canal e outras soluções populares; atualmente Debezium suporta Mysql, PG, SQL Server, Oracle, Cassandra e Mongo, se Flink suporta Debezium, significa que Flink pode se conectar ao seguinte O changelog de todos os bancos de dados na captura de tela é benéfico para melhorar todo o ecossistema. Entre eles, o Debezium suporta sincronização completa + incremental , que é muito flexível e torna possível Exactly-Once.

Os tipos de banco de dados suportados pelo Debezium são os seguintes:

foto

2. Abrace a comunidade e facilite a expansão

Se você escolher o Debezium como o mecanismo incorporado do Flink, poderá incorporá-lo à base de código como um pacote de dependência em vez de executar através do conector kafka. Você também não precisa se comunicar diretamente com o servidor MySQL e não precisa precisa lidar com instantâneos complexos, GTIDs, bloqueios, etc. enquanto abraça e colabora com a comunidade Debezium

Em terceiro lugar, a estrutura interna de dados é semelhante

Para a estrutura de dados do tipo RowData dentro do Flink SQL, existe um RowKind de metadados, que possui 4 tipos, a saber, inserir (Inserir), atualizar (UPDATE_BEFORE antes da atualização, UPDATE_AFTER após a atualização) e excluir (DELETE). Esses quatro tipos de dados podem ser encontrado É basicamente consistente com a estrutura do Binlog.

foto

Aqui está uma explicação do significado de cada campo de metadados na estrutura de dados do Debezium:

· campo antes: É um campo opcional, que representa o estado antes da ocorrência do evento, se for uma operação de criação, o valor deste campo é nulo.

· after field: É um campo opcional, que representa o estado da linha após a ocorrência do evento, se for uma operação de exclusão, então o valor deste campo é nulo.

· source: é um campo obrigatório, incluindo metainformações do evento, como offset, arquivo binlog, banco de dados e tabela.

ts_ms: representa o timestamp dos eventos de processamento do Debezium

· Campo OP: Este campo também possui 4 valores, ou seja, C (criar), U (Atualizar), D (Excluir) e Ler®. Para a operação U, sua parte de dados contém Before e After.

foto

3. Conceitos

Haverá muitos conceitos envolvidos aqui, todo mundo tem uma cognição primeiro, e depois eles serão divididos e explicados separadamente.

3.1、Stream

O conceito de fluxo é realmente fácil de entender **O fluxo tem duas características: limitação e modo de mudança. **Em seguida, apresente esses dois recursos separadamente:

Modificar modo:

foto

Conforme mostrado na figura acima: Existem dois modos de tabela dinâmica, modo de anexação e modo de substituição (inserção e retração) . Em seguida, apresente brevemente a diferença entre os dois

Para o modo de acréscimo, é fácil de entender. Se nenhuma chave primária for especificada na definição da tabela, depois que um registro for adicionado à tabela, ele nunca será atualizado ou excluído anexando o registro de fluxo à tabela como uma nova linha.

Para o modo Substituir, se a chave primária estiver definida na tabela, então se não houver nenhum registro com o mesmo atributo chave, ela será inserida na tabela, caso contrário será substituída. Então, para o modo de substituição, ele é subdividido em modos upsert e retract:

Para o modo Upsert, inclui duas mensagens, Upsert (inserir e atualizar) e DELETE.A principal diferença entre este modo e o modo retrair é que as alterações de UPDATE serão codificadas com uma única mensagem, o que é mais eficiente. _

Para o modo Retract, um fluxo de atualização contém mensagens ADD e RETRACT. Para uma alteração Insert, ela será codificada em uma mensagem ADD. Para uma alteração DELETE, ela será codificada em uma mensagem RETRACT. Para uma alteração UPDATE, será codificado em Updated-Before como a mensagem de retração e a mensagem ADD. Este modo precisa ser desmontado em duas mensagens para o evento de atualização e a eficiência será relativamente baixa. Aqui está uma breve introdução ao que é um fluxo de retração, conforme mostrado na figura abaixo:

Operação	Do utilizador	Contagem(url)	Marca
eu (inserir)	Mary	1
eu (inserir)	Prumo	1
-U(Atualizar-Antes)	Mary	0	vai deletar o registro
+U(Atualizar-Depois)	Mary	2
eu (inserir)	liz	1
-U(Atualizar-Antes)	Prumo	0	vai deletar o registro
+U(Atualizar-Depois)	Prumo	2

foto

Fronteira

Bounded Stream: Consiste em eventos de tamanho limitado, a consulta do trabalho processa os dados atualmente disponíveis e terminará depois disso.

Fluxo Ilimitado: Consiste em eventos infinitos, se a entrada for um fluxo ilimitado, a consulta é processada continuamente à medida que todos os dados chegam.

3. Resumo:

Delimitação \ Alterar modo

Acrescentar

Atualizar

ilimitado

Anexar fluxo ilimitado

por exemplo, logs do Kafka

Atualizar fluxo ilimitado

por exemplo, capturar continuamente as alterações da tabela MySQL

limitado

Anexar Fluxo Delimitado

por exemplo, um arquivo parquet em HDFS,

uma tabela MySQL

Atualizar fluxo limitado

por exemplo, capturar alterações da tabela MySQL até um ponto de tempo

3.2, tabela dinâmica Tabela Dinâmica

Tabelas dinâmicas são tabelas que mudam com o tempo e podem ser consultadas como tabelas regulares tradicionais. Uma tabela dinâmica pode ser convertida em um fluxo e um fluxo pode ser convertido em uma tabela dinâmica (precisa ter o mesmo esquema e o método de conversão depende se o esquema da tabela contém a definição da chave primária). Nota: Todas as tabelas criadas no Flink SQL são tabelas dinâmicas. Uma consulta em uma tabela dinâmica gera uma nova tabela dinâmica (atualizada de acordo com a entrada) e se a consulta termina depende da limitação da entrada.

DynamicTable é um objeto conceitual e stream é uma representação física.

3.3、Changelog

O Changelog é um fluxo anexado que consiste em linhas contendo colunas de operação de alteração (para sinalizadores de inserção/exclusão ou mais no futuro) e colunas de metadados reais. O objetivo do design do Flink CDC é extrair os eventos do log de alterações e convertê-los em operações de alteração (como inserir, atualizar, excluir eventos).

Converter de um stream de acréscimo para um stream de atualização ( ou seja, Interpretar Changelog ).

Converta de um stream de atualização para um stream de acréscimo ( Emit Changelog ).

No Flink SQL, os dados fluem de um operador para outro na forma de Changelog Stream. Changelog Stream a qualquer momento pode ser traduzido em uma tabela ou um fluxo, conforme mostrado na figura a seguir:

foto

A figura a seguir mostrará completamente a conversão entre o tipo Stream e Table:

foto

Diferentes ferramentas de CDC podem ter diferentes métodos de codificação para o Changelog, o que também é um grande desafio para o flink. Aqui estão duas soluções populares: Debezium e Canal como exemplos:

Tome o Debezium como exemplo. O Debezium é uma ferramenta CDC construída sobre o Kafka Connector. Ele pode transmitir fluxos de mudança em tempo real para o Kafka. O Debezium gera um formato unificado para o log de alterações do Kafka. Tome a operação de atualização como exemplo:

{
  "before": {
    "id": 1004,
    "first_name": "Anne",
    "last_name": "Kretchmar",
    "email": "[email protected]"
  }, //before作为可选字段，如果是create操作，则该字段为null
  "after": {
    "id": 1004,
    "first_name": "Anne Marie",
    "last_name": "Kretchmar",
    "email": "[email protected]"
  }, //after作为可选字段，如果是delete操作，则该字段为null
  "source": { ... },//强制字段，标识事件元信息，如offset,binlog file，database,table 等等。
  "op": "u",   //强制字段，用来描述操作类型，如C(create),U(update),D(delete)
  "ts_ms": 1465581029523
}

Por padrão, o Debezium gera dois eventos para operações de exclusão: evento DELETE e evento Tombstone (tombstone) (com valor/carga útil nulo), o evento tombstone é usado para o mecanismo de compactação Kafka. Deve-se notar que: Debezium não é um sistema de armazenamento, mas representa um formato de armazenamento, que é baseado no formato JSON e pode converter linhas de resultado desserializadas em ChangeRow ou Tuple2<Boolean, Row>.

O Canal é uma ferramenta CDC popular na China. Ele é usado para capturar alterações do Mysql para outros sistemas. Ele suporta alterações de fluxo Kafka e RocketMQ nos formatos JSON e protobuf. Aqui está um exemplo da operação de atualização:

{
  "data": [  
    {//表示真实的数据，如果是更新操作，则是更新后的状态，如果是删除操作，则是删除之前的状态。
      "id": "13",
      "username": "13",
      "password": "6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9",
      "name": "Canal Manager V2"
    }
  ],
  "old": [ //可选字段，如果不是update操作，那么该字段为null
    {
      "id": "13",
      "username": "13",
      "password": "6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9",
      "name": "Canal Manager"
    }
  ],
  "database": "canal_manager",
  "es": 1568972368000,
  "id": 11,
  "isDdl": false,
  "mysqlType": {...},
  "pkNames": [
    "id"
  ],
  "sql": "",
  "sqlType": {...},
  "table": "canal_user",
  "ts": 1568972369005,
  "type": "UPDATE"
}

O Flink oferece suporte a esses dois formatos principais de codificação de ferramentas CDC, que podem ser passados por format="canal-json" ou format="debezium-json".

foto

4. Rastreabilidade do código-fonte

Na seção acima, é mencionado que o Flink escolheu o Debezium como o mecanismo incorporado para implementar o CDC. Atualmente, os conectores suportados pelo Flink CDC são os seguintes:

Nota: O suporte do conector para Mongo precisa ser usado na versão Flink CDC2.0

Base de dados	Versão
MySQL	Banco de dados: 5.7, 8.0.xJDBC Driver: 8.0.16
PostgreSQLName	Banco de dados: 9.6, 10, 11, 12Driver JDBC: 42.2.12
MongoDBGenericName	Banco de dados: 4.0, 4.2, 5.0MongoDB Driver: 4.3.1

As versões Flink correspondentes aos conectores Flink CDC são as seguintes:

Versão do Conector Flink CDC	Versão do Flink
1.0.0	1.11.*
1.1.0	1.11.*
1.2.0	1.12.*
1.3.0	1.12.*
1.4.0	1.13.*
2.0.0	1.13.*

4.1、Debezium-Mysql

Antes de aprender mais sobre como o Flink combina com o Debezium e o processo de interação específico, vamos dar uma breve olhada em como o Debezium implementa a captura de alteração de evento. A figura abaixo mostra a função do Debezium (tomando a versão Debezium1.2 como exemplo) em todo o link do CDC:

foto

Tomando o Mysql como exemplo, antes de usar o Debezium, o seguinte trabalho precisa ser preparado:

4.1.0, Preparações

1. Precisa autorizar a conta mysql

 GRANT SELECT, RELOAD, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'user' IDENTIFIED BY 'password';

2. Abra o log binário do Mysql

-- 1、检查是否已经开启
SELECT variable_value as "BINARY LOGGING STATUS (log-bin) ::"
FROM information_schema.global_variables WHERE variable_name='log_bin';
 
--2、配置服务文件，开启binlog
server-id         = 223344
log_bin           = mysql-bin
binlog_format     = ROW
binlog_row_image  = FULL
expire_logs_days  = 10

3. Ative o GTID

Global Transaction Identifiers (GTIDs) identificam exclusivamente transações que ocorrem em servidores dentro de um cluster. Embora o Debezium MySQL Connector não precise dele, usar GTIDs pode simplificar a replicação e tornar mais fácil confirmar se o servidor mestre e o servidor escravo são consistentes. GTIDS só pode ser usado após Mysql5.6+

-- 1、开启gtid_mode
gtid_mode=ON
 
--2、开启enforce_gtid_consistency
enforce_gtid_consistency=ON
 
--3、检测是否生效
show global variables like '%GTID%';

4.1.1, executa instantâneos do banco de dados (leitura completa)

Quando o Mysql Connector é iniciado pela primeira vez, ele executará primeiro um instantâneo inicial consistente do banco de dados. O principal motivo é que o Mysql geralmente é definido para limpar o log binário após um determinado período de tempo, para garantir exatamente- uma vez, tire um instantâneo primeiro. O modo instantâneo padrão é inicial, que pode ser ajustado por meio do parâmetro snapshot.mode. Em seguida, observe os detalhes do instantâneo específico:

Primeiro, obtenha um bloqueio de leitura global para impedir que outros clientes gravem (se o Debezium detectar que os bloqueios globais não são permitidos, ele será alterado para um bloqueio de nível de tabela). Deve-se observar que o instantâneo em si não pode impedir que outros clientes executem DDL Porque isso pode interferir na tentativa do Conector de ler o local do log binário e o esquema da tabela. Um bloqueio de leitura global é mantido durante a leitura do local do log binário e, em seguida, liberado em uma etapa posterior.
Inicie uma transação de leitura repetível para garantir que todas as leituras subsequentes sejam feitas em um instantâneo consistente.
Leia a localização atual do log binário.
Leia o esquema correspondente às tabelas da biblioteca permitidas pela configuração do Connecto.
Libere o bloqueio global de leitura/bloqueio em nível de tabela e outros clientes poderão gravar neste momento.
Escreva a instrução de alteração DDL no tópico correspondente (isso também é para garantir consistência para salvar todas as instruções DDL, quando o conector reiniciar após travar ou ser interrompido normalmente, todas as instruções DDL podem ser lidas neste tópico para reconstruir a estrutura da tabela em um determinado apontar no tempo até o ponto no log binário antes da falha para evitar que inconsistências de esquema causem exceções).
Varre as tabelas da biblioteca e gera um evento para cada linha no tópico de uma tabela específica.
Confirme a transação, registrando o instantâneo concluído no deslocamento do Conector.

Se o conector falhar ao fazer um instantâneo, ele criará um novo instantâneo quando for reiniciado. Depois que o instantâneo for concluído, ele começará a ler no mesmo local do log binário, para que nenhum evento de alteração seja perdido. Se o Conector for interrompido por muito tempo e quando o servidor MySQL limpar arquivos binlog mais antigos, a última posição do Conector poderá ser perdida. Quando o conector for reiniciado, o servidor MySQL não terá mais um ponto de partida e o conector executará outro instantâneo inicial.

foto

4.1.2. Leitura incremental

Inicialize um cliente Binlog e iniciará um thread chamado binlog-client
O cliente registrará o ouvinte de eventos, que chamará um método handleEvent, principalmente para atualização de deslocamento, processamento de eventos de encaminhamento, notificação de heartbeat e outras lógicas, por exemplo, quando mysqld escreve para mudar para um novo binlog ou executa flush logs ou o binlog atual o tamanho do arquivo é maior que Quando max_binlog_size for definido, a posição do log binário será redefinida.
Configure uma série de desserializadores para analisar de acordo com diferentes tipos de eventos, como excluir, atualizar e inserir eventos. Em seguida, manipuladores de eventos como handleDelete, handleUpdate e handleInsert serão chamados para processamento.
Quando um evento for detectado, o processador específico será chamado de acordo com o tipo de evento específico, que não é o foco da explicação aqui. Este artigo explica principalmente como o flink recebe essa parte dos dados e converte a estrutura de dados que ele suporta.

4.2、Flink-cdc-mysql

Haverá um artigo separado para apresentar como o Flink chama o mecanismo Debezium. Aqui está um diagrama de relacionamento de chamada primeiro, e os leitores podem lê-lo sozinhos quando tiverem tempo

foto

4.3、Propriedades do Debezium-Mysql

A tabela a seguir é o arquivo de configuração que acompanha o debezium. Ele ainda pode ser reutilizado no flink cdc. Você só precisa adicionar o prefixo "debezium." antes de usá-lo para fazer efeito.

Propriedade	Padrão	Descrição
nome		O nome exclusivo do conector, se o nome for o mesmo, ele falhará e relatará um erro
conector.classe		A classe de carregamento do conector Connector, use io.debezium.connector.mysql.MySqlConnector para o conector Mysql
tarefas.max	1	O número máximo de tarefas criadas pelo Connector, apenas uma tarefa é usada para mysql.
banco de dados.nome do host		endereço do banco de dados mysql
banco de dados.porta	3306	porta do banco de dados mysql
banco de dados.usuário		Nome de usuário de autenticação do banco de dados Mysql
banco de dados.senha		Senha de autenticação do banco de dados Mysql
banco de dados.servidor.nome		nome do serviço mysql
banco de dados.servidor.id	aleatório	ID do serviço MySQL
database.history.kafka.topic		Tópico que armazena o esquema do histórico da tabela do banco de dados
database.history.kafka.bootstrap.servers		O endereço kafka onde o esquema de histórico da tabela do banco de dados é armazenado
database.whitelist	string vazia	一个可选的逗号分隔的正则表达式列表，与要监控的数据库名称相匹配；任何不包括在白名单中的数据库名称将被排除在监控之外。默认情况下，所有数据库都将被监控。不能与database.blacklist一起使用
database.blacklist	empty string	一个可选的逗号分隔的正则表达式列表，与数据库名称相匹配，以排除在监控之外；任何不包括在黑名单中的数据库名称将被监控。不能与database.whitelist一起使用
table.whitelist	empty string	一个可选的逗号分隔的正则表达式列表，用于匹配要监控的表的全称表标识符；任何不包括在白名单中的表将被排除在监控之外。每个标识符的形式是databaseName.tableName。默认情况下，连接器将监控每个被监控数据库中的每个非系统表。不能与table.blacklist一起使用
table.blacklist	empty string	一个可选的逗号分隔的正则表达式列表，用于匹配要从监控中排除的表的全称表标识符；任何不包括在黑名单中的表都将被监控。每个标识符的形式是databaseName.tableName。不能与table.whitelist一起使用
column.blacklist	empty string	一个可选的逗号分隔的正则表达式列表，该列表与应从更改事件消息值中排除的列的全称名称相匹配。列的全称是数据库名.表名.列名，或者数据库名.模式名.表名.列名
column.truncate.to.length.chars	n/a	一个可选的逗号分隔的正则表达式列表，它与基于字符的列的完全限定名称相匹配，如果字段值长于指定的字符数，其值应在变更事件消息值中被截断。在一个配置中可以使用具有不同长度的多个属性，尽管在每个属性中长度必须是一个正整数。列的全称是数据库名.表名.列名的形式
column.mask.with.length.chars	n/a	当列长度超过指定长度，那么多余的值由*来替换
column.mask.hash.hashAlgorithm.with.salt.salt	n/a	列加盐操作
time.precision.mode	adaptive_time_microseconds	时间、日期和时间戳可以用不同种类的精度表示，包括。adaptive_time_microseconds（默认）根据数据库列的类型，使用毫秒、微秒或纳秒的精度值，准确捕获日期、数据时间和时间戳的值，但TIME类型的字段除外，它总是被捕获为微秒。adaptive（已弃用）根据数据库列的类型，使用毫秒、微秒或纳秒的精度，完全按照数据库中的时间和时间戳值来捕捉；或者connector总是使用Kafka Connector内置的时间、日期和时间戳的表示法来表示时间和时间戳值，它使用毫秒精度，而不管数据库列的精度
decimal.handling.mode	precise	指定连接器应该如何处理DECIMAL和NUMERIC列的值：precision（默认）使用java.math.BigDecimal值精确表示它们，在变化事件中以二进制形式表示；或者使用double值表示它们，这可能会导致精度的损失，但会更容易使用。 string选项将值编码为格式化的字符串，这很容易使用，但会失去关于真正类型的语义信息
bigint.unsigned.handling.mode	long	指定BIGINT UNSIGNED列在变化事件中的表示方式，包括：precision使用java.math.BigDecimal表示数值，在变化事件中使用二进制表示法和Kafka Connect的org.apache.kafka.connect.data.Decimal类型进行编码； long（默认）使用Java的long表示数值，它可能不提供精度，但在消费者中使用起来会容易得多。只有在处理大于2^63的值时，才应该使用精确设置，因为这些值不能用long来表达。
include.schema.changes	true	指定是否要将数据库schema变更事件推送到Topic中
include.query	false	指定连接器是否应包括产生变化事件的原始SQL查询。注意：这个选项要求MySQL在配置时将binlog_rows_query_log_events选项设置为ON。查询将不会出现在从快照过程中产生的事件中。启用该选项可能会暴露出被明确列入黑名单的表或字段，或通过在变更事件中包括原始SQL语句而被掩盖。出于这个原因，这个选项默认为 "false"
event.processing.failure.handling.mode	fail	指定connector在反序列化binlog事件过程中对异常的反应。 fail表示将传播异常，停止Connector Warn将记录有问题的事件及binlog偏移量，然后跳过 skip:直接跳过有问题的事件
inconsistent.schema.handling.mode	fail	指定连接器应该如何应对与内部Schema表示中不存在的表有关的binlog事件（即内部表示与数据库不一致）。 fail将抛出一个异常（指出有问题的事件及其binlog偏移），并停止连接器。 warn将跳过有问题的事件，并把有问题事件和它的binlog偏移量记录下来。 skip将跳过有问题的事件。
max.queue.size	8192	指定阻塞队列的最大长度，从数据库日志中读取的变更事件在写入Kafka之前会被放入该队列。这个队列可以为binlog reader提供反向压力，例如，当写到Kafka的速度较慢或Kafka不可用时。出现在队列中的事件不包括在这个连接器定期记录的偏移量中。默认为8192，并且应该总是大于max.batch.size属性中指定的最大批次大小。
max.batch.size	2048	指定在该连接器的每次迭代中应处理的每批事件的最大长度。默认值为2048
poll.interval.ms	1000	指定连接器在每次迭代过程中等待新的变化事件出现的毫秒数。默认为1000毫秒，或1秒
connect.timeout.ms	30000	指定该连接器在尝试连接到MySQL数据库服务器后，在超时前应等待的最大时间（毫秒）。默认值为30秒
tombstones.on.delete	true	控制是否应在删除事件后生成墓碑事件。当为真时，删除操作由一个删除事件和一个后续的墓碑事件表示。当false时，只有一个删除事件被发送。发出墓碑事件（默认行为）允许Kafka在源记录被删除后完全删除所有与给定键有关的事件。
message.key.columns	empty string	一个分号的正则表达式列表，匹配完全限定的表和列，以映射一个主键。每一项（正则表达式）必须与代表自定义键的<完全限定的表>：<列的逗号分隔列表>相匹配。完全限定的表可以定义为databaseName.tableName。
binary.handling.mode	bytes	指定二进制（blob、binary、varbinary等）列在变化事件中的表示方式，包括：bytes表示二进制数据为字节数组（默认），base64表示二进制数据为base64编码的String，hex表示二进制数据为hex编码的（base16）String

connect.keep.alive	true	指定是否应使用单独的线程来确保与MySQL服务器/集群保持连接
table.ignore.builtin	true	指定是否应该忽略内置系统表。无论表的白名单或黑名单如何，这都适用。默认情况下，系统表被排除在监控之外，当对任何系统表进行更改时，不会产生任何事件。
database.history.kafka.recovery.poll.interval.ms	100	用于指定连接器在启动/恢复期间轮询持久数据时应等待的最大毫秒数。默认值是100ms
database.history.kafka.recovery.attempts	4	在连接器恢复之前，连接器尝试读取持久化历史数据的最大次数。没有收到数据后的最大等待时间是recovery.attempts x recovery.poll.interval.ms
database.history.skip.unparseable.ddl	false	指定连接器是否应该忽略畸形或未知的数据库语句，或停止处理并让操作者修复问题。安全的默认值是false。跳过应该谨慎使用，因为在处理binlog时，它可能导致数据丢失或混乱
database.history.store.only.monitored.tables.ddl	false	指定连接器是否应该记录所有的DDL语句或（当为true时）只记录那些与Debezium监控的表有关的语句（通过过滤器配置）。安全的默认值是false。这个功能应该谨慎使用，因为当过滤器被改变时，可能需要缺失的数据。
database.ssl.mode	disabled	指定是否使用加密的连接。默认是disabled，并指定使用未加密的连接。如果服务器支持安全连接，preferred选项会建立一个加密连接，否则会退回到未加密连接。 required选项建立一个加密连接，但如果由于任何原因不能建立加密连接，则会失败。 verify_ca选项的行为类似于required，但是它还会根据配置的证书颁发机构（CA）证书来验证服务器的TLS证书，如果它不匹配任何有效的CA证书，则会失败。 verify_identity选项的行为与verify_ca类似，但另外验证服务器证书与远程连接的主机是否匹配。
binlog.buffer.size	0	Binlog Reader使用的缓冲区的大小。在特定条件下，MySQL Binlog可能包含Roldback语句完成的未提交的数据。典型示例正在使用SavePoints或混合单个事务中的临时和常规表更改。当检测到事务的开始时，Debezium尝试向前滚动Binlog位置并找到提交或回滚，以便决定事务的更改是否会流流。缓冲区的大小定义了Debezium可以在搜索事务边界的同时的交易中的最大变化次数。如果事务的大小大于缓冲区，则Debezium需要重新卷起并重新读取流式传输时不适合缓冲区的事件。0代表禁用缓冲。默认情况下禁用。注意：此功能还在测试
snapshot.mode	initial	指定连接器在启动允许快照时的模式。默认为inital，并指定仅在没有为逻辑服务器名称记录偏移时才能运行快照。 when_needed选项指定在启动时运行快照，只要它认为它需要（当没有可用偏移时，或者以前记录的偏移量在指定服务器中不可用的Binlog位置或GTID）。 never选项指定不运行快照。 schema_only选项只获取启动以来的更改。 schema_only_recovery选项是现有连接器的恢复选项，用来恢复损坏或者丢失的数据库历史topic
snapshot.locking.mode	minimal	控制连接器是否持续获取全局MySQL读取锁（防止数据库的任何更新）执行快照。有三种可能的值minimal，extended，none。 minimal仅在连接器读取数据库模式和其他元数据时保持全局读取锁定仅适用于快照的初始部分。快照中的剩余工作涉及从每个表中选择所有行，即使在不再保持全局读取锁定状态时，也可以使用可重复读取事务以一致的方式完成。虽然其他MySQL客户端正在更新数据库。 extended指在某些情况下客户端提交MySQL从可重复读取语义中排除的操作，可能需要阻止所有写入的全部持续时间。 None将阻止连接器在快照过程中获取任何表锁。此值可以与所有快照模式一起使用，但仅在快照时不发生Schema更改时，才能使用。注意:对于使用MyISAM引擎定义的表，表仍将被锁定，只要该属性设置为MyISAM获取表锁定。InnoDB引擎获取的是行级锁
snapshot.select.statement.overrides		控制哪些表的行将被包含在快照中。此属性包含一个以逗号分隔的完全限定的表（DB_NAME.TABLE_NAME）的列表。单个表的选择语句在进一步的配置属性中指定，每个表由 id snapshot.select.statement.overrides.[DB_NAME].[TABLE_NAME] 识别。这些属性的值是在快照期间从特定表检索数据时要使用的 SELECT 语句。对于大型的仅有附录的表来说，一个可能的用例是设置一个特定的点来开始（恢复）快照，以防止之前的快照被打断。注意：这个设置只对快照有影响。从binlog捕获的事件完全不受其影响。
min.row.count.to.stream.results	1000	在快照操作中，连接器将查询每个包含的表，为该表的所有行产生一个读取事件。这个参数决定了MySQL连接是否会将表的所有结果拉入内存，或者是否会将结果流化（可能会慢一些，但对于非常大的表来说是可行的）。该值指定了在连接器将结果流化之前，表必须包含的最小行数，默认为1000。将此参数设置为'0'，可以跳过所有的表大小检查，并在快照期间始终流式处理所有结果
database.initial.statements		建立到数据库的 JDBC 连接（不是事务日志读取连接）时要执行的 SQL 语句的分号分隔列表。使用双分号 (';;') 将分号用作字符而不是分隔符。注意：连接器可以自行决定建立 JDBC 连接，因此这通常仅用于配置会话参数，而不用于执行 DML 语句
snapshot.delay.ms		连接器在启动后，进行快照之前需要等待的时间间隔；当在集群中启动多个连接器时可以避免快照中断
snapshot.fetch.size		指定在快照时应该从表中一次性读取的最大行数
snapshot.lock.timeout.ms	10000	指定在快照时等待获取表锁的最长时间，如果在指定时间间隔内未获取到表锁的时候，则快照失败
enable.time.adjuster		O MySQL permite que os usuários insiram valores de ano como 2 ou 4 dígitos. No caso de dois dígitos, o valor é mapeado automaticamente para o intervalo de 1970 a 2069. Isso geralmente é feito pelo banco de dados. Definido como verdadeiro (padrão) quando Debezium faz a conversão. Defina como falso quando a transformação for totalmente delegada ao banco de dados
higienizar.campos.nomes	true quando a configuração do conector especifica explicitamente os parâmetros key.converter ou value.converter para usar o Avro; caso contrário, o padrão é false.	Se os nomes de campo devem ser limpos para cumprir os requisitos de nomenclatura Avro
operações.ignoradas		Uma lista separada por vírgulas de operações operacionais a serem ignoradas. As operações incluem: c para inserir, u para atualizar e d para excluir. Por padrão, nenhuma ação é ignorada

Flink da entrada ao abandono (nove) - dez mil palavras para explicar o design do CDC (1)

Acho que você gosta