MDEV-38202: make init_rpl_role visible at runtime by Mahmoud-kh1 · Pull Request #4904 · MariaDB/server

Mahmoud-kh1 · 2026-04-04T15:59:10Z

This PR adds a new feature to see the server’s initial replication role at runtime.

I added a new read-only status variable init_rpl_role that captures the value of rpl_status right after startup and keeps it unchanged.

Reason
Previously, init_rpl_role could be set in the cnf file but was not visible in runtime which will be helpful for investigating issues as it will allow us to see with which value mariadb was started.

Tests :
Added basic tests to verify that init_rpl_role is correctly set at startup and displayed properly.

gkodinov

Thank you for your contribution! This is a preliminary review.

Please, in addition to the notes below:

add a commit message to your commit explaining what it is that you do
update the Jira with a complete description of what the new variable is (data type, validity period, purpose), when and how it can be set, etc. : helps documenting it.
Make sure that there are no failing buildbot hosts.

mysql-test/suite/sys_vars/t/init_rpl_role_variable_basic.test

gkodinov · 2026-04-06T07:48:40Z

mysql-test/suite/sys_vars/t/init_rpl_role_variable_basic.test

+
+--echo # it should show in INFORMATION_SCHEMA.GLOBAL_VARIABLES  
+SELECT * FROM INFORMATION_SCHEMA.GLOBAL_VARIABLES  
+  WHERE VARIABLE_NAME = 'init_rpl_role'; 


Please always terminate the last line with a new line.

We also customarily add a --echo # End of MA.MI tests at the end: helps conflict resolution when merging up and down.

gkodinov · 2026-04-06T07:50:49Z

sql/sys_vars.cc

       NOT_IN_BINLOG, ON_CHECK(check_init_string));

+#ifdef HAVE_REPLICATION 
+static Sys_var_enum Sys_init_rpl_role(  


Feel free to leave that to the final reviewer. But: is there any specific reason this should be a system variable?
It's read only at runtime and not settable via the command line/config file at startup. So, in essence, you can only read it. So why not make this a status variable?

I just make it system variable to support this syntax
SELECT @@global.init_rpl_role;
SELECT @@init_rpl_role;

again, why? what's better about this syntax compared to SHOW GLOBAL STATUS LIKE 'init_rpl_role' ?

I thought it will be just a nice bonus :) , I will turn it to status variable as you suggested.

I stumbled upon the System & Status Variables Guide.

In general, I believe this should be a system variable, as it’s associated with a mode configuration rather than a status report.

In theory, it is possible to make --init-rpl-role mutable during runtime for recovering complex Semi-Sync networks/situations.
But in practice, --init-rpl-role doesn’t scale. (see also MDEV-34878)

FWIW, I've requested that this is a status variable for the following reasons:

I've assumed that a value will never be assigned directly to it.

Status variables are more light-weight than system variables: less locking needed etc.

I personally find a non-settable system variable to be an abomination and a gotcha: why would you put something non-settable in a settable variables namespace?

This said, it's your review and your codebase. So feel free to ignore the above or not.

I've assumed that a value will never be assigned directly to it.

Status variables are more light-weight than system variables: less locking needed etc.

I personally find a non-settable system variable to be an abomination and a gotcha: why would you put something non-settable in a settable variables namespace?

There are existing global read-only variables.
But yes, the system variables system should solve these missed optimizations.

Hi @ParadoxV5 I return it back to be a system variable .

gkodinov · 2026-04-06T07:51:20Z

sql/sys_vars.cc

+       "The replication role that the server was started with. "  
+        "Possible values are MASTER and SLAVE", 
+       READ_ONLY GLOBAL_VAR(init_rpl_role_val), NO_CMD_LINE,  
+       rpl_role_type, DEFAULT(RPL_AUTH_MASTER));  


Do you really need a default here? You're going to always set it.

I see rp_status has it as default value so I follow it

What I implied is that you will never see this default value. So you might just as well put 0 here.

gkodinov

Thank you for making it a status variable!

Some cleanups below. And then it's ready.

mysql-test/suite/sys_vars/t/init_rpl_role_variable_basic.test

ParadoxV5 · 2026-04-07T21:36:23Z

sql/sys_vars.cc

       NOT_IN_BINLOG, ON_CHECK(check_init_string));

