Working with Galera Cluster on MariaDB using RHSC
Starting (or bootstrapping) a Galera Cluster using MariaDB from RHSC (RedHat Software Collection) CANNOT be done with –wsrep-new-cluster option at service start up on RHEL6, e.g. commonly known as:
# service mysql start –wsrep-new-cluster <=== This DOES NOT work!!!
RHEL has re-packaged MariaDB and Galera cluster and move the installation base directory to /opt/rh/rh-mariadb101 from her original installation tree and the service script /etc/init.d/rh-mariadb101-mariadb does not take any additional parameters (e.g. –wsrep-new-cluster) when kicking off the MariaDB service.
Here are the steps to get Galera Cluster started with software distributed by RHSC:
STEP 1: Install MariaDB and Galera Cluster (refer to the post “MariaDB RHSC Instalaltion” abvoe
STEP 2: On the first cluster node, update the configuration file “galera.cnf” (PLEASE NOTE: do not change the my.cnf or mariadb-server.cnf!)
Create an FID to handle State Transition (default is root user):
[mariadb@dbverstyhost ~]$ mysql -u root -p -D mysql
Enter password:
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 12
Server version: 10.1.19-MariaDB MariaDB Server
Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.
Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.
MariaDB [mysql]> GRANT USAGE ON *.* to dbversity_usr@’%’ IDENTIFIED BY ‘dbpass’;
Query OK, 0 rows affected (0.00 sec)
MariaDB [mysql]> GRANT ALL PRIVILEGES on *.* to dbversity_usr@’%’;
Query OK, 0 rows affected (0.00 sec)
MariaDB [mysql]> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.01 sec)
MariaDB [mysql]> quit
Bye
[root@dbverstyhost ~]# cd /etc/opt/rh/rh-mariadb101/my.cnf.d
[root@dbverstyhost my.cnf.d]# ls -l
total 20
-rw-r–r– 1 root root 41 Nov 24 03:18 auth_gssapi.cnf
-rw-r–r– 1 root root 763 Nov 4 07:15 enable_encryption.preset
-rw-r–r– 1 root root 3536 Feb 15 18:20 galera.cnf
-rw-r–r– 1 root root 1518 Nov 24 03:18 mariadb-server.cnf
-rw-r–r– 1 root root 232 Nov 4 07:15 mysql-clients.cnf
[root@dbverstyhost my.cnf.d]#
Update galera.cnf with the following parameters:
wsrep_provider=/opt/rh/rh-mariadb101/root/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_name=”my_wsrep_cluster”
wsrep_cluster_address=”gcomm://212.10.13.79,212.10.13.112,212.10.13.113″
wsrep_node_name=dbverstyhost
wsrep_node_address=212.10.13.113
wsrep_sst_method=rsync
wsrep_sst_auth=dbversity_usr:dbpass
STEP 3: Bootstrap the new cluster:
[root@dbverstyhost my.cnf.d]# service rh-mariadb101-mariadb stop
Stopping rh-mariadb101-mariadb: [ OK ]
[root@dbverstyhost my.cnf.d]# scl enable rh-mariadb101 ‘galera_new_cluster’
Starting rh-mariadb101-mariadb: [ OK ]
[root@dbverstyhost my.cnf.d]#
Check the cluster status:
MariaDB [(none)]> show status like ‘wsrep_%’;
Specially for the following:
+——————————+————————————–+
| Variable_name | Value |
+——————————+————————————–+
| wsrep_cluster_size | 1 |
| wsrep_cluster_state_uuid | 7cfd3cfd-f460-11e6-a68c-e771d72eccdb |
| wsrep_cluster_status | Primary |
| wsrep_connected | ON |
| wsrep_evs_state | OPERATIONAL |
| wsrep_gcomm_uuid | 7cfc71d0-f460-11e6-a58a-f3b7d501e78d |
| wsrep_incoming_addresses | 212.10.13.113:3306 |
| wsrep_local_state_comment | Synced |
| wsrep_provider_name | Galera |
| wsrep_provider_vendor | Codership Oy <info@codership.com> |
| wsrep_provider_version | 3.12(r9921e73) |
| wsrep_ready | ON |
STEP 4: Add more nodes to the cluster
Copy the galera.cnf to the 2nd node and modify the following parameters:
wsrep_node_name=dbversityhost03
wsrep_node_address=212.10.13.79
And start the 2nd node normally, in this example, this is the first time the MariaDB starts up on this host. the users and databases are all replicated and synced from the first node. There’s no need to run mysql_secure_installation or create dbversity_usr.
[root@dbversityhost03 my.cnf.d]# service rh-mariadb101-mariadb start
Initializing MariaDB database
2017-02-16 11:12:06 139634290231264 [Note] /opt/rh/rh-mariadb101/root/usr/libexec/mysqld (mysqld 10.1.19-MariaDB) starting as process 32277 …
2017-02-16 11:12:11 139706038134752 [Note] /opt/rh/rh-mariadb101/root/usr/libexec/mysqld (mysqld 10.1.19-MariaDB) starting as process 32307 …
2017-02-16 11:12:15 140367686957024 [Note] /opt/rh/rh-mariadb101/root/usr/libexec/mysqld (mysqld 10.1.19-MariaDB) starting as process 32337 …
PLEASE REMEMBER TO SET A PASSWORD FOR THE MariaDB root USER !
To do so, start the server, then issue the following commands:
scl enable rh-mariadb101 — ‘/opt/rh/rh-mariadb101/root/usr/bin/mysqladmin’ -u root password ‘new-password’
scl enable rh-mariadb101 — ‘/opt/rh/rh-mariadb101/root/usr/bin/mysqladmin’ -u root -h dbversityhost03 password ‘new-password’
Alternatively you can run:
scl enable rh-mariadb101 — ‘/opt/rh/rh-mariadb101/root/usr/bin/mysql_secure_installation’
which will also give you the option of removing the test
databases and anonymous user created by default. This is
strongly recommended for production servers.
See the MariaDB Knowledgebase at http://mariadb.com/kb or the
MySQL manual for more instructions.
Please report any problems at http://mariadb.org/jira
The latest information about MariaDB is available at http://mariadb.org/.
You can find additional information about the MySQL part at:
http://dev.mysql.com
Support MariaDB development by buying support/new features from MariaDB
Corporation Ab. You can contact us about this at sales@mariadb.com.
Alternatively consider joining our community based development effort:
http://mariadb.com/kb/en/contributing-to-the-mariadb-project/
Starting rh-mariadb101-mariadb: [ OK ]
Check the cluster status to ensure the 2nd node is added to the cluster:
MariaDB [mysql]> show status like ‘wsrep_cluster%’;
+————————–+————————————–+
| Variable_name | Value |
+————————–+————————————–+
| wsrep_cluster_conf_id | 2 |
| wsrep_cluster_size | 2 |
| wsrep_cluster_state_uuid | 7cfd3cfd-f460-11e6-a68c-e771d72eccdb |
| wsrep_cluster_status | Primary |
+————————–+————————————–+
4 rows in set (0.00 sec)
Repeat STEP 4 to add more nodes to the cluster.
Please note: For Galera cluster to function, the 3 node cluster is recommended minimum to ensure the chance that a quorum will exist in the event of network problem. A cluster has two nodes (or more generally any even number of nodes) a single network link failure could cause the cluster to pause since it could create two partitions with half of the nodes, neither having a quorum. An odd number of nodes means that a single network link failure cannot cause the cluster to pause since there will always be quorum.
I enjoyed your wonderful blog.
Thank you for the very hard work done.