Flink desde la entrada hasta el abandono (nueve) - diez mil palabras para explicar el diseño de CDC (1)

1. Preparación

Antes de comenzar a estudiar el principio de Flink CDC (este artículo presenta primero la versión CDC1.0 y ampliará la introducción de las funciones de 2.0 más adelante), se deben realizar las siguientes tareas (este artículo comienza con el entorno Flink1.12 )

1. Abra el sitio web oficial de Flink (consulte la introducción del módulo Connector)

2. Abra Github y descargue el código fuente (el enlace no se puede colocar en este momento, los lectores pueden buscar en github por sí mismos)

apache-flink

Flink-cdc-conectores

deuda

3. empezar a hundirse

2. Propuesta de diseño

2.1 Motivación del diseño

CDC (Captura de datos de cambios, captura de datos de cambios) es un modelo relativamente popular en las empresas, que se utiliza principalmente en la sincronización de datos, el índice de búsqueda, la actualización de caché y otros escenarios; la comunidad inicial necesita admitir la capacidad de extraer e interpretar directamente los registros de cambios en Table Funciones API y SQL para ampliar los escenarios de uso de Flink .

Por otro lado, el concepto de "tabla dinámica" se propuso anteriormente y se definieron dos modos en los flujos: modo de adición y modo de actualización . Flink ya admite el modo de adición que convierte la transmisión en una tabla dinámica, pero aún no admite el modo de actualización, por lo que la interpretación del registro de cambios es completar la pieza faltante del rompecabezas para obtener un concepto completo de tabla dinámica. Por supuesto, ahora no solo se admite la actualización, sino que también se admite el modo de retracción, que se explicará por separado más adelante.

2.2, selección de herramientas CDC

Los esquemas CDC comunes se comparan de la siguiente manera:

1. Función perfecta

Para las herramientas de CDC, actualmente hay muchas opciones, como Debezium, Canal y otras soluciones populares; actualmente Debezium admite Mysql, PG, SQL Server, Oracle, Cassandra y Mongo, si Flink admite Debezium, significa que Flink puede conectarse a los siguientes El registro de cambios de todas las bases de datos en la captura de pantalla es beneficioso para mejorar todo el ecosistema. Entre ellos, Debezium admite la sincronización completa + incremental , que es muy flexible y hace posible Exactly-Once.

Los tipos de bases de datos admitidos por Debezium son los siguientes:

2. Abrazar a la comunidad y facilitar la expansión

Si elige Debezium como el motor integrado de Flink, puede integrarlo en el código base como un paquete de dependencia en lugar de ejecutarlo a través del conector kafka. Tampoco necesita comunicarse directamente con el servidor MySQL, y no necesita necesita lidiar con instantáneas complejas, GTID, bloqueos, etc. ventaja. mientras abraza y colabora con la comunidad Debezium

En tercer lugar, la estructura de datos internos es similar

Para la estructura de datos de tipo RowData dentro de Flink SQL, hay un metadato RowKind, que tiene 4 tipos, a saber, insertar (Insertar), actualizar (ACTUALIZAR_ANTES de la actualización, ACTUALIZAR_DESPUÉS de la actualización) y eliminar (DELETE).Estos cuatro tipos de datos pueden ser encontrado Es básicamente consistente con la estructura de Binlog.

Aquí hay una explicación del significado de cada campo de metadatos en la estructura de datos de Debezium:

· before field: Es un campo opcional, que representa el estado antes de que ocurra el evento, si es una operación de creación, el valor de este campo es nulo.

· after field: Es un campo opcional, que representa el estado de la fila después de que ocurre el evento, si es una operación de borrado, entonces el valor de este campo es nulo.

· fuente: es un campo obligatorio, incluida la metainformación del evento, como el desplazamiento, el archivo binlog, la base de datos y la tabla.

ts_ms: representa la marca de tiempo de los eventos de procesamiento de Debezium

· Campo OP: este campo también tiene 4 valores, a saber, C (crear), U (actualizar), D (eliminar) y Leer®. Para la operación U, su parte de datos contiene Antes y Después.

3. Conceptos

Habrá muchos conceptos involucrados aquí, todos tienen una cognición primero, y luego se dividirán y explicarán por separado más adelante.

3.1, Corriente

El concepto de flujo es realmente fácil de entender **El flujo tiene dos características: acotación y modo de cambio. ** Luego presenta estas dos características por separado:

1. Modo de cambio:

