14.20.6 The InnoDB memcached Plugin and Replication

Because the daemon_memcached plugin supports
the MySQL binary log,
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 with binary logging.

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

Enabling the InnoDB memcached Binary Log

To use the daemon_memcached plugin with
the MySQL binary log,
enable the
innodb_api_enable_binlog
configuration option on the
master server.
This option can only be set at server startup. You must also
enable the MySQL binary log on the master server using the
--log-bin option. You can
add these options to the MySQL configuration file, or on the
mysqld command line.

Testing the InnoDB memcached Replication Configuration

This example demonstrates how to test the
InnoDBmemcached
replication configuration using the memcached
and telnet to insert, update, and delete data. A MySQL client is
used to verify results on the master and slave servers.

The example uses the demo_test table, which
was created by the
innodb_memcached_config.sql configuration
script during the initial setup of the
daemon_memcached plugin. The
demo_test table contains a single example
record.

Use the set command to insert a record
with a key of test1, a flag value of
10, an expiration value of
0, a cas value of 1, and a value of
t1.

On the master server, check that the record was inserted
into the demo_test table. Assuming the
demo_test table was not previously
modified, there should be two records. The example record
with a key of AA, and the record you just
inserted, with a key of test1. The
c1 column maps to the key, the
c2 column to the value, the
c3 column to the flag value, the
c4 column to the cas value, and the
c5 column to the expiration time. The
expiration time was set to 0, since it is unused.

Check to ensure that the flush_all
operation was replicated on the slave server.

mysql> SELECT * FROM test.demo_test;
Empty set (0.00 sec)

InnoDB memcached Binary Log Notes

Binary Log Format:

Most memcached operations are mapped to
DML statements (analogous to
insert, delete, update). Since there is no actual SQL
statement being processed by the MySQL server, all
memcached commands (except for
flush_all) use Row-Based Replication
(RBR) logging, which is independent of any server
binlog_format setting.

The memcachedflush_all command is mapped to the
TRUNCATE TABLE command. Since
DDL commands can only use
statement-based logging, the flush_all
command is replicated by sending a
TRUNCATE TABLE statement.

Transactions:

The concept of
transactions has not
typically been part of memcached
applications. For performance considerations,
daemon_memcached_r_batch_size
and
daemon_memcached_w_batch_size
are used to control the batch size for read and write
transactions. These settings do not affect replication. Each
SQL operation on the underlying InnoDB
table is replicated after successful completion.

The default value of
daemon_memcached_w_batch_size
is 1, which means that each
memcached write operation is committed
immediately. This default setting incurs a certain amount of
performance overhead to avoid inconsistencies in the data
that is visible on the master and slave servers. The
replicated records are always available immediately on the
slave server. If you set
daemon_memcached_w_batch_size
to a value greater than 1, records
inserted or updated through memcached are
not immediately visible on the master server; to view the
records on the master server before they are committed,
issue SET
TRANSACTION ISOLATION LEVEL READ UNCOMMITTED.