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

Galera SST scripts can't read mysqld_multi's [mysqldN] option groups

Details

    Description

      mysqld_multi uses special option groups with names like [mysqld1], [mysqld2], ..., [mysqldN].

      https://mariadb.com/kb/en/library/mysqld_multi/#option-groups

      It looks like SST scripts can't currently support these option groups. The only option group-related value it gets from the server is --defaults-group-suffix from the server, if that option was set for mysqld when the server was started:

      https://github.com/MariaDB/server/blob/93ac7ae70ff000353538f732899b421a3f2ea7ce/scripts/wsrep_sst_common.sh#L95

      https://github.com/MariaDB/server/blob/93ac7ae70ff000353538f732899b421a3f2ea7ce/scripts/wsrep_sst_common.sh#L196

      The SST script does not get told by the server to read these option groups, so this means that the SST script will fail to read options like innodb-data-home-dir when it is in a mysqld_multi option group like [mysqld1]:

      https://github.com/MariaDB/server/blob/93ac7ae70ff000353538f732899b421a3f2ea7ce/scripts/wsrep_sst_rsync.sh#L174

      https://github.com/MariaDB/server/blob/93ac7ae70ff000353538f732899b421a3f2ea7ce/scripts/wsrep_sst_mariabackup.sh#L710

      So maybe this problem could easily be fixed by changing mysqld_multi, so that it sets --defaults-group-suffix=N when it starts mysqld. For example, if you start instance number 1 with mysqld_multi, then it could pass --defaults-group-suffix=1 to mysqld, so that it reads group [mysqld1]. I believe that this should allow mysqld to also pass --defaults-group-suffix=N to the SST script, so that it also reads the proper option group.

      Currently, it does not look like the mysqld_multi script sets --defaults-group-suffix=N. Instead, the script reads all of the options from the [mysqldN] option group in the configuration file itself, and then passes those options to mysqld on the command-line:

      https://github.com/MariaDB/server/blob/93ac7ae70ff000353538f732899b421a3f2ea7ce/scripts/mysqld_multi.sh#L324

      It looks like the SST scripts currently need to be able to read the following variables from the [mysqldN] option groups:

      • innodb-data-home-dir

      https://github.com/MariaDB/server/blob/93ac7ae70ff000353538f732899b421a3f2ea7ce/scripts/wsrep_sst_rsync.sh#L174

      https://github.com/MariaDB/server/blob/93ac7ae70ff000353538f732899b421a3f2ea7ce/scripts/wsrep_sst_mariabackup.sh#L710

      • innodb-log-group-home-dir

      https://github.com/MariaDB/server/blob/93ac7ae70ff000353538f732899b421a3f2ea7ce/scripts/wsrep_sst_rsync.sh#L156

      https://github.com/MariaDB/server/blob/93ac7ae70ff000353538f732899b421a3f2ea7ce/scripts/wsrep_sst_mariabackup.sh#L955

      • innodb-undo-directory

      https://github.com/MariaDB/server/blob/93ac7ae70ff000353538f732899b421a3f2ea7ce/scripts/wsrep_sst_mariabackup.sh#L956

      • log-bin

      https://github.com/MariaDB/server/blob/93ac7ae70ff000353538f732899b421a3f2ea7ce/scripts/wsrep_sst_mariabackup.sh#L1034

      As an alternative fix, should they all be converted into command-line options that the server passes to the SST scripts, so that the SST scripts don't have to read them from the configuration file at all?

      Attachments

        Issue Links

          Activity

            I tried to correct all the shortcomings on the results of the review and made some small improvements to the patch itself - this is basic version for the 10.1 branch: https://github.com/MariaDB/server/commit/6e7407eea73e24b0b710bc7fcdfae8d266744d91

            sysprg Julius Goryavsky added a comment - I tried to correct all the shortcomings on the results of the review and made some small improvements to the patch itself - this is basic version for the 10.1 branch: https://github.com/MariaDB/server/commit/6e7407eea73e24b0b710bc7fcdfae8d266744d91

            ok to push in 10.1. Please then do 10.1->10.2 merge, retest and push. Similar thing should be done for 10.3 and 10.4.

            jplindst Jan Lindström (Inactive) added a comment - ok to push in 10.1. Please then do 10.1->10.2 merge, retest and push. Similar thing should be done for 10.3 and 10.4.

            After review and testing, the correction is applied to 10.1, 10.2, 10.3 and 10.4 branches

            sysprg Julius Goryavsky added a comment - After review and testing, the correction is applied to 10.1, 10.2, 10.3 and 10.4 branches

            I did not see this being applied to 10.2. On 10.1, this broke the debug build for me.

            I did the merge to 10.2. On my system, the += syntax that was added to scripts/wsrep_sst_common causes a failure of scripts/wsrep_sst_rsync, because in 10.2, that script is for /bin/sh (which is implemented by dash on Debian), not bash. I think that dependencies to Bash should be avoided, because a simpler shell should have a smaller overhead and fewer security holes.

            marko Marko Mäkelä added a comment - I did not see this being applied to 10.2. On 10.1, this broke the debug build for me . I did the merge to 10.2. On my system, the += syntax that was added to scripts/wsrep_sst_common causes a failure of scripts/wsrep_sst_rsync , because in 10.2, that script is for /bin/sh (which is implemented by dash on Debian), not bash . I think that dependencies to Bash should be avoided, because a simpler shell should have a smaller overhead and fewer security holes.

            I pushed a follow-up change that makes wsrep_sst_rsync use Bash instead of Bourne shell. The following Galera-related scripts are still declared to use the Bourne shell:

            • scripts/galera_new_cluster.sh
            • scripts/galera_recovery.sh
            • support-files/wsrep_notify.sh
            • mysql-test/std_data/wsrep_notify.sh (why does this exist, and why does it differ from the above?)

            The following Galera-related scripts depend on Bash:

            • scripts/wsrep_sst_mariabackup.sh
            • scripts/wsrep_sst_mysqldump.sh
            • scripts/wsrep_sst_rsync.sh
            • scripts/wsrep_sst_xtrabackup-v2.sh
            • scripts/wsrep_sst_xtrabackup.sh

            I see that MDEV-17835 in MariaDB 10.3.13 and 10.4.2 changed scripts/wsrep_sst_rsync.sh to use Bash instead of the Bourne shell. Only the 10.2 version was free from that dependency since MariaDB 10.2.3, which is when we applied spil’s contribution to remove Bash dependencies from the wsrep scripts.

            marko Marko Mäkelä added a comment - I pushed a follow-up change that makes wsrep_sst_rsync use Bash instead of Bourne shell. The following Galera-related scripts are still declared to use the Bourne shell: scripts/galera_new_cluster.sh scripts/galera_recovery.sh support-files/wsrep_notify.sh mysql-test/std_data/wsrep_notify.sh (why does this exist, and why does it differ from the above?) The following Galera-related scripts depend on Bash: scripts/wsrep_sst_mariabackup.sh scripts/wsrep_sst_mysqldump.sh scripts/wsrep_sst_rsync.sh scripts/wsrep_sst_xtrabackup-v2.sh scripts/wsrep_sst_xtrabackup.sh I see that MDEV-17835 in MariaDB 10.3.13 and 10.4.2 changed scripts/wsrep_sst_rsync.sh to use Bash instead of the Bourne shell. Only the 10.2 version was free from that dependency since MariaDB 10.2.3, which is when we applied spil ’s contribution to remove Bash dependencies from the wsrep scripts .

            People

              sysprg Julius Goryavsky
              GeoffMontee Geoff Montee (Inactive)
              Votes:
              1 Vote for this issue
              Watchers:
              7 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.