Como se muestra en la figura anterior: hay dos modos de tabla dinámica, modo de adición y modo de reemplazo (upsert y retract) . A continuación, introduzca brevemente la diferencia entre los dos

Para el modo de adición, es fácil de entender. Si no se especifica ninguna clave principal en la definición de la tabla, una vez que se agrega un registro a la tabla, nunca se actualiza ni elimina agregando el registro de flujo a la tabla como una nueva fila.

Para el modo Reemplazar, si la clave principal está definida en la tabla, si no hay ningún registro con el mismo atributo de clave, se insertará en la tabla; de lo contrario, se reemplazará. Luego, para el modo de reemplazo, se subdivide en modos de inserción y retracción:

Para el modo Upsert, incluye dos mensajes, Upsert (insertar y actualizar) y DELETE.La principal diferencia entre este modo y el modo retract es que los cambios de UPDATE se codificarán con un solo mensaje, lo que es más eficiente. _

Para el modo Retract, un flujo de actualización contiene mensajes ADD y RETRACT. Para un cambio Insert, se codificará en un mensaje ADD. Para un cambio DELETE, se codificará en un mensaje RETRACT. Para un cambio UPDATE, será codificado en Actualizado antes como el mensaje de retractación y el mensaje AGREGAR. Este modo debe dividirse en dos mensajes para el evento de actualización y la eficiencia será relativamente baja. Aquí hay una breve introducción a lo que es un flujo de retroceso, como se muestra en la siguiente figura:

Operación	Usuario	Contar (dirección URL)	Marca
yo (insertar)	María	1
yo (insertar)	Beto	1
-U(Actualizar-Antes)	María	0	borrará el registro
+U(Actualizar-Después)	María	2
yo (insertar)	liz	1
-U(Actualizar-Antes)	Beto	0	borrará el registro
+U(Actualizar-Después)	Beto	2

2. acotación

Secuencia limitada: consta de eventos de tamaño limitado, la consulta de trabajo procesa los datos disponibles actualmente y finalizará después de eso.

Secuencia ilimitada: consiste en eventos infinitos, si la entrada es una secuencia ilimitada, la consulta se procesa continuamente a medida que llegan todos los datos.

3. Resumen:

Acotación \ Cambiar modo	Adjuntar	Actualizar
Ilimitado	Agregar flujo ilimitado por ejemplo, registros de Kafka	Actualizar flujo ilimitado por ejemplo, captura continuamente los cambios de la tabla MySQL
Encerrado	Agregar flujo delimitado por ejemplo, un archivo de parquet en HDFS, una tabla mysql	Actualizar flujo delimitado por ejemplo, capturar cambios de la tabla MySQL hasta un punto de tiempo

3.2, tabla dinámica Tabla dinámica

Las tablas dinámicas son tablas que cambian con el tiempo y se pueden consultar como tablas regulares tradicionales. Una tabla dinámica se puede convertir en una secuencia y una secuencia se puede convertir en una tabla dinámica (debe tener el mismo esquema, y ​​el método de conversión depende de si el esquema de la tabla contiene la definición de la clave principal). Nota: Todas las tablas creadas en Flink SQL son tablas dinámicas. Una consulta en una tabla dinámica genera una nueva tabla dinámica (actualizada de acuerdo con la entrada), y si la consulta termina depende de los límites de la entrada.

DynamicTable es un objeto conceptual y stream es una representación física.

3.3, Registro de cambios

El registro de cambios es una secuencia de datos adjuntos que consta de filas que contienen columnas de operaciones de cambio (para insertar/eliminar indicadores o más en el futuro) y columnas de metadatos reales. El objetivo del diseño de Flink CDC es extraer los eventos del registro de cambios y convertirlos en operaciones de cambio (como insertar, actualizar, eliminar eventos).

Convertir de un flujo de datos adjuntos a un flujo de actualización ( es decir, Interpretar registro de cambios ).

Convierta de un flujo de actualización a un flujo de datos adjuntos ( Emit Changelog ).

En Flink SQL, los datos fluyen de un operador a otro en forma de Changelog Stream. Changelog Stream en cualquier momento se puede traducir a una tabla o flujo, como se muestra en la siguiente figura:

La siguiente figura mostrará completamente la conversión entre el tipo de flujo y la tabla:

Las diferentes herramientas de CDC pueden tener diferentes métodos de codificación para Changelog, lo que también es un gran desafío para flink. Aquí hay dos soluciones populares: Debezium y Canal como ejemplos:

