Go to connections and create a new connection. Then, select the existing MySQL source you have just created and then do the same for the Local JSON destination. Once you're done, you can set up the connection as follows.
As you can see, I set the replication frequency to manual so I can trigger synchronization on demand. You can change the replication frequency, later on, to sync as frequently as every 5 minutes .
Then, it's time to configure the streams , which in this case are the tables in your database. For now, you only have the cars table. If you expand it, you can see the columns it has.
Now, you should select a sync mode. If you want to take full advantage of performing MySQL CDC, you should use Incremental | Append mode to only look at the rows that have changed in the source and sync them to the destination. Selecting a Full Refresh mode would sync the whole source table, which is most likely not what you want when using CDC. Learn more about sync modes in our documentation .
When using an Incremental sync mode, you would generally need to provide a Cursor field , but when using CDC, that's not necessary since the changes in the source are detected via the Debezium connector stream.
Once you're ready, save the changes. Then, you can run your first sync by clicking on Sync now . You can check your run logs to verify everything is going well. Just wait for the sync to be completed, and that's it! You've replicated data from MySQL using CDC.
Step 6: Verify that the sync worked Step 7: Test CDC in action by creating and deleting an object from the database Now, let's test the MySQL CDC setup you have configured. To do that, run the following queries to insert and delete a row from the database.
INSERT INTO cars VALUES(3, 'tesla');DELETE FROM cars WHERE NAME = 'tesla';
Launch a sync and, once it finishes, check the local JSON file to verify that CDC has captured the change. The JSON file should now have two new lines, showing the addition and deletion of the row from the database.
CDC allows you to see that a row was deleted, which would be impossible to detect when using the regular Incremental sync mode. The _ab_cdc_deleted_at meta field not being null means id=3 was deleted.
From the root directory of the Airbyte project, go to tmp/airbyte_local/json_data/ , and you will find a file named _airbyte_raw_cars.jsonl where the data from the MySQL database was replicated.
You can check the file's contents in your preferred IDE or run the following command.
cat _airbyte_raw_cars.jsonl
Wrapping up In this tutorial, you have learned what the MySQL binlog is and how Airbyte reads it to implement log-based Change Data Capture (CDC). In addition, you have learned how to configure an Airbyte connection between a MySQL database and a local JSON file.
Delve deeper into streamlining your data workflows by exploring our comprehensive article on migrating from MySQL to PostgreSQL using Airbyte. Gain insights into leveraging log-based Change Data Capture (CDC) and configuring Airbyte connections for near real-time ELT pipelines, extending your capabilities to seamlessly integrate with various databases, data warehouses, or data lakes.
To learn more, you can check out our comprehensive article on Salesforce CDC and discover how this setup can be leveraged to create a near real-time ELT pipeline, extending the capabilities of CDC into various data destinations!
If you found Airbyte helpful, you might want to check our fully managed solution: Airbyte Cloud . We also invite you to join the conversation on our community Slack Channel to share your ideas with thousands of data engineers and help make everyone’s project a success!
MySQL