+#ifdef HAVE_REPLICATION 
+static Sys_var_enum Sys_init_rpl_role(  


I stumbled upon the System & Status Variables Guide.

In general, I believe this should be a system variable, as it’s associated with a mode configuration rather than a status report.

In theory, it is possible to make --init-rpl-role mutable during runtime for recovering complex Semi-Sync networks/situations.
But in practice, --init-rpl-role doesn’t scale. (see also MDEV-34878)

gkodinov

LGTM. Thank you for your work. Please stay tuned for the final review.

ParadoxV5

Thanks and well done on the first-time contribution, @Mahmoud-kh1!

ParadoxV5 · 2026-04-10T19:56:21Z

sql/sys_vars.cc

+       "The replication role that the server was started with"  
+       "Possible values are MASTER and SLAVE",  
+       READ_ONLY GLOBAL_VAR(init_rpl_role_val), NO_CMD_LINE,  
+       rpl_role_type, DEFAULT(RPL_AUTH_MASTER));  


Recommendation: Move --init-rpl-role from sql/mysqld.cc here.

Suggested change

"The replication role that the server was started with"

"Possible values are MASTER and SLAVE",

READ_ONLY GLOBAL_VAR(init_rpl_role_val), NO_CMD_LINE,

rpl_role_type, DEFAULT(RPL_AUTH_MASTER));

"Set the replication role <insert mention of semi-sync recovery here>"

READ_ONLY GLOBAL_VAR(init_rpl_role_val), CMD_LINE(REQUIRED_ARG),

rpl_role_type, DEFAULT(RPL_AUTH_MASTER));

(I’m surprised to see --init-rpl-role hooked directly onto the status variable Rpl_status in sql/mysqld.cc, which changes live and is most likely not what users expect @@init_rpl_role to be, if not Semi-Sync Recovery itself…
Not to mention finer Rpl_status alternatives in SHOW REPLICA STATUS.)

Hint: How should rpl_status (status variable Rpl_status) be initialized, now that you’ve unregistered it in sql/mysqld.cc?

yeah I see , I should assign it to the new variable I made now it will never be updated :)

mysql-test/suite/sys_vars/t/init_rpl_role_variable_basic.test

ParadoxV5 · 2026-04-10T20:14:19Z

mysql-test/suite/sys_vars/t/init_rpl_role_variable_basic.test

Please add test-to-fails for not SESSION scope and Read-only as well.

💭(Why? Because they aren’t merely “alternative syntaxes”… I wonder if all these _basic.tests could’ve instead been a single information_schema.system_variables-based script similar to sys_vars.sysvars_server_notembedded. reference)

The test LGTM except… nits. These double-blankline separators, upper/lower case inconsistencies, and sentences without capitalization and full stops itch me.

ok , I will clean it now.

ParadoxV5 · 2026-04-11T20:59:06Z

sql/sys_vars.cc

+       "The replication role that the server was started with"  
+       "Possible values are MASTER and SLAVE",  
+       READ_ONLY GLOBAL_VAR(init_rpl_role_val), NO_CMD_LINE,  
+       rpl_role_type, DEFAULT(RPL_AUTH_MASTER));  


Hint: How should rpl_status (status variable Rpl_status) be initialized, now that you’ve unregistered it in sql/mysqld.cc?

ParadoxV5 · 2026-04-11T21:03:21Z

mysql-test/suite/sys_vars/t/init_rpl_role_variable_basic.test

The test LGTM except… nits. These double-blankline separators, upper/lower case inconsistencies, and sentences without capitalization and full stops itch me.

mysql-test/main/mysqld--help.result

ParadoxV5

Are you still cleaning up?

The expected results of sys_vars.sysvars_server_notembedded and main.mysqld--help tests need updates to match the new refined description.
You can have path/to/mtr --record suite_name.test_name rewrite the results if you don’t like manual copy-pastes.

While there, some small details that I missed last time:

Your added lines have numerous (unnecessary) trailing spaces. Please clean them up.
Re. the commit message
- It still says “status variable” 😄.
- The last paragraph of your commit message (added later?) exceeds the guidelines.
  I suggest breaking the line up:
```
Example usage:
* SHOW GLOBAL VARIABLES LIKE 'init_rpl_role'
* SELECT @@GLOBAL.init_rpl_role;
```
- Would you like to include the reviewers?
```
Reviewed-by: ParadoxV5 <paradox.ver5@gmail.com>
Reviewed-by: Georgi (Joro) Kodinov <joro@mariadb.org>
```
- Nit: doubled space in … investigation issues because

ParadoxV5 · 2026-04-12T20:36:56Z

mysql-test/suite/sys_vars/t/init_rpl_role_variable_basic.test

