Jump to content

User:Yiyiyongfu/sandbox: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Yiyiyongfu (talk | contribs)
Yiyiyongfu (talk | contribs)
Line 8: Line 8:
* Write-Set Replication API: has wsrep hooks, dlopen() and Galera Replication Plugin
* Write-Set Replication API: has wsrep hooks, dlopen() and Galera Replication Plugin
* Group Communication plugins: the plugins that make the write-set replication in proper working order.
* Group Communication plugins: the plugins that make the write-set replication in proper working order.
Wsrep API: It is a connection link between databases. Set the content in a database as a state. When changes appears in a database, same changes occur in other database as the result of Wsrep API. When changes happen in one database, wsrep hooks interpret the changes to write-set. Then Galera Replication plugin process the interpret and copy the data of nodes to other databases. To record each change of the state of the database, Global Transaction ID is used.
[https://launchpad.net/wsrep Wsrep API]: It is a connection link between databases. Set the content in a database as a state. When changes appears in a database, same changes occur in other database as the result of Wsrep API. When changes happen in one database, wsrep hooks interpret the changes to write-set. Then Galera Replication plugin process the interpret and copy the data of nodes to other databases. To record each change of the state of the database, Global Transaction ID is used.
45eec521-2f34-11e0-0800-2a36050b826b:94530586304
45eec521-2f34-11e0-0800-2a36050b826b:94530586304
Galera Replication Plugin: It consists of Certification Layer, Replication Layer and Group Communication Framework.[[File:Multi-master.png|thumb|309x309px|insert a caption here]]
Galera Replication Plugin: It consists of Certification Layer, Replication Layer and Group Communication Framework.[[File:Multi-master.png|thumb|309x309px|insert a caption here]]
Line 121: Line 121:
* -- -- <code>defaults-file</code>(the script is given the path to the my.cnf configuration file)
* -- -- <code>defaults-file</code>(the script is given the path to the my.cnf configuration file)


=== Differences with MySQL<ref>{{Cite web|url=https://mariadb.com/kb/en/mariadb/galera-use-cases/|title=Galera Use Cases|access-date=2016-09-13}}</ref> ===
=== Differences with MySQL ===
Although Galera Cluster is really alike MySQL and some other database systems,  there are still some fundamental differences.
Although Galera Cluster is really alike MySQL and some other database systems,  there are still some fundamental differences.


Line 128: Line 128:


==== Differences in Table Configurations ====
==== Differences in Table Configurations ====
The same problems also happen with respect to storage engine support, certain queries and the query cache.<syntaxhighlight>
The same problems also happen with respect to storage engine support, certain queries and the query [[Cache (computing)|cache]].<syntaxhighlight>
INSERT INTO mysql.user (Host, User, Password)
INSERT INTO mysql.user (Host, User, Password)
VALUES ('localhost', 'stranger', 'password');
VALUES ('localhost', 'stranger', 'password');

Revision as of 02:35, 13 September 2016

Introduction

Galera Cluster is a database cluster who is suitable in diverse database server, such as MySQL and so on.  Multi-master replication system and Synchronous Replication are used to update data of nodes in the database. Automatic nodes joining and membership control are essential features of Galera Cluster. When Galera Cluster is under operation, user can have access to any node and compose it without interruption. 

Galera Cluster uses Synchronous replication systems to update every nodes in a single transaction through write-set replication. Galera Cluster has three main components:

  • Database Management System (DBMS): use MySQL, MariaDB or Percona XtraDB as the databse server to operate self nodes.
  • Write-Set Replication API: has wsrep hooks, dlopen() and Galera Replication Plugin
  • Group Communication plugins: the plugins that make the write-set replication in proper working order.

Wsrep API: It is a connection link between databases. Set the content in a database as a state. When changes appears in a database, same changes occur in other database as the result of Wsrep API. When changes happen in one database, wsrep hooks interpret the changes to write-set. Then Galera Replication plugin process the interpret and copy the data of nodes to other databases. To record each change of the state of the database, Global Transaction ID is used.

45eec521-2f34-11e0-0800-2a36050b826b:94530586304  

Galera Replication Plugin: It consists of Certification Layer, Replication Layer and Group Communication Framework.

insert a caption here
insert a caption here

Features

Galera Cluster has make database sever such as MySQL to reach a excellent performance. As it uses the multi-master system, when any change is updated to any database, other databases will also have the same change simultaneously

  • High Reliability: when nodes crush, there is no data loss.
  • High Accessibly: user can add and delete nodes at any time, even under the operation of the system.
  • Excellent consistency of information: when the state of one database changed, all the state changed simultaneously.
  • Automatic Node Provisioning: System automatically back up databse.

Installing

Galera Cluster will need you to prepare some additional softwares and configurations as the fundamental of itself. It supports any unix-like systems like OS X. After you finish installing the software on your server you would also need to configure the server to make it as a node. It needs at least three nodes.

Installing the Galera Cluster for MySQL

You will also need to do a lot of steps to prepare for the install like disabling SELinux and configuring the firewall.

Moreover you need to enable a lot of stuff.

  • Enabling the Codership repository
  • Enabling the apt Repository
  • Enabling the yum Repository
  • Enabling the zypper Repository

There are two packages which are wsrep and Galera Replication Plugin that you need to install for Galera Cluster.

For Red Hat, Fedora and CentOS distributions:

# yum install galera-3 \ 

                    mysql-wsrep-5.6

Galera Cluster has been installed on your machine by these two lines of code. 

Installing the Galera Cluster for MariaDB

MariaDB Galera Cluster is the MariaDB implementation of Galera Cluster for MySQL.

You also need to enable a lot:

  • Enabling the MariaDB Repository
  • Enabling the apt Repository
  • Enabling the yum Repository

Three packages involved in the installation of MariaDB Galera Cluster:

  • MariaDB database client
  • MariaDB database server
  • Galera Replication Plugin

For Red Hat distributions:

# yum install MariaDB-client \

                MariaDB-Galera-server \

                Galera

System Configuration

After you installed this Galera Cluster you have to make your database as a node in your cluster. You need to edit the MySQL configuration file for this purpose.

  • Configuring Database Server
  • Configuring Swap Space

Using Galera Cluster

As we have finished installing the Galera Cluster and some configurations, we can introduce something about application for Galera Cluster. You will know how to take nodes into cluster, how to recover failed nodes, how to back up data from cluster and how to make the communications safe.

Nodes Provision[1]

Galera needs all the nodes to be synchronized with the cluster. So it is really important to join nodes to the cluster.

There are two options available to detemine the state transfer donor

  • Automatic
  • Manual

Also It comes to the topic of state snapshot transfers. We can divide all the methods to two facets:

  • Logical State Snapshots(interface through the server and client)
  • Physical State Snapshots(copy the data files directly from node to node)

Recovering the Primary Component[2]

What is the primary component? If one of the nodes fails, the cluster may be divided to several parts. Then only one of the components can still perform normally and modify the database state. This is the primary component. The cluster will recovers the primary component if there is an outage.

What if we nned to modify the saved primary component state? A node will give itself a unique ID to identify itself to others after a suddenly shutdown. For instance, if you want three nodes to join together as a new primary component you will need to provide unique ID for them respectively. And the file record these values is gwstate.dat.

Resetting the Number of Nodes

Nodes sometimes would be not the primary component any more. At this time all nodes would return an error to all queries. You can check this by using the wsrep_cluster_status.

SHOW GLOBAL STATUS LIKE 'wsrep_cluster_status';

If none of the nodes consider itself as a primary component, you need to reset the quorum. There are two ways to do this:

  • Automatic Bootstrap
  • Manual Bootstrap

As for the manual bootstrap, we will bootstraps the primary component to the most current node. First to shut down the cluster and then start it up and make the most current node at the beginning.

# Shut down
service mysql stop
systemctl stop mysql
# Start the most the current node
service mysql start --wsrep-new-cluster
systemctl start mysql --wsrep-new-cluster
# Start all nodes
service mysql start
systemctl start mysql

Upgrading Galera Cluster[3]

You will need a better cluster sometimes and you need to upgrade the Galera Cluster.

  • Rolling Upgrade
  • Bulk Upgrade
  • Provider Upgrade

When you use rolling upgrades, the cluster would not be interrupted but the speed is very low. On the contrary, if you don't want to wait for so much time and accept all the clusters down at the same time so that there must be an outage. There is still another choice that not taking so much time called provider upgrade. You could only upgrade the Galera Cluster provider in this way.

Scriptable State Snapshot Transfers

There is some general parameters for all state transfer scripts to tell you the condition of the nodes and clusters.

  • -- -- role(refer a node to be sender or receiver)
  • -- -- address(return IP address)
  • -- -- auth(return authentication)
  • -- -- datadir(path to the data directory)
  • -- -- defaults-file(the script is given the path to the my.cnf configuration file)

Differences with MySQL[4]

Although Galera Cluster is really alike MySQL and some other database systems,  there are still some fundamental differences.

Differences in Server

Not like MySQL, Galera Cluster does not support so many database systems. There are also many differences in the way it handles binary logs and character sets. Also it does not use the binlog-do-db options and character_set_server with UTF-16, UTF-32 or UCS-2.

Differences in Table Configurations

The same problems also happen with respect to storage engine support, certain queries and the query cache.

INSERT INTO mysql.user (Host, User, Password) 
    VALUES ('localhost', 'stranger', 'password');

For example the above code cannot realize its purpose that replicate the changes to the database to the cluster. You also cannot open a log directly. You must forwart the logs to a file for Galera Cluster.

log_output = FILE

Differences in Transactions

The differences also exist in the way Galera Cluster processes transactions from MySQL. For example, the standard MySQL server supports the distributed transaction processing while it does not make sense with Galera Cluster.

Transaction commit is also different. Galera uses optimistic concurrency control, which can issue a commit aborting at the stage. When this happens, Galera will return a deadlock error.

code (Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK)

Migrating from MySQL to Galera Cluster[5]

If your local server already has versions of MySQL, MariaDB or some others, you need to take some additional steps before migration. Before upgrading, you also need to do some basic steps to use mysql_upgrade.

First you need to start the database server without replication.

service mysql start --wsrep_on=OFF
mysql_upgrade
systemctl stop mysql

After finishing upgrading the table you need to initialize the cluster as well as stoping the mysqld process. The Galera Replication Plugin can be used only if there is a transactional storage engine .

Infrastructure Preparation

Before migration, you first need to think about the infrastructure.

  • Launch three new servers at least
  • Install Galera on each new server
  • Configure the database server
  • Start the cluster after finishing above steps

To check if it is working properly, use the following code:

SHOW STATUS LIKE 'wsrep_cluster_size';

After all these steps over, Galera Cluster is now working well as well as your MySQL. However it does not have data for it is now unused.

Data Migration

You need to transfer the data from your existing structure to the Galera Cluster. There are several steps:

  • Stop the master server
  • Load the migration.sql file to one of the new nodes.
  • Transfer the data from the master server to the cluster nodes
  • Restart the application servers
    # Stop the server
    $ mysqldump -u root -p --skip-create-options --all-databases > migration.sql
    # Load
    $ scp migration.sql user@galera-node-IP
    # Tranfer
    $ mysql -u root -p < migration.sql
    You also need to transfer the database.

Reference

  1. ^ "State Snapshot Transfers — Galera Cluster Documentation". galeracluster.com. Retrieved 2016-09-13.
  2. ^ "Recovering the Primary Component — Galera Cluster Documentation". galeracluster.com. Retrieved 2016-09-13.
  3. ^ "Upgrading Galera Cluster — Galera Cluster Documentation". galeracluster.com. Retrieved 2016-09-13.
  4. ^ "Galera Use Cases". Retrieved 2016-09-13.
  5. ^ "Migrating to Galera Cluster — Galera Cluster Documentation". galeracluster.com. Retrieved 2016-09-13.