Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-9037

DML statements on a Galera Cluster node with sql_log_bin=OFF still appears in binary log on _other_ nodes

Details

    • Bug
    • Status: Closed (View Workflow)
    • Minor
    • Resolution: Won't Fix
    • 10.1.8
    • N/A
    • Galera
    • 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-7205 was 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

          Activity

            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.

            elenst Elena Stepanova added a comment - 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.

            Just for the sake of completeness, the following bug report states that it is related to this bug report, so I also wanted to note that in this report (in case anyone is searching for one or the other, etc.):

            https://jira.mariadb.org/browse/MDEV-7205

            ccalender Chris Calender (Inactive) added a comment - Just for the sake of completeness, the following bug report states that it is related to this bug report, so I also wanted to note that in this report (in case anyone is searching for one or the other, etc.): https://jira.mariadb.org/browse/MDEV-7205

            10.1 is EOL.

            janlindstrom Jan Lindström added a comment - 10.1 is EOL.

            People

              jplindst Jan Lindström (Inactive)
              jorginator Karl E. Jørgensen
              Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.