+--echo # MDEV-38202: add init_rpl_role in output of "show variables"   
+--echo #  
+
+--echo # it should show SLAVE as it is set in opt file


Suggested change

--echo # it should show SLAVE as it is set in opt file

--echo # It should show SLAVE as it is set in the .opt file.

mysql-test/suite/sys_vars/t/init_rpl_role_variable_basic.test

Problem: The --init-rpl-role option can be set in the .cnf file or command line to configure the server replication role at startup (MASTER or SLAVE), but there was no way to check this value at runtime. This made it hard to investigate issues because we could not know which role the server was started with. Solution: I added a new read-only system variable init_rpl_role that is set after startup and kept unchanged. Example usage: * SHOW GLOBAL VARIABLES LIKE 'init_rpl_role' * SELECT @@GLOBAL.init_rpl_role Reviewed-by: ParadoxV5 <paradox.ver5@gmail.com> Reviewed-by: Georgi (Joro) Kodinov <joro@mariadb.org>

Mahmoud-kh1 force-pushed the init_rpl_role branch 6 times, most recently from f6f6a30 to 029860e Compare April 4, 2026 17:30

gkodinov added the External Contribution All PRs from entities outside of MariaDB Foundation, Corporation, Codership agreements. label Apr 6, 2026

gkodinov requested changes Apr 6, 2026

View reviewed changes

gkodinov self-assigned this Apr 7, 2026

Mahmoud-kh1 force-pushed the init_rpl_role branch 3 times, most recently from 1979739 to 8795f3b Compare April 7, 2026 12:17

Mahmoud-kh1 changed the title ~~MDEV-38202: add init_rpl_role in SHOW VARIABLES~~ MDEV-38202: make init_rpl_role visible at runtime Apr 7, 2026

Mahmoud-kh1 requested a review from gkodinov April 7, 2026 12:51

gkodinov requested changes Apr 7, 2026

View reviewed changes

mysql-test/suite/sys_vars/t/init_rpl_role_variable_basic.test Outdated Show resolved Hide resolved

mysql-test/suite/sys_vars/t/init_rpl_role_variable_basic.test Show resolved Hide resolved

Mahmoud-kh1 force-pushed the init_rpl_role branch from 8795f3b to 648ee9c Compare April 7, 2026 13:24

Mahmoud-kh1 requested a review from gkodinov April 7, 2026 13:25

ParadoxV5 requested changes Apr 7, 2026

View reviewed changes

ParadoxV5 self-assigned this Apr 7, 2026

gkodinov approved these changes Apr 8, 2026

View reviewed changes

Mahmoud-kh1 force-pushed the init_rpl_role branch from 648ee9c to c732a37 Compare April 10, 2026 11:13

Mahmoud-kh1 requested a review from ParadoxV5 April 10, 2026 12:07

ParadoxV5 reviewed Apr 10, 2026

View reviewed changes

Mahmoud-kh1 force-pushed the init_rpl_role branch 2 times, most recently from 98393ff to d9aa486 Compare April 11, 2026 20:59

ParadoxV5 requested changes Apr 11, 2026

View reviewed changes

Mahmoud-kh1 force-pushed the init_rpl_role branch 3 times, most recently from 37a4765 to e74a17c Compare April 11, 2026 22:09

Mahmoud-kh1 requested a review from ParadoxV5 April 11, 2026 22:13

ParadoxV5 reviewed Apr 12, 2026

View reviewed changes

Mahmoud-kh1 force-pushed the init_rpl_role branch 4 times, most recently from 5c4cdcd to 839be78 Compare April 13, 2026 01:00

Mahmoud-kh1 force-pushed the init_rpl_role branch from 839be78 to 8f83b3b Compare April 13, 2026 01:17

Mahmoud-kh1 requested a review from ParadoxV5 April 13, 2026 01:48

	--echo # it should show SLAVE as it is set in opt file
	--echo # It should show SLAVE as it is set in the .opt file.

Uh oh!

Conversation

Mahmoud-kh1 commented Apr 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gkodinov left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ParadoxV5 Apr 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gkodinov left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

ParadoxV5 Apr 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gkodinov left a comment

Choose a reason for hiding this comment

Uh oh!

ParadoxV5 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ParadoxV5 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Mahmoud-kh1 commented Apr 4, 2026 •

edited

Loading

ParadoxV5 Apr 7, 2026 •

edited

Loading

ParadoxV5 Apr 7, 2026 •

edited

Loading

ParadoxV5 left a comment •

edited

Loading