Maraidb 10.1.18, node Binlog is not updated for writes in other nodes of the same cluster. Is gtid not working as expected ?

ClusterA and ClusterB are with 3 nodes each. Using version Mariadb 10.1.18. Have setup a async channel between node1 of ClusterA and node1 of ClusterB in both directions(both act as Master to each other). Any write to node1 of ClusterA is seen replicated to ClusterB and within ClusterA properly. But any write to the node2/3 of ClusterA is not seen in ClusterB. Only synchronized within ClusterA.

When I digged into the binary logs of the nodes of ClusterA, actually the binlog is not updated in a node, when the write happens in another node of the same cluster. The gtid concept is actually not working.

I have used log_slave_updates=1 and log_bin=1.

Pls suggest if I am missing any more options here. The same config works in Mariadb 10.0.27, but there the Bidirectional Async channel setup is resulting in the insertion of duplicate rows.

Appreciate any suggestion on this. Thanks.

my.cnf file looks as below.

[mysqld]

query_cache_size=0

binlog_format=ROW

default-storage-engine=innodb

innodb_autoinc_lock_mode=2

query_cache_type=0

bind-address=0.0.0.0

log_bin=binlog

log_slave_updates=1

expire_logs_days=7

datadir="/var/lib/mysql/"

wsrep_provider="/usr/lib/galera/libgalera_smm.so"

wsrep_sst_method="rsync"

wsrep_on=ON

wsrep_node_address=10.200.69.126

wsrep_node_name=node_10.200.69.126

gtid_strict_mode=OFF

server_id=103

gtid_domain_id=1

gtid_ignore_duplicates=ON

wsrep_cluster_name=cluster_A

wsrep_cluster_address=gcomm:node-1-mariadbk-mariadb-a.mon-marathon-ssre.mesos,node-2-mariadbk-mariadb-a.mon-marathon-ssre.mesos,node-3-mariadbk-mariadb-a.mon-marathon-ssre.mesos

wsrep_provider_options=gcache.size=4G;gmcast.segment=1;

[client]

socket=/var/run/mysqld/mysqld.sock

Comments

Comments loading...
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.