mysqld_multi uses special option groups with names like [mysqld1], [mysqld2], ..., [mysqldN].
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:
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]:
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:
It looks like the SST scripts currently need to be able to read the following variables from the [mysqldN] option groups:
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?