A newer version of this documentation is available.
View Latest (v2.0)

Gluesync for MySQL

Gluesync SQL to NoSQL for MySQL

Core principles

Gluesync uses GDC (Gluesync Data Capture) feature to let the magic happen under the hood, more specifically Gluesync adopts an optimized triggers structure in order to catch events generated by operations that hit fields in your source MySQL database.

Triggers on GDC are based on a per-transaction logic and only tracking changed rows IDs, storing data on a table called Action logs table where all changed row IDs are stored and their data type maintained unaltered.

This technique is also kwown as change tracking pattern. Which in the opposite of change data capture does not require a copy of all the data present in all the columns involved in a commit, this ensure performance gain and less footprint per each transaction on your source database since no data transformation or manipulation is being required by our design.

We’re working on supporting native CDC capabilities for MySQL. If you’re interest on knowing more about it please reach out to us.

Architectural overview

Here in the following diagram is represented an architectural overview of the environment you are going to have after having deployed Gluesync.

a diagram illustrating the architectural overview of Gluesync for MariaDB

Q&A

I have got MySQL running under a managed DBaaS offered from AWS | CGP | Azure | OCI | …​, is it supported? Since we opted for GDC in order to catch field-level changes from your MySQL instance this gives you the ability to work with whatever deployment / flavor of MySQL you might have.

For a list of suppored versions have a look at our list of supported databases / versions available here.

Having further questions? For more information regarding Gluesync please reach us via email by pressing here: Contact MOLO17.