DPTCloud
Back to articles
Technology Insight

Building a Lightweight CDC Pipeline: Syncing MySQL to Meilisearch with Debezium

May 30, 2026

Introduction to Real-Time Search Synchronization

In modern enterprise application development, providing users with a fast, relevant, and intuitive search experience is paramount. While relational databases like MySQL excel at transactional processing (OLTP) and maintaining relational integrity, they are inherently poorly optimized for complex, full-text search operations. Forcing MySQL to execute heavy LIKE queries or full-text indexes under high traffic invariably leads to CPU spikes, slow response times, and a degraded user experience.

To solve this, architectural best practices dictate offloading search workloads to a dedicated search engine. Meilisearch has emerged as a premier choice for this role, offering an open-source, lightning-fast, and highly relevant search experience out of the box. However, introducing a dedicated search engine introduces a critical challenge: How do we synchronize data from our primary MySQL database to Meilisearch in real time without degrading application performance?

Traditional approaches rely on dual-writing from the application layer or running scheduled cron jobs. Dual-writing introduces tight coupling and data inconsistency risks during network partitions, while cron jobs introduce unacceptable latency. The definitive solution to this problem is Change Data Capture (CDC). In this comprehensive guide, we will explore how to build a ultra-lightweight CDC pipeline from MySQL to Meilisearch using Debezium Server, completely bypassing the resource overhead of a traditional Apache Kafka deployment.

Understanding the Architectural Components

Before diving into the implementation details, it is essential to understand the roles of each component in our ultra-lightweight architecture and why this specific combination delivers high performance with minimal infrastructure footprint.

MySQL and the Binary Log (Binlog)

MySQL tracks all data modifications (INSERTs, UPDATEs, DELETEs) in a sequential log known as the Binary Log (Binlog). Instead of querying the database tables directly and creating read lock contention, a CDC tool can stream events directly from the Binlog. This approach is non-invasive, asynchronous, and imposes near-zero overhead on the primary database engine.

Debezium Server: Kafka-less CDC

Historically, Debezium required a full Apache Kafka and Kafka Connect cluster to operate. While Kafka provides unmatched scalability, its infrastructure footprint—requiring ZooKeeper or KRaft, multiple brokers, and substantial memory allocation—is often overkill for simple point-to-point data synchronization.

Debezium Server is a standalone, lightweight alternative. It wraps the core Debezium connectors into a single Quarkus-based application that can read changes from a source database and emit them directly to various cloud infrastructure and alternative messaging systems, or process them via custom HTTP sinks, making the entire pipeline highly cost-effective and simple to manage.

Meilisearch: Developer-First Full-Text Search

Meilisearch is a RESTful search engine designed for instant, typo-tolerant search experiences. Unlike Elasticsearch, which is powerful but resource-heavy and complex to configure, Meilisearch is lightweight, starts in seconds, and provides intuitive relevancy rules natively. By pairing Debezium's sub-second event streaming with Meilisearch's rapid indexing, we achieve a highly responsive search architecture.

Step-by-Step Implementation Guide

Let us walk through the practical configuration required to establish this lightweight synchronization pipeline. We assume a containerized environment utilizing Docker for ease of deployment.

Step 1: Configuring MySQL for CDC

To allow Debezium to read database events, you must ensure that row-based logging is enabled in your MySQL configuration (my.cnf or mysqld.cnf). Modify your database configuration file to include the following parameters:

[mysqld]
server-id         = 223344
log_bin           = mysql-bin
binlog_format     = ROW
binlog_row_image  = FULL
expire_logs_days  = 7

After updating the configuration, restart your MySQL service. Next, create a dedicated database user for Debezium with the minimal required privileges to read the replication stream:

CREATE USER 'debezium'@'%' IDENTIFIED BY 'dbz_password_2026';
GRANT SELECT, RELOAD, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'debezium'@'%';
FLUSH PRIVILEGES;

Step 2: Initializing Meilisearch

Deploying Meilisearch is straightforward. Ensure you secure your production instance with a master key. Spin up the service using Docker:

docker run -d -p 7700:7700 \
  -v $(pwd)/meili_data:/meili_data \
  -e MEILI_MASTER_KEY="your_secure_master_key_2026" \
  getmeili/meilisearch:v1.x

Create your destination index (e.g., products) via a simple HTTP POST request using cURL or an API client like Postman, ensuring you define the primary key attribute expected from your MySQL table:

curl -X POST 'http://localhost:7700/indexes' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer your_secure_master_key_2026' \
  --data-binary '{ "uid": "products", "primaryKey": "id" }'

Step 3: Configuring Debezium Server with an HTTP Sink

Because Debezium Server does not feature a native Meilisearch sink connector out of the box, we utilize Debezium Server's flexible HTTP Sink. This sink transforms database change events into JSON payloads and dispatches them to a specified HTTP endpoint. To handle the format translation between Debezium's standard CDC format and Meilisearch's document format, we can route the data through a lightweight webhook proxy or leverage Debezium's internal Single Message Transformations (SMT).

Create an application.properties configuration file for Debezium Server:

debezium.sink.type=http
debezium.sink.http.url=http://meilisearch-proxy:8080/sync
debezium.source.connector.class=io.debezium.connector.mysql.MySqlConnector
debezium.source.offset.storage.file.filename=data/offsets.dat

# Source Database Connection Settings
debezium.source.database.hostname=mysql-server
debezium.source.database.port=3306
debezium.source.database.user=debezium
debezium.source.database.password=dbz_password_2026
debezium.source.database.server.id=223344
debezium.source.database.server.name=mysql_cdc
debezium.source.database.include.list=ecommerce_db
debezium.source.table.include.list=ecommerce_db.products

# Transformations to Flatten Payload
debezium.source.transforms=unwrap
debezium.source.transforms.unwrap.type=io.debezium.transforms.ExtractNewRecordState
debezium.source.transforms.unwrap.drop.tombstones=false
Note: The ExtractNewRecordState SMT (unwrap) is vital. It strips away Debezium's metadata envelope, providing Meilisearch with a clean, flat JSON representation of the database row directly.

Optimizing the Pipeline for Production

Deploying a pipeline to production requires careful planning around edge cases, failure recovery, and performance tuning.

  • Handling Deletions: When a row is deleted in MySQL, Debezium emits a tombstone event with a null value. Ensure your middleware proxy captures these events and issues a corresponding DELETE request to the Meilisearch endpoint (/indexes/products/documents/{id}) to remove the stale search document.
  • Network Idempotency: Because network glitches can cause event retries, ensure your Meilisearch documents use the database's primary key as their immutable id field. This ensures that processing the same insert event twice results in an idempotent update rather than duplicated data.
  • Memory Management: Monitor the JVM memory settings of your Debezium Server. Since it runs on Quarkus, its footprint is small (often under 150MB of RAM), but heavy database transactions may require adjusting heap limits via environment variables.

Conclusion

By bypassing the complexity of Apache Kafka and utilizing Debezium Server coupled with Meilisearch, we have engineered an ultra-lightweight, reactive, and highly cost-efficient search synchronization pipeline. This architecture ensures your user-facing search indices reflect transactional database states in sub-seconds, without compromising the performance of your primary core application services. Implement this architecture today to achieve enterprise-grade real-time search capabilities on a startup budget.

Building a Lightweight CDC Pipeline: Syncing MySQL to Meilisearch with Debezium | DPTCloud