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

[PATCH] 10.1 Fails To Join Existing Galera Cluster

Details

    • Bug
    • Status: Closed (View Workflow)
    • Blocker
    • Resolution: Fixed
    • 10.1.8
    • 10.1.9
    • Galera, Galera SST
    • Debian 8.2 netinst install
      MariaDB 10.1.8-MariaDB-1~jessie-log

    Description

      MariaDB 10.1.8 fails to join an existing MariaDB 10.0.21 cluster for migration.

      With the existing cluster environment up and running, I built two parallel VMs to test joining. Both have fresh installs from the Debian 8.2 netinst.iso. After ISO installation completed, SSH was installed for ease of access.

      From here, each of the VMs were configured per instructions on this page: https://downloads.mariadb.org/mariadb/repositories/

      The only difference in the two VMs is the reference to "10.0" and "10.1" in the source repository and the packages installed - "mariadb-galera-server" on 10.0 and "mariadb-server" on 10.1

      The following file was created with contents below on each VM: /etc/mysql/conf.d/galera.cnf

      [mysqld]
      log_slave_updates=1
      innodb_buffer_pool_size=768M

      [galera]
      wsrep_on=ON
      wsrep_provider=/usr/lib/galera/libgalera_smm.so
      wsrep_provider_options="gmcast.segment=3"
      wsrep_cluster_name="CLUSTERNAME"
      wsrep_cluster_address="gcomm://192.168.100.10"
      wsrep_sst_method=rsync
      binlog_format=ROW
      default-storage-engine=innodb
      innodb_autoinc_lock_mode=2
      bind-address=0.0.0.0

      After creating this file, the mariadb server was restarted on each VM.

      The MariaDB 10.0.21 VM joined the cluster without issue.

      The MariaDB 10.1.8 VM failed to join the cluster. Log file attached.

      Attachments

        Issue Links

          is caused by

          Task - A task that needs to be done. MDEV-8034 wsrep_node_address can't be ipv6

          • Major - Major loss of function.
          • Closed
          links to

          Web Link GitHub Pull Requset

          Activity

            Ascending order - Click to sort in descending order
            View 13 older comments
            nirbhay_c Nirbhay Choubey (Inactive) added a comment -

            https://github.com/MariaDB/server/commit/5079d69d48e2c1b763d23bdb294297e6d6da43a2

            nirbhay_c Nirbhay Choubey (Inactive) added a comment - https://github.com/MariaDB/server/commit/5079d69d48e2c1b763d23bdb294297e6d6da43a2
            nirbhay_c Nirbhay Choubey (Inactive) added a comment -

            darkain http://galeracluster.com/documentation-webpages/upgrading.html#id1

            nirbhay_c Nirbhay Choubey (Inactive) added a comment - darkain http://galeracluster.com/documentation-webpages/upgrading.html#id1
            nirbhay_c Nirbhay Choubey (Inactive) added a comment -

            jplindst Do you think its a real problem with the following errors showing up the error log, or can they be safely ignored?

            InnoDB: Error: Column last_update in table "mysql"."innodb_table_stats" is INT UNSIGNED NOT NULL but should be BINARY(4) NOT NULL (type mismatch).
            InnoDB: Error: Fetch of persistent statistics requested for table "my_database"."my_table" but the required system tables mysql.innodb_table_stats and mysql.innodb_index_stats are not present or have unexpected structure. Using transient stats instead.

            nirbhay_c Nirbhay Choubey (Inactive) added a comment - jplindst Do you think its a real problem with the following errors showing up the error log, or can they be safely ignored? InnoDB: Error: Column last_update in table "mysql"."innodb_table_stats" is INT UNSIGNED NOT NULL but should be BINARY(4) NOT NULL (type mismatch). InnoDB: Error: Fetch of persistent statistics requested for table "my_database"."my_table" but the required system tables mysql.innodb_table_stats and mysql.innodb_index_stats are not present or have unexpected structure. Using transient stats instead.
            jplindst Jan Lindström (Inactive) added a comment -

            These are not the real problem, looks more like a mysql_upgrade was not run.

            jplindst Jan Lindström (Inactive) added a comment - These are not the real problem, looks more like a mysql_upgrade was not run.
            darkain Vincent Milum Jr added a comment -

            Should mysql_upgrade be ran BEFORE or AFTER a rolling upgrade, or sometime during the middle? The main question here is how to properly have a mixed environment of 10.0 and 10.1 nodes during a rolling upgrade from one to the other, and whether this is officially supported, or if the entire cluster has to be taken offline to do the upgrade safely.

            darkain Vincent Milum Jr added a comment - Should mysql_upgrade be ran BEFORE or AFTER a rolling upgrade, or sometime during the middle? The main question here is how to properly have a mixed environment of 10.0 and 10.1 nodes during a rolling upgrade from one to the other, and whether this is officially supported, or if the entire cluster has to be taken offline to do the upgrade safely.

            People

              nirbhay_c Nirbhay Choubey (Inactive)
              darkain Vincent Milum Jr
              Votes:
              1 Vote for this issue
              Watchers:
              5 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.