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

galera.galera_wan_restart_sst fails: Server did not transition to READY state

    XMLWordPrintable

Details

    • Bug
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • 10.11, 11.4, 13.1
    • None
    • Galera, Tests, MTR
    • None

    Description

      galera.galera_wan_restart_sst fails with Server did not transition to READY state on the 10.11, 11.4, 13.1 and main branches.

      Build Run Info

      Branch Builder name Date Commit Variant
      10.11 aarch64-debian-12 2026-10-02T02:09:35Z 45c0b8649cd3e8ff8fefa5258b6b3f2c3172b61f none
      11.4 ppc64le-ubuntu-2204 2026-10-02T11:41:51Z 64929e06781b69f79e243a57a0cee7b291f0753f none
      13.1 ppc64le-ubuntu-2204 2026-10-01T06:19:59Z 87e62ca17270e163a6d41b3fc8d6f4d440f1bb88 none
      main aarch64-debian-12 2026-10-01T10:14:51Z 3cdcd64fb042f4a31e82613ef2835c37fcafcc3d none

      Failure text

      Latest run on 10.11 (worker number, timestamps, paths, the calling test line and the query tail differ between runs):

      galera.galera_wan_restart_sst            w12 [ fail ]
              Test ended at 2026-10-02 00:21:31
       
      CURRENT_TEST: galera.galera_wan_restart_sst
      mysqltest: In included file "./include/galera_wait_ready.inc": 
      included from /home/buildbot/aarch64-debian-12/build/mysql-test/suite/galera/include/start_mysqld.inc at line 16:
      included from /home/buildbot/aarch64-debian-12/build/mysql-test/suite/galera/t/galera_wan_restart_sst.test at line 109:
      At line 43: "Server did not transition to READY state in  seconds"
       
      The result from queries just before the failure was:
      < snip >
      INSERT INTO t1 VALUES (11);
      connection node_2;
      INSERT INTO t1 VALUES (12);
      connection node_4;
      INSERT INTO t1 VALUES (14);
      connection node_3;
      INSERT INTO t1 VALUES (131);
      connection node_1;
      connection node_2;
      INSERT INTO t1 VALUES (22);
      connection node_1;
      connection node_2;
      Killing server ...
      connection node_1;
      INSERT INTO t1 VALUES (21);
      connection node_3;
      INSERT INTO t1 VALUES (23);
      connection node_4;
      INSERT INTO t1 VALUES (24);
      connection node_2;
       
      More results from queries before failure can be found in /home/buildbot/aarch64-debian-12/build/mysql-test/var/12/log/galera_wan_restart_sst.log
       
       - saving '/home/buildbot/aarch64-debian-12/build/mysql-test/var/12/log/galera.galera_wan_restart_sst/' to '/home/buildbot/aarch64-debian-12/build/mysql-test/var/log/galera.galera_wan_restart_sst/'
       
      Retrying test galera.galera_wan_restart_sst, attempt(2/3)...

      On 11.4, 13.1 and main the failing line is At line 28: "Server did not transition to READY state", without the in seconds suffix.

      Analysis

      Two builders are affected: aarch64-debian-12 (10.11, 13.1, main) and ppc64le-ubuntu-2204 (11.4, 13.1). The failure is raised by galera_wait_ready.inc, called through start_mysqld.inc from galera_wan_restart_sst.test at line 74, 109 or 142, while waiting for a started node to reach the READY state. MDEV-38401 covers failures on aarch64-debian-12 that end with the same message; the comments there refer to SST timeouts at the donor under parallel MTR load and to MDEV-40727. On s390x-ubuntu-2204 the test also failed on 10.11, 11.4, 12.3 and 13.1 between 2026-09-29 and 2026-09-30 with WSREP did not transition to state READY.

      Created via the mtr-failure-bug skill.

      Attachments

        Issue Links

          Activity

            People

              bnestere Brandon Nesterenko
              susil.behera Susil Behera
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

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