InnoDB Memcached Plugin: Architecture, Performance Comparison, Configuration, and High Availability

The InnoDB Memcached Plugin (IMC) embeds a memcached daemon inside MySQL, allowing direct set and get operations on InnoDB tables, thus eliminating SQL parsing overhead and removing the memory‑size limitation of pure memcached.

1. Background

Typical architectures add an external cache (memcached or Redis) between the application and the database to reduce latency, but they require the application to maintain data consistency and can become costly when the cached data exceeds available memory. In the security center, data grew to nearly 100 GB, making Redis unsuitable, prompting the evaluation of IMC.

2. Comparison with Existing Storage Solutions

Qunar’s DBA team uses three storage options: HBase (large‑scale, high latency), MySQL (general purpose), and Redis (in‑memory cache). Performance tests were conducted on a client machine (2.7 GHz i5, 8 GB RAM, macOS 10.13.1) against a server (HP DL360 Gen9, 32 CPU cores, 126 GB RAM, CentOS 7.2) with the following configurations:

InnoDB buffer pool: 24 GB

Memcached memory: 16 GB

Read‑only, write‑only, and mixed (9:1 read/write) benchmarks were run with key size 32 bytes and value size 128 bytes. Results showed that IMC’s read QPS was about 50 % higher than MySQL, while write performance was comparable. Redis achieved higher write throughput but suffered from memory cost and capacity limits.

Redis Benchmark Example

# Operation count 1,000,000, value size 1024 bytes
redis-benchmark -n 1000000 -d 1024

Sample Redis output:

====== SET ======
1000000 requests completed in 9.59 seconds
50 parallel clients
100.00 % <= 0 milliseconds
104231.81 requests per second

====== GET ======
1000000 requests completed in 8.83 seconds
50 parallel clients
100.00 % <= 0 milliseconds
113237.45 requests per second

3. Using InnoDB Memcached

3.1 Installation

# Initialize daemon_memcached plugin
source MYSQL_HOME/share/innodb_memcached_config.sql

# Install plugin
INSTALL PLUGIN daemon_memcached SONAME "libmemcached.so";

After installation, you can connect via telnet to port 11211 and issue memcached commands such as:

# Get value for key AA in tablespace aaa
get @aaa.AA

3.2 Configuration Tables

Three tables are created in the innodb_memcache database: cache_policies , config_options , and containers . They control storage policies, option settings, and the mapping between memcached keys and InnoDB tables.

Example query of cache_policies :

SELECT * FROM cache_policies\G;

Typical rows:

policy_name: cache_policy
get_policy: innodb_only
set_policy: innodb_only
delete_policy: innodb_only
flush_policy: innodb_only

Example of containers mapping:

name: aaa
 db_schema: test
 db_table: demo_test
 key_columns: c1
 value_columns: c2
 flags: c3
 cas_column: c4
 expire_time_column: c5
 unique_idx_name_on_key: PRIMARY

Example of config_options :

name          | value
--------------+-------
separator     | 
 table_map_delimiter | .

After modifying these tables, the plugin must be reinstalled:

UNINSTALL PLUGIN daemon_memcached;
INSTALL PLUGIN daemon_memcached SONAME "libmemcached.so";

3.3 Performance Tests

Using memslap and the same server configuration as in section 2, the following tests were performed:

100 % SET: key 20 bytes, value 1024 bytes

100 % GET (cold and warm InnoDB buffer)

Mixed read/write (9:1) for the security‑center workload

Results indicated that the cache_only policy outperforms traditional memcached, while caching and innodb_only policies provide high QPS with acceptable latency, making IMC suitable for scenarios where cache capacity is insufficient but relational‑database response time is required.

4. High Availability

By enabling innodb_api_enable_binlog=1 , IMC writes generate binlogs, allowing MySQL replication for backup and HA. The HA architecture mirrors Qunar’s QMHA design: one master node providing memcached service, one or more slave nodes for failover, and a sentinel cluster of five nodes monitoring MySQL status. If a majority detects a failure, the sentinel updates ZooKeeper, and Java clients switch to the new master. Switchover takes ~2 seconds; failover ~9 seconds.

Overall, IMC offers a middle ground between MySQL and Redis, delivering higher read performance than MySQL, larger storage capacity than Redis, and acceptable write latency, making it ideal for large‑scale, read‑heavy, latency‑sensitive applications.