← Back to branch summary

~drizzle-trunk/drizzle/development

« back to all changes in this revision

Viewing changes to docs/replication.rst

  • Committer: Brian Aker
  • Date: 2010-10-28 01:45:34 UTC
  • mfrom: (1878.5.8 catalogs)
  • Revision ID: brian@tangent.org-20101028014534-b6qp4wp6crj60h7k
Merge in catalog tree.

Show diffs side-by-side

added added

removed removed

Lines of Context:
docs/replication.rst
6
6
sub-messages. There is a single main "envelope" message, Transaction, that
7
7
is passed to plugins that subscribe to the replication stream.
8
8
 
9
 
Configuration Options
10
 
---------------------
11
 
 
12
 
**transaction_message_threshold**
13
 
 
14
 
    Controls the size, in bytes, of the Transaction messages. When a Transaction
15
 
    message exceeds this size, a new Transaction message with the same
16
 
    transaction ID will be created to continue the replication events.
17
 
    See :ref:`bulk-operations` below.
18
 
 
19
 
 
20
 
**replicate_query**
21
 
 
22
 
    Controls whether the originating SQL query will be included within each
23
 
    Statement message contained in the enclosing Transaction message. The
24
 
    default global value is FALSE which will not include the query in the
25
 
    messages. It can be controlled per session, as well. For example:
26
 
 
27
 
    .. code-block:: mysql
28
 
 
29
 
       drizzle> set @@replicate_query = 1;
30
 
 
31
 
    The stored query should be used as a guide only, and never executed
32
 
    on a slave to perform replication as this will lead to incorrect results.
33
9
 
34
10
Message Definitions
35
11
-------------------
126
102
of the Statement should construct the inner Statement subclass representing
127
103
a data change.
128
104
 
129
 
Statements are recorded seperatley as sometimes individual statements
130
 
have to be rolled back.
131
 
 
132
 
 
133
 
.. _bulk-operations:
134
105
 
135
106
How Bulk Operations Work
136
107
------------------------
166
137
It's easiest to understand this mechanism by following through a real-world
167
138
scenario.
168
139
 
169
 
Suppose the following table:
170
 
 
171
 
.. code-block:: mysql
 
140
Suppose the following table::
172
141
 
173
142
  CREATE TABLE test.person
174
143
  (
180
149
 
181
150
Also suppose that test.t1 contains 1 million records.
182
151
 
183
 
Next, suppose a client issues the SQL statement:
184
 
 
185
 
.. code-block:: mysql
 
152
Next, suppose a client issues the SQL statement::
186
153
 
187
154
  UPDATE test.person SET is_active = 'N';
188
155
 
222
189
Handling ROLLBACKs
223
190
------------------
224
191
 
225
 
Both transactions and individual statements may be rolled back.
226
 
 
227
192
When a transaction is rolled back, one of two things happen depending
228
193
on whether the transaction is made up of either a single Transaction
229
194
message, or if it is made up of multiple Transaction messages (e.g, bulk
235
200
* For a transaction which is made up of multiple messages, and at least
236
201
  one message has already been sent through the replication stream, then
237
202
  the Transaction message will contain a Statement message with type =
238
 
  ROLLBACK.
 
203
  ROLLBACK.
 
 
b'\\ No newline at end of file'