Main system:

• CentOS 6.3 x64
• MariaDB-Galera-server-5.5.36-1.el6.x86_64
• galera-25.3.2-1.rhel6.x86_64

Tested with multiple systems and versions (see description for details).

Hi Ralf,
I tried to reproduce this issue on a variety of platforms : precise (32 & 64), CentOS 6.5 (32 & 64), different
server versions : 5.5.35, 5.5.36, 5.5.37 and galera version 25.3.2, 25.3.5. But couldn't!

Node 1
=====
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 5
Server version: 5.5.37-MariaDB-wsrep-debug Source distribution, wsrep_25.10.r3980

Copyright (c) 2000, 2014, Oracle, SkySQL Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [test]> CREATE DATABASE mytest;
Query OK, 1 row affected (0.00 sec)

MariaDB [test]> USE mytest;
Database changed
MariaDB [mytest]> CREATE TABLE mytable (
-> id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
-> myint INT DEFAULT 0,
-> mybool BOOL DEFAULT 0,
-> mystr VARCHAR(100) DEFAULT ""
-> );
Query OK, 0 rows affected (0.05 sec)

MariaDB [mytest]> INSERT INTO `mytest`.`mytable` (`myint`, `mystr`) VALUES ('0', 'test');
Query OK, 1 row affected (0.00 sec)

MariaDB [mytest]> UPDATE mytable SET myint = 0 WHERE id = 1;
Query OK, 0 rows affected (0.03 sec)
Rows matched: 1 Changed: 0 Warnings: 0

MariaDB [mytest]> UPDATE mytable SET mybool = 0 WHERE id = 1;
Query OK, 0 rows affected (0.00 sec)
Rows matched: 1 Changed: 0 Warnings: 0

MariaDB [mytest]> UPDATE mytable SET mybool = 0 WHERE id = 1;
Query OK, 0 rows affected (0.05 sec)
Rows matched: 1 Changed: 0 Warnings: 0

MariaDB [mytest]> select * from mytable;
--------------------+

--------------------+

--------------------+
1 row in set (0.01 sec)

Node 2
=====
MariaDB [test]> select * from mytest.mytable;
--------------------+

--------------------+

--------------------+
1 row in set (0.00 sec)

Is there something specific that I am missing (besides CentOS 6.3 as I presume
it shouldn't make much difference)?

Hello, Nirbhay!

Thank you for your answer!

I tried to reproduce this issue on a variety of platforms (...) But couldn't!

This is pretty weird.

besides CentOS 6.3 as I presume it shouldn't make much difference

I also think that this should not make much difference.

Here is the config behind the replication, maybe there is something wrong or missing and this causes the error in some way?

# Galera replication lines (taken from "/etc/my.cnf.d/server.cnf")

wsrep_provider=/usr/lib64/galera/libgalera_smm.so

wsrep_cluster_address="gcomm://192.168.1.2"

wsrep_sst_method=rsync

wsrep_sst_auth=root:password

bind-address=192.168.1.1

skip-name-resolve

However, we're also using these config lines for the replication with MariaDB 10 and everything works fine there.

Thanks in advance!

Still no luck. The wsrep_ config options that you have shared are all standard ones and
required for a node to join the cluster (except of wsrep_sst_auth, which is not necessary
in case of 'rsync', but ok if you leave it there). Can you please share all the config options
which are being passed on server start?

Hello, Nirbhay!

except of wsrep_sst_auth, which is not necessary in case of 'rsync'

Thanks for the hint, I've removed it (was a left over from the past).

Can you please share all the config options which are being passed on server start?

Yes I can. I'm using the default init script to start the service and this is my config /etc/my.cnf.d/server.cnf.

# this is read by the standalone daemon and embedded servers

[server]

# this is only for the mysqld standalone daemon

[mysqld]

character-set-server=utf8

default_week_format=3

event-scheduler=1

innodb_buffer_pool_size=1024M

log-error=/var/log/mysqld.log

log-slow-queries=/var/log/mysqld-slow.log

general_log_file=/var/log/mysqld-general.log

general_log=1

max_allowed_packet=16M

symbolic-links=1

user=mysql

# Should be disabled for productive use

performance_schema=on

# this is only for embedded server

[embedded]

# This group is only read by MariaDB-5.5 servers.

# If you use the same .cnf file for MariaDB of different versions,

# use this group for options that older servers don't understand

[mysqld-5.5]

# These two groups are only read by MariaDB servers, not by MySQL.

# If you use the same .cnf file for MySQL and MariaDB,

# you can put MariaDB-only options here

[mariadb]

port=3308

character-set-server=utf8

# Galera replication lines

wsrep_provider=/usr/lib64/galera/libgalera_smm.so

wsrep_cluster_address="gcomm://192.168.1.2"

wsrep_sst_method=rsync

bind-address=192.168.1.1

skip-name-resolve

[mariadb-5.5]

character-set-server=utf8

Thanks in advance!

Hi Ralf,
It looks like binlog-format has not been set? Are you setting it through command line?
In galera cluster, nodes should always be started in "row" binary log format.
On 5.5, I am able to reproduce this issue only when node has binlog format set to
statement (default). However, same works on 10.0-galera due to a minor (and possibly
harmless) difference in one of the innodb handler functions.

Hello, Nirbhay!

It looks like binlog-format has not been set?

Thanks a lot for the information! It was not set via command line, but after setting the binlog-format to row (inside the config) it works.

However, same works on 10.0-galera due to a minor (and possibly harmless) difference

Should I explicitly set the binlog-format there anyway?

Thanks in advance!

> Should I explicitly set the binlog-format there anyway?

Yes, you should.

Yes, you should.

Thanks a lot. Would mixed format be okay does it have to be row format for some reason?

Thanks in advance!

Hi Ralf,
Galera uses certification based replication which requires PK of all rows
changed in a transaction alongside the actual change (collectively known
as writeset) in order to determine if the changes can be applied (conflict-free).
The PK information won't be available if the binary logging is statement based
or mixed (which is mostly statement based).
HTH
Thanks!

I see. Thanks again for your help!