Debezium Blog
The current pattern in application development gravitates toward microservices and microservices architecture. While this approach gives the developer teams great flexibility in terms of independent deployments and development velocity, the drawback is at hand when you try to track a bug in production. Monolithic applications sit nicely at a single place so you can introspect the code flows and the application’s runtime state. This is more challenging with microservice architectures, as a single business transaction...
I’m pleased to announce the release of Debezium 1.4.0.Beta1!
This release includes support for distributed tracing, lowercase table and schema naming for Db2, specifying MySQL snapshot records as create or read operations, and enhancements to Vitess for nullable and primary key columns.
I’m excited to announce the release of Debezium 1.4.0.Alpha2!
This second pass of the 1.4 release line provides a few useful new features:
-
New API hook for the PostgreSQL
Snapshotter
interface -
Field renaming using
ExtractNewRecordState
SMT’sadd.fields
andadd.headers
configurations
I’m excited to announce the release of Debezium 1.3.1.Final!
This release primarily focuses on bugs that were reported after the 1.3 release. Most importantly, the following bugs were fixed related to the Debezium connector for Oracle LogMiner adapter thanks to the continued feedback by the Debezium community.
This post originally appeared on the Bolt Labs Engineering blog.
Traditionally, MySQL has been used to power most of the backend services at Bolt. We’ve designed our schemas in a way that they’re sharded into different MySQL clusters. Each MySQL cluster contains a subset of data and consists of one primary and multiple replication nodes.
Once data is persisted to the database, we use the Debezium MySQL Connector to capture data change events and send them to Kafka. This gives us an easy and reliable way to communicate changes between back-end microservices.