Copyright Autores Debezium. Licenciado bajo la Licencia Apache, Versión 2.0.
Debezium es un proyecto de código abierto que proporciona una plataforma de transmisión de datos de baja latencia para la captura de datos modificados (CDC). Este conector proporciona una implementación de receptor para transmitir los cambios emitidos por Debezium a una base de datos relacional.
La implementación de este conector reconoce la fuente Debezium. Esto significa que el conector puede consumir eventos de cambio nativos de Debezium sin necesidad de utilizar ExtractNewRecordState para aplanar la estructura del evento. Esto reduce la configuración necesaria para utilizar un conector receptor JDBC. Además, esto también significa que el lado del sumidero de la tubería puede aprovechar los metadatos de Debezium, como la propagación del tipo de columna, para admitir sin problemas una resolución adecuada del tipo de columna en el lado del conector del sumidero de la tubería.
El conector de fregadero JDBC es un conector de fregadero tradicional de Kafka Connect (también conocido como consumidor). Su trabajo es leer registros de uno o más temas de Kafka y producir declaraciones SQL que se ejecutan en la base de datos de destino configurada.
Un SinkRecordDescriptor es un objeto que se construye a partir de cada SinkRecord . La mayoría de los métodos que de otro modo tomarían un SinkRecord toman este objeto descriptor en su lugar. El descriptor es, de hecho, una versión preprocesada de SinkRecord , lo que nos permite realizar este preprocesamiento una vez y luego hacer uso de esta información en todo el conector. Al agregar nuevos métodos, generalmente querrás utilizar un SinkRecordDescriptor .
Cada base de datos receptor normalmente tendrá su propia implementación DatabaseDialect que debería extender GeneralDatabaseDialect . El dialecto es uno de los mecanismos principales utilizados por el conector receptor JDBC para resolver declaraciones SQL y otras características de la base de datos en la que el conector escribirá los eventos consumidos. El conector receptor JDBC se basa en la resolución de dialecto de Hibernate para controlar el contenedor de dialecto utilizado por el conector.
Si no se detecta ninguna asignación de dialecto para la base de datos receptora que se está utilizando, el conector receptor JDBC utilizará de forma predeterminada la implementación GeneralDatabaseDialect . Esta implementación generalizada no admite todos los aspectos del conector; por ejemplo, el modo de inserción UPSERT no se admite cuando se elige este dialecto, ya que la declaración UPSERT generalmente es exclusiva de la base de datos que se utiliza. Generalmente es una buena idea agregar una nueva implementación de dialecto si una nueva base de datos receptora va a tener total compatibilidad con el amplio comportamiento del conector receptor JDBC.
Cada campo en un mensaje de Kafka está asociado con un tipo de esquema, pero este tipo de información también puede contener otros metadatos, como un nombre o incluso parámetros proporcionados por el conector de origen. El conector receptor JDBC utiliza un sistema de tipos, que se basa en el contrato io.debezium.connector.jdbc.type.Type , para manejar la vinculación de valores, la resolución de valores predeterminados y otras características que podrían ser específicas del tipo.
Existen efectivamente tres tipos diferentes de implementaciones Type :
io.debezium.connector.jdbc.type.connect .io.debezium.connector.jdbc.type.debezium .io.debezium.connector.jdbc.dialect .Los tipos se registran en un patrón jerárquico, comenzando con los tipos Kafka Connect, luego los tipos Debezium y, por último, los tipos específicos de dialecto. Esto permite que los tipos de Debezium anulen los tipos de Kafka Connect si es necesario y, finalmente, el dialecto anule cualquier otro tipo contribuido.
Los tipos se resuelven mirando primero el nombre del esquema Kafka y asignándolo a un registro de tipo. Si el esquema no tiene un nombre, el tipo de esquema se utiliza para resolverlo en un tipo. Esto permite que los tipos básicos de Kafka Connect tengan la última palabra sobre cómo se interpretan los datos si no se detecta ninguna otra implementación de tipo para el campo.
Hay dos estrategias de nomenclatura utilizadas por el conector receptor JDBC:
TableNamingStrategyColumnNamingStrategy El conector receptor JDBC se envía con implementaciones predeterminadas de ambos, que se encuentran en el paquete io.debezium.connector.jdbc.naming . El comportamiento predeterminado de estas dos estrategias es el siguiente:
. con _ y utiliza el valor configurado table.name.format para resolver el nombre final de la tabla. Entonces, suponiendo que el nombre del tema del evento es server.schema.table con el valor predeterminado table.name.format=dbo.${topic} , la tabla de destino se creará como dbo.server_schema_table .Estas dos estrategias se pueden anular especificando referencias de nombres de clase completos en la configuración del conector. Una configuración de ejemplo:
table.naming.strategy=io.debezium.connector.jdbc.naming.DefaultTableNamingStrategy
column.naming.strategy=io.debezium.connector.jdbc.naming.DefaultColumnNamingStrategy
El conector receptor JDBC mantiene un modelo relacional en memoria, similar a los conectores fuente Debezium. Estas clases de modelo relacional se pueden encontrar en el paquete io.debezium.connector.jdbc.relational .
Se requiere lo siguiente para trabajar con el código base del conector receptor Debezium JDBC y compilarlo localmente:
.mvnw para comandos de Maven) El conjunto de pruebas se basa en gran medida en el uso de TestContainer e inicia automáticamente una variedad de bases de datos de origen y receptor. Sin un entorno compatible con Docker, las pruebas de integración no se ejecutarán. Si no tiene un entorno Docker, puede omitir las pruebas de integración utilizando el argumento de línea de comando -DskipITs , que se muestra a continuación:
$ ./mvnw clean verify -DskipITs
Hay tres tipos de tipos en el conjunto de pruebas:
De forma predeterminada, todas las pruebas unitarias se ejecutan como parte de la compilación. Las pruebas de integración basadas en receptores solo se ejecutan para MySQL, PostgreSQL y SQL Server de forma predeterminada, mientras que no se ejecuta ninguna de las pruebas basadas en matrices de un extremo a otro.
Para ejecutar las pruebas de integración basadas en receptores para Oracle y DB2, se debe proporcionar el argumento -Dtest.tags para incluirlas en la compilación. Para hacer esto, agregue todas las pruebas de integración a ejecutar, como se muestra a continuación para todas las bases de datos:
$ ./mvnw clean install -Dtest.tags=it-mysql,it-postgresql,it-sqlserver,it-oracle,it-db2
Para ejecutar todas las pruebas de integración basadas en receptores para todas las bases de datos, se proporciona una etiqueta de acceso directo:
$ ./mvnw clean install -Dtest.tags=it
De manera similar, para habilitar pruebas específicas de un extremo a otro, el argumento -Dtest.tags también se puede proporcionar con las etiquetas necesarias para cada tipo de base de datos receptora:
$ ./mvnw clean install -Dtest.tags=e2e-mysql,e2e-postgresql,e2e-sqlserver,e2e-oracle,e2e-db2
Para ejecutar todas las pruebas de integración de un extremo a otro, también se proporciona una etiqueta de acceso directo:
$ ./mvnw clean install -Dtest.tags=e2e
Para ejecutar todas las pruebas para todas las combinaciones de fuente/sumidero:
$ ./mvnw clean install -Dtest.tags=all
La comunidad Debezium da la bienvenida a cualquiera que quiera ayudar de cualquier manera, ya sea informando problemas, ayudando con la documentación o contribuyendo con cambios de código para corregir errores, agregar pruebas o implementar nuevas funciones. Consulte este documento para obtener más detalles.
¡Muchas gracias a todos los contribuyentes del receptor Debezium JDBC!
Este proyecto tiene la licencia Apache, versión 2.
