Galera Replication

mysql_galera_restart - created

root — 2013-05-14T19:05:45+03:00

This howto concerns the case when, for whatever reason (power failure, nasty bug, maintenance, etc.), all your MySQL/Galera nodes went down. As in “mysqld process is no more”. The logic there is rather simple and obvious: * find the most updated node (with the most advanced state ID). * start it as the first node of the cluster. * start the rest of the nodes as usual.

howto - [HowTo]

root — 2013-05-14T18:08:59+03:00

* Galera cluster deployment variants * MySQL/Galera configuration basics * Data backup in Galera cluster for MySQL * MySQL/Galera cluster upgrade * How to restart Galera cluster for MySQL * Migrate from MyISAM installation to Galera cluster for MySQL * Use ClusterControl(tm) to deploy Galera cluster in Amazon EC2 in less than 10 minutes * Compile Galera from source

node_provisioning_recovery - [State Transfer]

root — 2013-05-14T17:58:44+03:00

Both new and failed nodes have the same property in common: their state is different from the state of the primary component and needs to be synchronized. As a result, new node provisioning and failed node recovery are essentially the same process and boils down to the node joining the cluster primary component.

limitations

root — 2013-05-12T09:47:08+03:00

This page lists limitations of MySQL/Galera replication. * Currently replication works only with InnoDB storage engine. Any writes to tables of other types, including system (mysql.*) tables are not replicated. However, DDL statements are replicated in statement level, and changes to mysql.* tables will get replicated that way. So, you can safely issue:CREATE USER... or GRANT... but issuing: INSERT INTO mysql.user... will not be replicated. In general, non-transactional engines cannot be supp…

data_backup

root — 2013-05-09T07:29:27+03:00

Good news: Galera cluster backups can be performed just like regular MySQL backups, using your favourite backup script. And since all the nodes are identical, backuping one node means backuping the whole cluster. Bad news: * such backups will have no global transaction ID associated with them, so they are good to recover data, but cannot be used to recover Galera node to a well-defined state. * such backup may block the operation of the whole cluster for the duration of backup (if it is a …

reference - [Status Variables]

root — 2013-05-08T17:57:55+03:00

Operation Node Failure Node Provisioning/Recovery Galera Node State Machine Flow Control SSL Support Galera Arbitrator Scriptable State Snapshot Transfer State Snapshot Transfer methods for MySQL Writeset cache Incremental State Transfer Rolling Schema Upgrade (MySQL >= 5.5.17 only)

info - [Configuration and Status Variables]

root — 2013-05-08T16:49:58+03:00

galera_parameters

root — 2013-05-08T15:47:19+03:00

Galera Parameters As of 0.8 Galera accepts parameters in the form of semicolon-separated key=value pair list: “key1 = value1; key2 = value2” (in addition to Galera URL). It can be used to configure arbitrary number of Galera parameters in one call. A key consists of parameter group and parameter name: ., where group roughly corresponds to some Galera module.

mysql_options_0.8

root — 2013-05-08T02:01:24+03:00

These are MySQL system variables introduced by wsrep patch v0.8. All variables are global except where marked by (L). Option Default Description wsrep_auto_increment_control ON Automatically adjust auto_increment_increment and auto_increment_offset system variables when cluster membership changes. wsrep_causal_reads (L) OFF Enforce strict cluster-wide “read committed” semantics on non-transactional reads. Results in larger read latencies. ws…

ssl_support

root — 2013-05-04T15:26:06+03:00

Starting with version 0.8.2 Galera library supports SSL for encryption of replication traffic. It is a cluster-wide option and should be enabled either on all of the nodes or none at all. To use it a private certificate/key pair should be generated for a cluster, for example, by the following command

flow_control

root — 2013-05-04T15:03:06+03:00

To ensure temporal synchrony and consistency (as opposed to logical which is provided by virtual synchrony), Galera implements several forms of low control depending on the node state: writeset cacheslave queue OPEN & PRIMARY The node is not considered to be a part of the cluster, it is not allowed to replicate, apply or cache any writesets. No flow control.

arbitrator_use_case.png

root — 2011-08-27T13:57:44+03:00

galera_use_cases_2.png

root — 2011-08-27T13:57:11+03:00

galera_use_cases_2a.png

root — 2011-08-27T13:57:04+03:00

galera_use_cases_3.png

root — 2011-08-04T18:43:16+03:00

galera_use_cases_0.png

root — 2011-08-04T17:44:52+03:00

galera_use_cases_1.png

root — 2011-08-04T17:10:44+03:00

galera_fsm.png

root — 2011-06-03T14:50:28+03:00

sst.png

root — 2011-06-01T00:31:47+03:00

certification.png

root — 2011-04-24T22:05:54+03:00