1. Tome Debezium como ejemplo. Debezium es una herramienta CDC construida sobre Kafka Connector. Puede transmitir flujos de cambios en tiempo real a Kafka. Debezium genera un formato unificado para el registro de cambios de Kafka. Tome la operación de actualización como ejemplo:

{
  "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
}

De forma predeterminada, Debezium genera dos eventos para las operaciones de eliminación: evento DELETE y evento Tombstone (tombstone) (con valor nulo/carga útil), el evento tombstone se usa para el mecanismo de compactación de Kafka. Cabe señalar que: Debezium no es un sistema de almacenamiento, sino que representa un formato de almacenamiento, que se basa en el formato JSON y puede convertir filas de resultados deserializados en ChangeRow o Tuple2<Boolean, Row>.

2. Canal es una herramienta CDC popular en China. Se utiliza para capturar cambios de Mysql a otros sistemas. Es compatible con los cambios de transmisión de Kafka y RocketMQ en formato JSON y formato protobuf. Aquí hay un ejemplo de la operación de actualización:

{
  "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"
}

Flink es compatible con estos dos formatos de codificación de herramientas CDC principales, que se pueden pasar a través de format="canal-json" o format="debezium-json".

4. Trazabilidad del código fuente

De la sección anterior, se menciona que Flink elige Debezium como el motor integrado para implementar CDC Actualmente, los conectores compatibles con Flink CDC son los siguientes:

Nota: El soporte del conector para Mongo debe usarse en la versión Flink CDC2.0

Base de datos	Versión
mysql	Base de datos: 5.7, 8.0.xJDBC Controlador: 8.0.16
postgresql	Base de datos: 9.6, 10, 11, 12 Controlador JDBC: 42.2.12
MongoDB	Base de datos: 4.0, 4.2, 5.0 Controlador MongoDB: 4.3.1

Las versiones de Flink correspondientes a los conectores Flink CDC son las siguientes:

Versión del conector Flink CDC	Versión 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 más sobre cómo Flink se combina con Debezium y el proceso de interacción específico, echemos un breve vistazo a cómo Debezium implementa la captura de cambios de eventos. La siguiente figura muestra el papel de Debezium (tomando la versión Debezium1.2 como ejemplo) en todo el enlace de CDC:

Tomando Mysql como ejemplo, antes de usar Debezium, se debe preparar el siguiente trabajo:

4.1.0, Preparaciones

1. Necesita autorizar la cuenta mysql

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

2. Abra el registro de archivos binarios de 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. Habilitar GTID

Los identificadores de transacciones globales (GTID) identifican de forma única las transacciones que ocurren en los servidores dentro de un clúster. Aunque Debezium MySQL Connector no lo necesita, el uso de GTID puede simplificar la replicación y facilitar la confirmación de si el servidor maestro y el servidor esclavo son consistentes. GTIDS solo se puede usar después de 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, Realiza instantáneas de la base de datos (lectura completa)

Cuando Mysql Connector se inicia por primera vez, primero realizará una instantánea consistente inicial de la base de datos. La razón principal es que Mysql generalmente está configurado para borrar el binlog después de un cierto período de tiempo, por lo que para garantizar exactamente: una vez, tome una instantánea primero. El modo de instantánea predeterminado es inicial, que se puede ajustar a través del parámetro snapshot.mode. A continuación, mire los detalles de la instantánea específica:

1. Primero obtenga un bloqueo de lectura global para bloquear la escritura de otros clientes (si Debezium detecta que los bloqueos globales no están permitidos, se cambiará a un bloqueo de nivel de tabla). Cabe señalar que la instantánea en sí no puede evitar que otros clientes ejecuten DDL Porque esto puede interferir con el intento de Connector de leer la ubicación binlog y el esquema de la tabla. Se mantiene un bloqueo de lectura global mientras se lee la ubicación binlog y luego se libera en un paso posterior.

2. Inicie una transacción de lectura repetible para asegurarse de que todas las lecturas posteriores se realicen en una instantánea coherente.

3. Leer la ubicación binlog actual.

4. Leer el esquema correspondiente a las tablas de biblioteca permitidas por la configuración de Connecto.

5. Libere el bloqueo de lectura global/bloqueo de nivel de tabla y otros clientes pueden escribir en este momento.

6. Escriba la declaración de cambio de DDL en el tema correspondiente (esto también es para garantizar la coherencia para guardar todas las declaraciones de DDL, cuando el conector se reinicia después de bloquearse o detenerse correctamente, todas las declaraciones de DDL se pueden leer desde este tema para reconstruir la estructura de la tabla en un momento específico). punto en el tiempo hasta el punto en el binlog antes del bloqueo para evitar que las inconsistencias del esquema causen excepciones).

