14.18.6 Using the InnoDB memcached Plugin with Replication

Because the InnoDB memcached daemon plugin supports the MySQL binary log, any updates made on a master server through the memcached interface can be replicated for backup, balancing intensive read workloads, and high availability. All memcached commands are supported for binlogging.

You do not need to set up the InnoDB memcached plugin on the slave servers. In this configuration, the primary advantage is increased write throughput on the master. The speed of the replication mechanism is not affected.

The following sections show how to use the binlog capability, to use the InnoDB memcached plugin along with MySQL replication. It assumes you have already done the basic setup described in Section 14.18.3, “Getting Started with InnoDB Memcached Plugin”.

Enable InnoDB Memcached Binary Log with innodb_api_enable_binlog:

Test with the memcached telnet Interface

To test the server with the above replication setup, we use the memcached telnet interface, and also query the master and slave servers using SQL to verify the results.

In our configuration setup SQL, one example table demo_test is created in the test database for use by memcached. We will use this default table for the demonstrations:

In the master server, you can see that the row is inserted. c1 maps to the key, c2 maps to the value, c3 is the flag, c4 is the cas value, and c5 is the expiration.


mysql> select * from test.demo_test;

c1c2c3c4c5
test1t11020
1 row in set (0.00 sec)

In the slave server, you will see the same record is inserted by replication:


mysql> select * from test.demo_test;

c1c2c3c4c5
test1t11020
1 row in set (0.00 sec)
Connected to 127.0.0.1.
Escape character is '^]'.
set test1 10 0 3
new
STORED

From the slave server, the update is replicated (notice the cas value also updated):


mysql> select * from test.demo_test;

c1c2c3c4c5
test1new1030
1 row in set (0.00 sec)
Connected to 127.0.0.1.
Escape character is '^]'.
delete test1
DELETED

When the delete is replicated to the slave, the record on the slave is also deleted:


mysql> select * from test.demo_test;
Empty set (0.00 sec)

First, insert two records by telnetting to the master server:

Connected to 127.0.0.1.
Escape character is '^]'
set test2 10 0 5
again
STORED
set test3 10 0 6
again1
STORED

In the slave server, confirm these two records are replicated:


mysql> select * from test.demo_test;

c1c2c3c4c5
test2again1050
test3again11060
2 rows in set (0.00 sec)

Call flush_all in the telnet interface to truncate the table:

Connected to 127.0.0.1.
Escape character is '^]'.
flush_all
OK

Then check that the truncation operation is replicated on the slave server:


mysql> select * from test.demo_test;
Empty set (0.00 sec)

All memcached commands are supported in terms of replication.

Notes for the InnoDB Memcached Binlog

Binlog Format:

Transactions: