drizzle
Profile
Search
 
Hosted by The Rackspace Cloud
Replication

This page serves to document ongoing design and development of the Drizzle pluggable replication system

Contents

Goals of the Replication System

There are only two major goals of the replication system as a whole. They are:

Some may ask, "Well, shouldn't performance be a goal?" or "What about synchronous replication!?". No, neither of these are central to the goals of the replication system as a whole, though performance or synchronous replication may certainly be laudable goals of a specific module's implementation of replication internals. By focusing on making plugin/module developers lives easier (via simplicity of the API), we can further the targeted implementation goals of those modules.

Use Cases of Replication

Look here for discussion of Replication Use Cases.

Command GPB messages

At the core of the replication system API is the Command message. This is a Google Protobuffer Message class and is exchanged between the kernel and replication modules. The Command message describes an event which occurred inside the kernel in regards to a changing of storage data or data definitions (DML and DDL statements).

The Command message is passed to the various Replicator, Applier, and Reader Plugin APIs and is the "currency" exchanged between Publisher and Subscriber modules.

Command message proto

As always, to see the most up-to-date version of the Command message format, see the definition in /drizzled/message/transaction.proto. Over time, the format of the message may change slightly by adding optional members to the message.

The TransactionContext sub-message

Each Command message is guaranteed to have a TransactionContext submessage which defines some valuable information about the command itself.


The Command type

Sub-commands and How to Use Them

Replicator

Applier

Reader

Publisher

Subscriber

Flow of Events Through Kernel to Replication Plugins