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.
287
The Drizzle kernel handles delivering replication messages to plugins by
288
maintaining a list of replication streams. A stream is represented as a
289
registered *replicator* and *applier* pair.
291
When a replication message is generated within the kernel, the replication
292
services module of the kernel will send this message to each registered
293
*replicator*. The *replicator* will then do something useful with it and
294
send it to each *applier* with which it is associated.
299
A registered *replicator* is a plugin that implements the TransactionReplicator
300
API. Each replicator will be plugged into the kernel to receive the Google
301
Protobuf messages that are generated as the database is changed. Ideally,
302
each registered replicator will transform or modify the messages it receives
303
to implement a specific behavior. For example, filtering by schema name.
305
Each registered replicator should have a unique name. The default replicator,
306
cleverly named **default_replicator**, does no transformation at all on the
307
replication messages.
312
A registered *applier* is a plugin that implements the TransactionApplier
313
API. Appliers are responsible for applying the replication messages that it
314
will receive from a registered replicator. The word "apply" is used loosely
315
here. An applier may do anything with the replication messages that provides
316
useful behavior. For example, an applier may simply write the messages to a
317
file on disk, or it may send the messages over the network to some other
318
service to be processed.
320
At the point of registration with the Drizzle kernel, each applier specifies
321
the name of a registered replicator that it should be attached to in order to
322
make the replication stream pair.
added
removed
docs/replication.rst
