How to improve MySQL performance even with Handler Socket with replication to in-memory Tarantool
summary
Claims a replicator from MySQL to Tarantool that replaces HandlerSocket and yields ~6–7× faster responses by moving hot working set into an in‑memory Tarantool cluster. It requires row‑based binlogs, one replicator per slave, and only supports Oracle/Percona MySQL (not MariaDB). Replicator does row‑level filtering (replicate selected rows and tables), supports a cold‑start sync, and on production replaces 10 HandlerSocket MySQL services with 2 Tarantool nodes, cutting replicated footprint from ~200 GB to ~20 GB while handling 10–50K rps.
AI-written summary · about
chapters (15)
- 0:00Introduction
- 0:21What is Tarantool
- 2:09HandlerSocket to Tarantool
- 3:56MySQL-Tarantool replicator
- 5:26Replicator features
- 7:23Caching not solution
- 8:09Tarantool vs HandlerSocket
- 9:41Tarantool not reinventing
- 10:51Replicating specific rows
- 11:57Results with Tarantool
- 12:42Tarantool advantages
- 13:26Tarantool community
- 14:29Backup in Tarantool
- 14:50Tarantool limitations
- 15:10Q&A
related talks
23mReplication Across Different Database Engines
51mReplication in Tarantool: Configuration and Usage
39mHow we sped up MySQL Handler Socket ninefold
59mReplication in Tarantool: Configuration and Usage
44mThe Evolution of Replication in Tarantool
35mMySQL HA, Recovery and Load Balancing
54mArchitecture of a Reliable In-MemorDBMS: the Tarantool Example
53mMySQL DevOps