280
280
a single statement, then a message buffering strategy should be employed
281
281
to guarantee that a statement was indeed applied successfully before
282
282
executing on the receiver.
284
.. _replication_streams:
289
The Drizzle kernel handles delivering replication messages to plugins by
290
maintaining a list of replication streams. A stream is represented as a
291
registered *replicator* and *applier* pair.
293
When a replication message is generated within the kernel, the replication
294
services module of the kernel will send this message to each registered
295
*replicator*. The *replicator* will then do something useful with it and
296
send it to each *applier* with which it is associated.
301
A registered *replicator* is a plugin that implements the TransactionReplicator
302
API. Each replicator will be plugged into the kernel to receive the Google
303
Protobuf messages that are generated as the database is changed. Ideally,
304
each registered replicator will transform or modify the messages it receives
305
to implement a specific behavior. For example, filtering by schema name.
307
Each registered replicator should have a unique name. The default replicator,
308
cleverly named **default_replicator**, does no transformation at all on the
309
replication messages.
314
A registered *applier* is a plugin that implements the TransactionApplier
315
API. Appliers are responsible for applying the replication messages that it
316
will receive from a registered replicator. The word "apply" is used loosely
317
here. An applier may do anything with the replication messages that provides
318
useful behavior. For example, an applier may simply write the messages to a
319
file on disk, or it may send the messages over the network to some other
320
service to be processed.
322
At the point of registration with the Drizzle kernel, each applier specifies
323
the name of a registered replicator that it should be attached to in order to
324
make the replication stream pair.
added
removed
docs/replication.rst
