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

Data loss on 10.1.20-MariaDB

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Critical
    • Resolution: Fixed
    • 10.1.20
    • 10.0.31
    • Replication

    Description

      Since we changed from MySQL to MariDB 10.1.20 we expecting data integrity problems. Some deeper investigations aproved that fact and we would have a resolution for this Problem:

      In our test case we have two nodes connected over lan and have a typical replication between them:

      SystemA <---> SystemB

      From SystemC we have started mysqlslap on SystemA to generate some queries:

      CREATE DATABASE perftest;
      CREATE TABLE perftest.a (ID int NOT NULL AUTO_INCREMENT, b TEXT, PRIMARY KEY (ID)) ENGINE=MyISAM;
      

      mysqlslap -h SystemA -p --delimiter=";" --query="INSERT INTO perftest.a (b) VALUES(NOW())" --concurrency=500 --iterations=200
      

      In the meantime of the generation we stopped on SystemB the slave and started after some seconds again

      stop slave;
      start slave;
      

      We are waiting a while until SystemA has a count of 100000 inserts = mysqlslap has finished the generation:

      select count(*) from perftest.a;
      

      Repeat the above count on SystemB(Slave) where we have stopped and started the slave, you will see a huge difference. In other words, we have a data loss!

      Attachments

        1. 4x_slaves_status.txt
          6 kB
        2. my.cnf
          2 kB
        3. slave_status.log
          2 kB

        Activity

          People

            Elkin Andrei Elkin
            drobot Igor Drobot
            Votes:
            0 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.