Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Won't Fix
-
10.1.8
-
Centos 7
Description
Our set-up:
- 3-node galera cluster
- MariaDB 10.1.8
- Centos 7
Configuration is pretty vanilla (this is a test cluster for now). The important settings are:
- binary logging enabled
- binlog_format = ROW
- log_slave_updates=ON
- sql_log_bin=ON
Things work fine. Except when apps do changes with sql_log_bin=OFF in their session - when doing so, the changes are (correctly) omitted from the binary logs on ONE node. But the binary logs on the OTHER nodes still show the changes!
This is a problem for us, as we need to be able to use asynchronous replication from the cluster to other servers: The slaves will see inconsistent behaviour depending on which node the changes originate from and which node they connect to.
Example:
connect mysql node_1;
|
create database if not exists test;
|
use test;
|
create table test_sql_log_bin (
|
id bigint auto_increment primary key,
|
s varchar(200)
|
);
|
insert into test_sql_log_bin(s) values (concat('Row from ',@@hostname, ' with sql_log_bin=', @@sql_log_bin));
|
set sql_log_bin=0;
|
insert into test_sql_log_bin(s) values (concat('Row from ',@@hostname, ' with sql_log_bin=', @@sql_log_bin));
|
Our current results are:
- both rows are replicated correctly to node_2 and node_3 (before
MDEV-7205was fixed, the 2nd insert did not replicate correctly) - binary log on node_1 only shows the first insert, which is what was expected.
- binary log on node_2 and node_3 shows both inserts - even though the 2nd was done with sql_log_bin=OFF. This is not what we hoped for...
Attachments
Issue Links
- relates to
-
MDEV-31437 (Galera + SQL_LOG_BIN=0) = GTID and state corruption
-
- Closed
-
-
MDEV-7205 Galera cluster & sql_log_bin = off don't work
-
- Closed
-
I don't think sql_log_bin=0 has anything to do with Galera replication at all. Yes, it prevents an event from being written to the binary log, but not from being replicated to other nodes, and since other nodes don't have sql_log_bin=0, they naturally write it to their binary logs.
But maybe I'm missing something here, assigning to nirbhay_c to confirm or provide a better answer.