← Back to branch summary

~ubuntu-branches/ubuntu/saucy/drizzle/saucy-proposed

« back to all changes in this revision

Viewing changes to docs/plugins/slave/admin.rst

  • Committer: Package Import Robot
  • Author(s): Clint Byrum
  • Date: 2012-06-19 10:46:49 UTC
  • mfrom: (1.1.6)
  • mto: This revision was merged to the branch mainline in revision 29.
  • Revision ID: package-import@ubuntu.com-20120619104649-e2l0ggd4oz3um0f4
Tags: upstream-7.1.36-stable
Import upstream version 7.1.36-stable

Show diffs side-by-side

added added

removed removed

Lines of Context:
docs/plugins/slave/admin.rst
1
 
********************************
2
 
Replication Slave Administration
3
 
********************************
4
 
 
5
 
This page walks you through some common administration tasks when using
6
 
the replication slave plugin.
7
 
 
8
 
Monitoring the Master
9
 
#####################
10
 
 
11
 
Slave Connections
12
 
*****************
13
 
 
14
 
If you want to determine which slave machines are connected to your
15
 
master, use the *SHOW PROCESSLIST* command. Slave connections will show
16
 
up in the output of this command.
17
 
 
18
 
InnoDB Transaction Log
19
 
**********************
20
 
 
21
 
The slave plugin uses the InnoDB transaction log (see
22
 
:ref:`innodb_transaction_log`) on the master to retrieve replication
23
 
messages. This transaction log, though stored as an internal table within
24
 
InnoDB, offers two different views to the table contents. Two tables in
25
 
the DATA_DICTIONARY schema provide the different views into the transaction
26
 
log: the SYS_REPLICATION_LOG table and the INNODB_REPLICATION_LOG table.
27
 
 
28
 
The SYS_REPLICATION_LOG table is read directly by the slave plugin.
29
 
This table is described as below::
30
 
 
31
 
  drizzle> SHOW CREATE TABLE data_dictionary.sys_replication_log\G
32
 
  *************************** 1. row ***************************
33
 
         Table: SYS_REPLICATION_LOG
34
 
  Create Table: CREATE TABLE `SYS_REPLICATION_LOG` (
35
 
    `ID` BIGINT,
36
 
    `SEGID` INT,
37
 
    `COMMIT_ID` BIGINT,
38
 
    `END_TIMESTAMP` BIGINT,
39
 
    `MESSAGE_LEN` INT,
40
 
    `MESSAGE` BLOB,
41
 
    PRIMARY KEY (`ID`,`SEGID`) USING BTREE,
42
 
    KEY `COMMIT_IDX` (`COMMIT_ID`,`ID`) USING BTREE
43
 
  ) ENGINE=InnoDB COLLATE = binary
44
 
 
45
 
The INNODB_REPLICATION_LOG is similar to the SYS_REPLICATION_LOG, the
46
 
main difference being that the Google Protobuffer message representing
47
 
the changed rows is converted to plain text before being output::
48
 
 
49
 
  drizzle> SHOW CREATE TABLE data_dictionary.innodb_replication_log\G
50
 
  *************************** 1. row ***************************
51
 
         Table: INNODB_REPLICATION_LOG
52
 
  Create Table: CREATE TABLE `INNODB_REPLICATION_LOG` (
53
 
    `TRANSACTION_ID` BIGINT NOT NULL,
54
 
    `TRANSACTION_SEGMENT_ID` BIGINT NOT NULL,
55
 
    `COMMIT_ID` BIGINT NOT NULL,
56
 
    `END_TIMESTAMP` BIGINT NOT NULL,
57
 
    `TRANSACTION_MESSAGE_STRING` TEXT COLLATE utf8_general_ci NOT NULL,
58
 
    `TRANSACTION_LENGTH` BIGINT NOT NULL
59
 
  ) ENGINE=FunctionEngine COLLATE = utf8_general_ci REPLICATE = FALSE
60
 
 
61
 
The INNODB_REPLICATION_LOG table is read-only due to the way it is
62
 
implemented. The SYS_REPLICATION_LOG table, on the other hand, allows you
63
 
to modify the contents of the transaction log. You would use this table
64
 
to trim the transaction log.
65
 
 
66
 
Monitoring the Slave
67
 
####################
68
 
 
69
 
The slave plugin has two types of threads doing all of the work:
70
 
 
71
 
* An IO (or producer) thread
72
 
* An applier (or consumer) thread
73
 
 
74
 
The status of each thread is stored in tables in the *sys_replication*
75
 
schema. The IO thread status is contained in the *io_state* table, and
76
 
the applier thread status is in the *applier_state* table. You may query
77
 
these tables just like any other table. For example::
78
 
 
79
 
  drizzle> SELECT * FROM sys_replication.io_state\G
80
 
  *************************** 1. row ***************************
81
 
     status: RUNNING
82
 
  error_msg: 
83
 
 
84
 
The above shows that the IO thread is **RUNNING**. If there had been
85
 
an error on the IO thread, the status value would be **STOPPED** and
86
 
the error_msg column would contain information about the error.
87
 
 
88
 
We can check the state of the applier thread in a similar manner::
89
 
 
90
 
  drizzle> SELECT * FROM sys_replication.applier_state\G
91
 
  *************************** 1. row ***************************
92
 
  last_applied_commit_id: 4
93
 
                  status: RUNNING
94
 
               error_msg: 
95
 
 
96
 
The status and error_msg columns are similar to the ones in the *io_state*
97
 
table. Also available is the last_applied_commit_id, which contains the
98
 
value of the COMMIT_ID from the master's replication log (see definition
99
 
of the data_dictionary.sys_replication_log table above) of the most
100
 
recently executed transaction.
101
 
 
102
 
Transaction Log Maintenance
103
 
###########################
104
 
 
105
 
Currently, the InnoDB transaction log grows without bounds and is never
106
 
trimmed of unneeded entries. This can present a problem for long running
107
 
replication setups. You may trim the log manually, but you must make certain
108
 
to not remove any entries that are needed by slave servers.
109
 
 
110
 
Follow these steps to trim the InnoDB transaction without affecting slave
111
 
function:
112
 
 
113
 
#. Query each slave for the *last_applied_commit_id* value from the *sys_replication.applier_state* table.
114
 
#. Choose the **minimum** value obtained from step one. This will be the marker for the slave that is the furthest behind the master.
115
 
#. Using this marker value from the previous step, delete all entries from the master's transaction log that has a COMMIT_ID less than the marker value.
116
 
 
117
 
Below is an example of the steps defined above. First, step 1 and 2. Assume
118
 
that we have two slave hosts connected to the master (slave-1 and slave-2).
119
 
We need to query both to check their relationship with the master transaction
120
 
log::
121
 
 
122
 
  slave-1> SELECT last_applied_commit_id FROM sys_replication.applier_state\G
123
 
  *************************** 1. row ***************************
124
 
  last_applied_commit_id: 3000
125
 
 
126
 
  slave-2> SELECT last_applied_commit_id FROM sys_replication.applier_state\G
127
 
  *************************** 1. row ***************************
128
 
  last_applied_commit_id: 2877
129
 
 
130
 
We see that slave-2 has the smallest value for *last_applied_commit_id*. We
131
 
will use this value in the next step to trim the transaction log on the
132
 
master::
133
 
 
134
 
  master> DELETE FROM data_dictionary.sys_replication_log WHERE commit_id < 2877;
135
 
 
136
 
This will remove all old, unneeded entries from the InnoDB transaction log. Note that the SYS_REPLICATION_LOG table is used for this maintenance task.