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/rpl/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.

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/rpl/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 for investigation issues because we can't know which role the server was started with. Solution: 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. ex usage: SHOW STATUS LIKE 'init_rpl_role'; SHOW GLOBAL STATUS LIKE 'init_rpl_role';

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.

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/rpl/t/init_rpl_role_variable_basic.test Show resolved Hide resolved

mysql-test/suite/rpl/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

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!

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!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

Mahmoud-kh1 commented Apr 4, 2026 •

edited

Loading

ParadoxV5 Apr 7, 2026 •

edited

Loading

ParadoxV5 Apr 7, 2026 •

edited

Loading