1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
|
Replication Slave
=================
Description
-----------
The replication slave plugin provides a native implementation of replication
between two Drizzle processes.
This plugin requires a master that is running with the InnoDB replication log
enabled.
Configuration
-------------
Most of the options that can be used to control the replication slave plugin
can only be given in a configuration file. The only exceptions are the
:option:`--slave.config-file` and :option:`--slave.max-commit-id` options.
.. program:: drizzled
.. option:: --slave.config-file=arg
Path to the replication slave configuration file. By default, the
plugin will look for a file named `slave.cfg` in the `etc` directory
of the Drizzle installation. If you want to specify a different path or
configuration file name, it is best to specify a full path to the
file. The relative path used by plugins is within the :option:`--datadir`
directory, so a full path is recommended.
.. option:: --slave.max-commit-id=arg
Manually set the maximum commit ID the slave is assumed to have retrieved
from the master. This value will be used by the slave to determine where
to begin retrieving replication messages from the master transaction log.
This option can be used to provision a new slave machine by setting it to
the value output from the drizzledump client when used with the
--single-transaction option.
This value is not allowed to be set via the configuration file since
you would normally only set it once on initial slave startup. This
eliminates the possibility of forgetting to delete it from the configuration
file for subsequent slave restarts.
The options below are read from the configuration file.
.. confval:: master-host
Hostname/IP address of the master server.
.. confval:: master-port
Drizzle port used by the master server. Default is 3306.
.. confval:: master-user
Username to use for connecting to the master server.
.. confval:: master-pass
Password associated with the username given by :confval:`master-user`.
.. confval:: max-reconnects
The number of reconnection attempts the slave plugin will try if the
master server becomes unreachable. Default is 10.
.. confval:: seconds-between-reconnects
The number of seconds to wait between reconnect attempts when the master
server becomes unreachable. Default is 30.
.. confval:: io-thread-sleep
The number of seconds the IO (producer) thread sleeps between queries to the
master for more replication events. Default is 5.
.. confval:: applier-thread-sleep
The number of seconds the applier (consumer) thread sleeps between applying
replication events from the local queue. Default is 5.
Implementation Details
----------------------
The replication slave plugin creates two worker threads, each accessing a
work queue (implemented as an InnoDB table) that contains the replication
events. This is a producer/consumer paradigm where one thread populates the
queue (the producer), and the other thread (the consumer) reads events from
the queue.
The producer thread (or I/O thread) is in charge of connecting to the master
server and pulling down replication events from the master's transaction
log and storing them locally in the slave queue. It is required that the
master use the InnoDB replication log (:option:`--innodb.replication-log <drizzled --innodb.replication-log>`).
The consumer thread (or applier thread) reads the replication events from
the local slave queue, applies them locally, and then deletes successfully
applied events from the queue.
Schemas and Tables
------------------
The slave plugin creates its own schema and set of tables to store its
metadata. It stores everything in the **sys_replication** schema. The
following are the tables that it will create:
.. dbtable:: sys_replication.io_state
Stores metadata about the IO/producer thread.
.. dbtable:: sys_replication.applier_state
Stores metadata about the applier/consumer thread.
.. dbtable:: sys_replication.queue
The replication event queue.
|