El conector CDC de MySQL permite leer datos instantáneos y datos incrementales de la base de datos MySQL.
Este documento traduce cómo configurar el conector CDC de MySQL para ejecutar consultas SQL en la base de datos MySQL según el sitio web oficial de ververica .

1. Dependencia

Para configurar el conector MySQL CDC, la siguiente tabla proporciona información de dependencia para dos proyectos que usan una herramienta de automatización de compilación (como Maven o SBT) y el cliente SQL con el paquete SQL JAR.

1. Dependencia de Maven

<dependency>
  <groupId>com.alibaba.ververica</groupId>
  <artifactId>flink-connector-mysql-cdc</artifactId>
  <version>1.1.0</version>
</dependency>

2. JAR de cliente SQL

Descargue flink-sql-connector-mysql-cdc-1.1.0.jar y colóquelo en <FLINK_HOME> / lib /.

Dos, configure el servidor MySQL

Debe definir un usuario de MySQL con los permisos adecuados para todas las bases de datos supervisadas por el conector Debezium MySQL.

1. Cree un usuario de MySQL:

mysql> CREATE USER 'user'@'localhost' IDENTIFIED BY 'password';

2. Otorgue los permisos necesarios al usuario:

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

3. Finalice los permisos de usuario:

mysql> FLUSH PRIVILEGES;

Vea más información sobre descripciones de permisos: https://debezium.io/documentation/reference/1.2/connectors/mysql.html#_permissions_explained .

Tres, presta atención

1. ¿Cómo funciona el código fuente de MySQL CDC?

Al iniciar la fuente CDC de MySQL, adquirirá un bloqueo de lectura global (FLUSH TABLES WITH READ LOCK), que evitará que otras bases de datos escriban. Luego, lee la ubicación actual del binlog y el esquema de la base de datos y la tabla. Después de eso, se liberará el bloqueo de lectura global. Luego, escanea la tabla de la base de datos y lee el binlog de la ubicación previamente registrada. Flink ejecutará periódicamente puntos de control para registrar la ubicación del binlog. Si ocurre una falla, el trabajo se reiniciará y se recuperará de la ubicación del binlog donde se completó el punto de control. Por lo tanto, solo garantiza una semántica.

2. Otorgue permisos de RELOAD a los usuarios de MySQL

Si al usuario de MySQL no se le otorgan permisos de RELOAD, la fuente CDC de MySQL usará bloqueos a nivel de tabla y usará este método para realizar instantáneas. Esto evitará escribir durante un período de tiempo más largo.

3. Bloqueo de lectura global (MESAS DE DESCARGA CON BLOQUEO DE LECTURA)

El bloqueo de lectura global se mantiene durante la lectura de la ubicación y el esquema de binlog. Esto puede tardar unos segundos , dependiendo del número de mesas. El bloqueo de lectura global evita la escritura , por lo que aún puede afectar el negocio en línea.
Si desea omitir el bloqueo de lectura y puede tolerar la semántica al menos una vez , puede agregar la opción ** 'debezium.snapshot.locking.mode' = 'none' ** para omitir el bloqueo.

4. Establezca una ID de SERVIDOR de red diferente para cada trabajo

Cada cliente de base de datos MySQL utilizado para leer binlog debe tener un ID único llamado ID de servidor. El servidor MySQL utilizará este ID para mantener las conexiones de red y las ubicaciones de binlog. Si diferentes trabajos comparten el mismo ID de servidor, es posible que se produzca una lectura desde la ubicación incorrecta del binlog.
Consejo: De forma predeterminada, cuando se inicia TaskManager, la identificación del servidor es aleatoria. Si el TaskManager falla, es posible que tenga un ID de servidor diferente cuando se inicie nuevamente. Pero esto no debería suceder con frecuencia (la excepción del trabajo no reiniciará TaskManager), ni tendrá mucho impacto en el servidor MySQL.

Por lo tanto, se recomienda establecer un ID de servidor diferente para cada trabajo, por ejemplo:

通过Sugerencias SQL * ： SELECT * FROM source_table / * + OPTIONS ('server-id' = '123456') /;
Establecer al crear la fuente a través de Stream ApI: ** MySQLSource.builder () .xxxxxx .serverId (123456); **

Importante : Se puede decir que el binlog de Mysq está en el nivel de la biblioteca, por lo que extraer diferentes tablas en una biblioteca o la misma tabla con el mismo ID de servidor puede causar pérdida de datos. Por lo que se recomienda establecer la identificación del servidor. (También le pregunté al jefe de Jark en el correo de la comunidad: dirección de entrega )

5. El punto de control no se puede realizar durante el análisis de la tabla de la base de datos.

Durante el escaneo de la tabla, no podemos realizar puntos de control porque no hay lugar para recuperar. Para no realizar un punto de control, la fuente CDC de MySQL mantendrá el punto de control esperando el tiempo de espera. Los puntos de control agotados se identificarán como puntos de control fallidos, que activarán la conmutación por error de los trabajos de Flink de forma predeterminada. Por lo tanto, si la tabla de la base de datos es grande, se recomienda agregar la siguiente configuración de Flink para evitar la conmutación por error debido a los puntos de control de tiempo de espera:

