Merge lp:~hrvojem/percona-xtradb-cluster/bug918568 into lp:~percona-dev/percona-xtradb-cluster/5.5.17-22.1

Proposed by Hrvoje Matijakovic on 2012-01-20
Status: Merged
Approved by: Vadim Tkachenko on 2012-01-30
Approved revision: 3693
Merged at revision: 3695
Proposed branch: lp:~hrvojem/percona-xtradb-cluster/bug918568
Merge into: lp:~percona-dev/percona-xtradb-cluster/5.5.17-22.1
Diff against target: 56 lines (+12/-5)
2 files modified
doc/source/faq.rst (+8/-1)
doc/source/glossary.rst (+4/-4)
To merge this branch: bzr merge lp:~hrvojem/percona-xtradb-cluster/bug918568
Reviewer Review Type Date Requested Status
Vadim Tkachenko 2012-01-20 Approve on 2012-01-30
Review via email: mp+89394@code.launchpad.net
To post a comment you must log in.
Vadim Tkachenko (vadim-tk) wrote :

I see merge conflict there

+<<<<<<< TREE

review: Needs Fixing
3693. By Hrvoje Matijakovic on 2012-01-30

added FAQ entry regarding bug918568

Vadim Tkachenko (vadim-tk) wrote :

good now

review: Approve

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'doc/source/faq.rst'
2--- doc/source/faq.rst 2012-01-17 15:50:42 +0000
3+++ doc/source/faq.rst 2012-01-30 19:54:24 +0000
4@@ -7,7 +7,7 @@
5 A: For auto-increment particular, Cluster changes auto_increment_offset
6 for each new node.
7 In the single node workload, locking handled by usual way how |InnoDB| handles locks.
8-In case of write load on several nodes, Cluster uses optimistic locking (http://en.wikipedia.org/wiki/Optimistic_concurrency_control) and application may receive lock error in the response on COMMIT query.
9+In case of write load on several nodes, Cluster uses `optimistic locking <http://en.wikipedia.org/wiki/Optimistic_concurrency_control>`_ and application may receive lock error in the response on COMMIT query.
10
11 Q: What if one of the nodes crashes and innodb recovery roll back some transactions?
12 =====================================================================================
13@@ -34,6 +34,13 @@
14
15 wsrep_provider_options="pc.ignore_sb = yes"
16
17+Q: Is it possible to set up cluster without state transfer
18+==========================================================
19+A: It is possible in two ways:
20+
21+1. by default Galera reads starting position from a text file <datadir>/grastate.dat. Just make this file identical on all nodes, and there will be no state transfer upon start.
22+2. wsrep_start_position variable - start the nodes with the same *UUID:seqno* value and there you are.
23+
24 Q: I have a two nodes setup. When node1 fails, node2 does not accept commands, why?
25 ====================================================================================
26 A: This is expected behaviour, to prevent |split brain|. See previous question.
27
28=== modified file 'doc/source/glossary.rst'
29--- doc/source/glossary.rst 2012-01-18 14:14:48 +0000
30+++ doc/source/glossary.rst 2012-01-30 19:54:24 +0000
31@@ -11,10 +11,10 @@
32 Storage engine which provides ACID-compliant transactions and foreign key support, among others improvements over :term:`MyISAM`. It is the default engine for |MySQL| as of the 5.5 series.
33
34 MyISAM
35- Previous default storage engine for |MySQL| for versions prior to 5.5. It doesn't fully support transactions but in some scenarios may be faster than :term:`InnoDB`. Each table is stored on disk in 3 files: :term:`.frm`, :term:`.MYD`, :term:`.MYI`
36+ Previous default storage engine for |MySQL| for versions prior to 5.5. It doesn't fully support transactions but in some scenarios may be faster than :term:`InnoDB`. Each table is stored on disk in 3 files: :term:`.frm`, :term:`.MYD`, :term:`.MYI`.
37
38 IST
39- Incremental State Transfer. Functionallity which instead of whole state snapshot can catch up with te group by receiving the missing writesets, but only if the writeset is still in the donor's writeset cache
40+ Incremental State Transfer. Functionallity which instead of whole state snapshot can catch up with te group by receiving the missing writesets, but only if the writeset is still in the donor's writeset cache.
41
42 XtraBackup
43 *Percona XtraBackup* is an open-source hot backup utility for |MySQL| - based servers that doesn’t lock your database during the backup.
44@@ -23,10 +23,10 @@
45 *Percona XtraDB* is an enhanced version of the InnoDB storage engine, designed to better scale on modern hardware, and including a variety of other features useful in high performance environments. It is fully backwards compatible, and so can be used as a drop-in replacement for standard InnoDB. More information `here <http://www.percona.com/docs/wiki/Percona-XtraDB:start>`_ .
46
47 XtraDB Cluster
48- *Percona XtraDB Cluster* is a high availability solution for MySQL
49+ *Percona XtraDB Cluster* is a high availability solution for MySQL.
50
51 Percona XtraDB Cluster
52- *Percona XtraDB Cluster* is a high availability solution for MySQL
53+ *Percona XtraDB Cluster* is a high availability solution for MySQL.
54
55 my.cnf
56 This file refers to the database server's main configuration file. Most Linux distributions place it as :file:`/etc/mysql/my.cnf`, but the location and name depends on the particular installation. Note that this is not the only way of configuring the server, some systems does not have one even and rely on the command options to start the server and its defaults values.

Subscribers

People subscribed via source and target branches