7. Escanea las tablas de la biblioteca y genera un evento para cada fila sobre el tema de una tabla específica.

8. Confirme la transacción, registrando la instantánea completa en el desplazamiento del conector.

Si el conector falla al hacer una instantánea, creará una nueva instantánea cuando se reinicie. Una vez que la instantánea esté completa, comenzará a leer desde la misma ubicación del binlog, de modo que no se perderán los eventos de cambio. Si el conector se detiene durante demasiado tiempo y cuando el servidor MySQL purga los archivos binlog más antiguos, es posible que se pierda la última posición del conector. Cuando el conector se reinicia, el servidor MySQL ya no tiene un punto de partida y el conector realiza otra instantánea inicial.

4.1.2 Lectura incremental

1. Inicialice un cliente Binlog e iniciará un hilo llamado binlog-client

2. El cliente registrará el detector de eventos, que llamará a un método handleEvent, principalmente para la actualización de compensación, el procesamiento de eventos de reenvío, la notificación de latidos y otra lógica, por ejemplo, cuando mysqld escribe para cambiar a un nuevo binlog o ejecuta registros de vaciado o el binlog actual el tamaño del archivo es mayor que Cuando se establece max_binlog_size, se restablecerá la posición binlog.

3. Configure una serie de deserializadores para analizar según diferentes tipos de eventos, como eventos de eliminación, actualización e inserción. Luego, se llamará a los controladores de eventos como handleDelete, handleUpdate y handleInsert para su procesamiento.

4. Cuando se detecta un evento, se llamará al procesador específico según el tipo de evento específico, que no es el foco de la explicación aquí. Este artículo explica principalmente cómo flink recibe esta parte de los datos y convierte la estructura de datos que admite.

4.2, Flink-cdc-mysql

Habrá un artículo separado para presentar cómo llama Flink al motor Debezium. Aquí hay un diagrama de relación de llamadas primero, y los lectores pueden leerlo por sí mismos cuando tengan tiempo

4.3, Propiedades de Debezium-Mysql

La siguiente tabla es el archivo de configuración que viene con debezium. Todavía se puede reutilizar en flink cdc. Solo necesita agregar el prefijo "debezium". antes de usarlo para que surta efecto.

Propiedad	Por defecto	Descripción
nombre		El nombre único del conector, si el nombre es el mismo, fallará e informará un error
conector.clase		La clase de carga del conector Connector, use io.debezium.connector.mysql.MySqlConnector para el conector Mysql
tareas.max	1	El número máximo de tareas creadas por Connector, solo se usa una tarea para mysql.
base de datos.nombre de host		dirección de la base de datos mysql
base de datos.puerto	3306	puerto de base de datos mysql
base de datos.usuario		Nombre de usuario de autenticación de la base de datos Mysql
base de datos.contraseña		Contraseña de autenticación de la base de datos mysql
base de datos.servidor.nombre		Nombre del servicio mysql
base de datos.servidor.id	aleatorio	Identificación del servicio Mysql
base de datos.historia.kafka.topic		Tema que almacena el esquema histórico de la tabla de la base de datos
base de datos.historia.kafka.bootstrap.servidores		La dirección kafka donde se almacena el esquema histórico de la tabla de la base de datos
base de datos.lista blanca	cuerda vacía	一个可选的逗号分隔的正则表达式列表，与要监控的数据库名称相匹配；任何不包括在白名单中的数据库名称将被排除在监控之外。默认情况下，所有数据库都将被监控。不能与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		MySQL permite a los usuarios insertar valores de año como 2 o 4 dígitos. En el caso de dos dígitos, el valor se asigna automáticamente al rango 1970 - 2069. Esto generalmente lo hace la base de datos. Establecido en verdadero (predeterminado) cuando Debezium realiza la conversión. Establecido en falso cuando la transformación se delega completamente a la base de datos
sanitize.field.names	true cuando la configuración del conector especifica explícitamente los parámetros key.converter o value.converter para usar Avro; de lo contrario, el valor predeterminado es false.	Si desinfectar los nombres de campo para cumplir con los requisitos de nomenclatura de Avro
operaciones omitidas		Una lista separada por comas de las operaciones operativas que se deben omitir. Las operaciones incluyen: c para insertar, u para actualizar y d para eliminar. De forma predeterminada, no se salta ninguna acción.