|
2116.1.53
by David Shrewsbury
Add basic plugin documentation |
1 |
Replication Slave
|
2 |
=================
|
|
3 |
||
4 |
Description
|
|
5 |
-----------
|
|
6 |
||
7 |
The replication slave plugin provides a native implementation of replication |
|
8 |
between two Drizzle processes. |
|
9 |
||
10 |
This plugin requires a master that is running with the InnoDB replication log |
|
11 |
enabled. |
|
12 |
||
13 |
Configuration
|
|
14 |
-------------
|
|
15 |
||
16 |
Most of the options that can be used to control the replication slave plugin |
|
17 |
can only be given in a configuration file. The only exception is the |
|
18 |
**config-file** option which designates the location of this configuration
|
|
19 |
file. |
|
20 |
||
21 |
**slave.config-file**
|
|
22 |
||
23 |
Path to the replication slave configuration file. |
|
24 |
||
25 |
The options below are read from the configuration file. |
|
26 |
||
27 |
**master-host**
|
|
28 |
||
29 |
Hostname/IP address of the master server. |
|
30 |
||
31 |
**master-port**
|
|
32 |
||
33 |
Drizzle port used by the master server. Default is 3306. |
|
34 |
||
35 |
**master-user**
|
|
36 |
||
37 |
Username to use for connecting to the master server. |
|
38 |
||
39 |
**master-pass**
|
|
40 |
||
41 |
Password associated with the username given by **master-user**.
|
|
42 |
||
43 |
**max-reconnects**
|
|
44 |
||
45 |
The number of reconnection attempts the slave plugin will try if the |
|
46 |
master server becomes unreachable. Default is 10. |
|
47 |
||
48 |
**seconds-between-reconnects**
|
|
49 |
||
50 |
The number of seconds to wait between reconnect attempts when the master |
|
51 |
server becomes unreachable. Default is 30. |
|
52 |
||
53 |
Implementation Details
|
|
54 |
----------------------
|
|
55 |
||
56 |
The replication slave plugin creates two worker threads, each accessing a |
|
57 |
work queue (implemented as an InnoDB table) that contains the replication |
|
58 |
events. This is a producer/consumer paradigm where one thread populates the |
|
59 |
queue (the producer), and the other thread (the consumer) reads events from |
|
60 |
the queue. |
|
61 |
||
62 |
The producer thread (or I/O thread) is in charge of connecting to the master |
|
63 |
server and pulling down replication events from the master's transaction |
|
64 |
log and storing them locally in the slave queue. It is required that the |
|
65 |
master use the InnoDB replication log (--innodb.replication-log=true). |
|
66 |
||
67 |
The consumer thread (or applier thread) reads the replication events from |
|
68 |
the local slave queue, applies them locally, and then deletes successfully |
|
69 |
applied events from the queue. |
|
70 |
||
71 |
Schemas and Tables
|
|
72 |
------------------
|
|
73 |
||
74 |
The slave plugin creates its own schema and set of tables to store its |
|
75 |
metadata. It stores everything in the **sys_replication** schema. The
|
|
76 |
following are the tables that it will create: |
|
77 |
||
78 |
**sys_replication.io_state**
|
|
79 |
||
80 |
Stores metadata about the IO/producer thread. |
|
81 |
||
82 |
**sys_replication.applier_state**
|
|
83 |
||
84 |
Stores metadata about the applier/consumer thread. |
|
85 |
||
86 |
**sys_replication.queue**
|
|
87 |
||
88 |
The replication event queue. |
|
89 |