-
Zhibo Zhang authored
Turn the remaining three `binlog*` options binlog_do_db, binlog_ignore_db, binlog_rows_event_max_size into global variables so that they can be visible from the SQL user level. This is for audit / secure configuration check purposes. Create new MTR tests to make sure that the newly created global variables can be visible from the command line interface. Behavior before the code change: MariaDB [(none)]> SHOW GLOBAL VARIABLES WHERE -> Variable_name LIKE 'binlog_do_db' OR -> Variable_name LIKE 'binlog_ignore_db' OR -> Variable_name LIKE 'binlog_row_event_max_size'; Empty set (0.001 sec) Behavior after the code change: MariaDB [(none)]> SHOW GLOBAL VARIABLES WHERE -> Variable_name LIKE 'binlog_do_db' OR -> Variable_name LIKE 'binlog_ignore_db' OR -> Variable_name LIKE 'binlog_row_event_max_size'; +---------------------------+-------+ | Variable_name | Value | +---------------------------+-------+ | binlog_do_db | | | binlog_ignore_db | | | binlog_row_event_max_size | 8192 | +---------------------------+-------+ 3 rows in set (0.001 sec) Note: For `binlog_do_db` and `binlog_ignore_db`, we add a new class `Sys_var_binlog_filter` to handle the dynamically-composable command line options for `binlog_do_db` and `binlog_ignore_db`. Below is the motivation: When the users start the server with the option --binlog-do-db="database1" --binlog-do-db="database2" The expected behavior is that the system should allow replication for both `database1` and `database2`, which is the logic of the original code. However, when turning the variables into system variables, the functionality does not exist any more, since system variables will only handle the last occurrence of the option, and in this case, the system will only be able to handle `database2`. Copyright: All new code of the whole pull request, including one or several files that are either new files or modified ones, are contributed under the BSD-new license. I am contributing on behalf of my employer Amazon Web Services, Inc.
34bbf37f