MariaDB Galera Fix 5.5.42 Fix


Installing package(s) with command apt-get -y install libmysqlclient18 ..


Reading package lists...
Building dependency tree...
Reading state information...
The following packages were automatically installed and are no longer required:
  comerr-dev galera-3 iproute krb5-multidev libapr1-dev libgssrpc4
  libkadm5clnt-mit9 libkadm5srv-mit9 libkdb5-7 libldap2-dev libpq-dev
  libsctp-dev libsctp1 libsqlite3-dev libssl-dev libssl-doc
  libterm-readkey-perl linux-image-3.13.0-46-generic
  linux-image-extra-3.13.0-46-generic lksctp-tools mariadb-common uuid-dev
Use 'apt-get autoremove' to remove them.
The following packages will be REMOVED:
  apache2-dev libaprutil1-dev libmariadbclient-dev libmariadbclient18
  mariadb-client-5.5 mariadb-client-core-5.5 mariadb-galera-server-5.5
The following packages will be upgraded:
1 upgraded, 0 newly installed, 7 to remove and 0 not upgraded.
Need to get 596 kB of archives.
After this operation, 123 MB disk space will be freed.
Get:1 trusty-security/main libmysqlclient18 amd64 5.5.43-0ubuntu0.14.04.1 [596 kB]
Fetched 596 kB in 1s (451 kB/s)
(Reading database ... 123781 files and directories currently installed.)
Removing apache2-dev (2.4.7-1ubuntu4.4) ...
Removing libaprutil1-dev (1.5.3-1) ...
Removing libmariadbclient-dev (5.5.42+maria-1~trusty) ...
Removing mariadb-galera-server-5.5 (5.5.42+maria-1~trusty) ...
 * Stopping MariaDB database server mysqld
Removing mariadb-client-5.5 (5.5.42+maria-1~trusty) ...
Removing mariadb-client-core-5.5 (5.5.42+maria-1~trusty) ...
Removing libmariadbclient18 (5.5.42+maria-1~trusty) ...
Processing triggers for man-db ( ...
Processing triggers for libc-bin (2.19-0ubuntu6.6) ...
(Reading database ... 122799 files and directories currently installed.)
Preparing to unpack .../libmysqlclient18_5.5.43-0ubuntu0.14.04.1_amd64.deb ...
Unpacking libmysqlclient18:amd64 (5.5.43-0ubuntu0.14.04.1) over (5.5.42+maria-1~trusty) ...
Setting up libmysqlclient18:amd64 (5.5.43-0ubuntu0.14.04.1) ...
Processing triggers for libc-bin (2.19-0ubuntu6.6) ...
To Fix
Ensure you are using latest source. (see
Get latest repository here


sudo apt-get remove libdbd-mysql-perl libmariadbclient18 libmysqlclient18 mariadb-client-5.5 mariadb-common mariadb-galera-server mariadb-galera-server-5.5 mysql-common  php5-mysql mariadb-client-core-5.5


Once everything is re-instal ensure your cluster is running as expected.

sudo apt-key adv --recv-keys --keyserver hkp:// 0xcbcb082a1bb943db

sudo add-apt-repository ‘deb trusty main’ 


sudo apt-get update && sudo apt-get install libmysqlclient18=5.5.44+maria-1~trusty mariadb-client-5.5=5.5.44+maria-1~trusty mariadb-client-core-5.5=5.5.44+maria-1~trusty mariadb-galera-server-5.5


mysql -u root -p -e ‘SELECT VARIABLE_VALUE as “cluster size” FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME=”wsrep_cluster_size”‘



| cluster size |


| 4            |




MariaDB Galera Quicktips


Set mysql server to auto start on all nodes.

Only when all the nodes are down run on main node.

sudo service mysql start --wsrep-new-cluster

Run the following on member nodes.

sudo service mysql start 

Join nodes to cluster by using command, with IP of one of the cluster nodes.

sudo service mysql start –wsrep_cluster_address=gcomm://ip_address

Check cluster size

mysql -u root -p -e ‘SELECT VARIABLE_VALUE as “cluster size” FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME=”wsrep_cluster_size”‘

Double check configuration files

sudo nano /etc/mysql/conf.d/galera.cnf
sudo nano /etc/mysql/conf.d/my.cnf


ERROR 1045 (28000): Access denied for user ‘debian-sys-maint’@’localhost’ (using password: YES)

Processing triggers for ureadahead (0.100.0-16) …


System check

mysql root e“show status like ‘wsrep%'”

wsrep_local_state_comment    |Synced         <cluster issynced
wsrep_incoming_addresses     |  <node db1 isaprovider
wsrep_cluster_size           |1              <cluster consists of1node 
wsrep_ready                  |ON             <good:)

If you are importing an SQL file. Ensure that the database is imported as InnoDB.
Galera only support InnoDB replication.

Galera slow node performance



Is it true that MySQL Galera is as slow as the slowest node?


Yes it is. Galera relies on group communication between nodes. For any matters, it will wait for all nodes to return the status of certification test before proceed with committing or rollbacking. At this phase, an overloaded node will surely facing a hard time to reply within the time manner, delaying the rest of the cluster to wait for it. Therefore it is recommended to have uniform servers across the cluster. Also, transaction latency is no shorter than the RTT (round trip time) to the slowest node.

Galera How to Handle a Crash


How to handle Galera crash?


First of all, make sure you are running the latest Galera stable release so you do not run into older bugs that have already been fixed. Start with inspecting the MySQL error log on the Galera nodes as Galera will be logging to this file. Try to shed some light to any relevant line which indicates error or failing. If the Galera nodes happen to be responsive, you may also try to collect following output:



Next, inspect the system resources by checking network, firewall, disk usage and memory utilization as well as inspecting the general system activity log (syslog, message, dmesg). If still no indication of the problem found, you may hit into a bug which you can report it directly at Galera bugs on Launchpad page or request for technical support assistance directly from the vendor (Codership, Percona or MariaDB). You may also join the Galera Google Group mailing list to seek for open assistance.



  • If you are using rsync for state transfer, and a node crashes before the state transfer is over, rsync process might hang forever, occupying the port and not allowing to restart the node. The problem will show up as ‘port in use’ in the server error log. Find the orphan rsync process and kill it manually.
  • Before re-initializing the cluster, you can determine which DB node is having the most updated data by comparing the wsrep_last_commited value among nodes. The one which holding the highest number is recommended to be the reference node when bootstrapping the cluster.