execution.checkpointing.interval: 10min
execution.checkpointing.tolerable-failed-checkpoints: 100
restart-strategy: fixed-delay
restart-strategy.fixed-delay.attempts: 2147483647

6. Establecer el tiempo de espera de la sesión de MySQL

Al crear una instantánea inicialmente consistente para una base de datos grande, la conexión que establece puede expirar mientras lee la tabla. Puede evitar este comportamiento configurando Interactive_timeout y wait_timeout en el archivo de configuración de MySQL.

Interactive_timeout: la cantidad de segundos que el servidor espera la actividad antes de cerrar una conexión interactiva. Consulte la documentación de MySQL .
wait_timeout: la cantidad de segundos que el servidor espera su actividad antes de cerrar una conexión no interactiva. Consulte la documentación de MySQL .

Cuarto, cómo crear una tabla CDC de MySQL

1. Método SQL:

(1) La tabla de definición es la siguiente:

-- register a MySQL table 'orders' in Flink SQL
CREATE TABLE orders (
  order_id INT,
  order_date TIMESTAMP(0),
  customer_name STRING,
  price DECIMAL(10, 5),
  product_id INT,
  order_status BOOLEAN
) WITH (
  'connector' = 'mysql-cdc',
  'hostname' = 'localhost',
  'port' = '3306',
  'username' = 'root',
  'password' = '123456',
  'database-name' = 'mydb',
  'table-name' = 'orders'
);

-- read snapshot and binlogs from orders table
SELECT * FROM orders;

(2) Opciones de conector

      待补充。。。

2, API de transmisión

El conector CDC de MySQL también puede ser una fuente DataStream. Puede crear SourceFunction de la siguiente manera:

import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;
import org.apache.flink.streaming.api.functions.source.SourceFunction;
import com.alibaba.ververica.cdc.debezium.StringDebeziumDeserializationSchema;
import com.alibaba.ververica.cdc.connectors.mysql.MySQLSource;

public class MySqlBinlogSourceExample {
  public static void main(String[] args) throws Exception {
    SourceFunction<String> sourceFunction = MySQLSource.<String>builder()
      .hostname("localhost")
      .port(3306)
      .databaseList("inventory") // monitor all tables under inventory database
      .username("flinkuser")
      .password("flinkpw")
      .deserializer(new StringDebeziumDeserializationSchema()) // converts SourceRecord to String
      .build();

    StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();

    env
      .addSource(sourceFunction)
      .print().setParallelism(1); // use parallelism 1 for sink to keep message ordering

    env.execute();
  }
}

Cinco, características

1. Procesamiento de una vez exactamente

El conector MySQL CDC es un conector Flink Source. Primero leerá la instantánea de la base de datos y luego, incluso si hay una falla, continuará leyendo el registro binario con un procesamiento único. Lea cómo el conector realiza instantáneas de la base de datos.

2. Lectura de un solo hilo

La fuente CDC de MySQL no se puede leer en paralelo porque solo una tarea puede recibir eventos de Binlog.

6. Mapeo de tipos de datos.

Para ser agregado. . .

Siete preguntas frecuentes

1. ¿Cómo omitir la instantánea y leer solo desde binlog?

Puede controlar debezium.snapshot.mode a través de las opciones , puede configurarlo en:

nunca: especifica que la conexión nunca debe usar instantáneas, y cuando el nombre del servidor lógico se usa para el primer inicio, el conector debe leer desde el principio del binlog; utilícelo con precaución, porque solo es válido cuando el binlog es garantizado para contener el historial completo de la base de datos.
schema_only: si no necesita instantáneas continuas de los datos desde que se inició el conector, pero solo necesita cambiarlas, puede usar la opción schema_only, donde el conector solo toma una instantánea del esquema (no de los datos).

2. ¿Cómo leer una base de datos compartida que contiene varias tablas (como user_00, user_01, ..., user_99)?

La opción table-name admite expresiones regulares para monitorear múltiples tablas que coinciden con expresiones regulares. Por lo tanto, puede establecer table-name en user _. * Para monitorear todas las tablas de prefijos de user_. La opción del nombre de la base de datos es la misma. Tenga en cuenta que las tablas compartidas deben estar en el mismo esquema.

3. ConnectException: DML '...' recibido para su procesamiento, binlog puede contener declaraciones de uso o eventos generados en base a un formato de copia mixto

Si existe la excepción anterior, verifique si binlog_format es ROW, puede ejecutarlo en el cliente MySQL ejecutando show variables como '% binlog_format%'. Tenga en cuenta que incluso si la configuración de su base de datos para binlog_format es ROW, puede cambiar esta configuración a través de otras sesiones, como SET SESSION binlog_format = 'MIXED'; SET SESSION tx_isolation = 'REPEATABLE-READ'; COMMIT ;. También asegúrese de que ninguna otra sesión esté cambiando esta configuración

8. Problemas encontrados en la práctica