[MDEV-29419] Unable to change persistently slave_parallel_mode Created: 2022-08-31  Updated: 2023-11-28

Status: Confirmed
Project: MariaDB Server
Component/s: Replication
Affects Version/s: 10.3, 10.4, 10.5, 10.6, 10.7, 10.8, 10.9, 10.10
Fix Version/s: 10.4, 10.5, 10.6

Type: Bug Priority: Major
Reporter: Jozef Kováč Assignee: Brandon Nesterenko
Resolution: Unresolved Votes: 0
Labels: None
Environment:

RHEL 8.6

Attachments: File mdev29419.cnf     File mdev29419.result     File mdev29419.test     Text File variables.txt    

 Description   

After updating MariaDB 10.4 to 10.5 there are lots of retried transaction(few thousand per hour) and lags in replication, switching slave_parallel_mode from optimistic back to conservative as was default on MariaDB 10.4 helps.

I stop replication change every slave connection to "conservative" and start, also change server global variable slave_parallel_mode to "conservative" and add "slave_parallel_mode = conservative" to my.cnf but after server restart all conection are again in "optimistic" mode global variable is correctly set to "conservative".

MTR test case and cnf

--source include/not_embedded.inc
 
 
 
--connect (slave1,127.0.0.1,root,,,$SERVER_MYPORT_3)
 
--connect (master1,127.0.0.1,root,,,$SERVER_MYPORT_1)
 
--connect (master2,127.0.0.1,root,,,$SERVER_MYPORT_2)
 
 
 
--connection slave1
 
--replace_result $SERVER_MYPORT_1 MYPORT_1
 
eval CHANGE MASTER 'x1' TO master_port=$SERVER_MYPORT_1, master_host='127.0.0.1', master_user='root';
 
eval CHANGE MASTER '' TO master_port=$SERVER_MYPORT_2, master_host='127.0.0.1', master_user='root';
 
 
 
set default_master_connection = '';
 
--source include/start_slave.inc
 
--let $status_items= Parallel_Mode
 
# will show minimal
 
--source include/show_slave_status.inc
 
 
 
set default_master_connection = 'x1';
 
--source include/start_slave.inc
 
--let $status_items= Parallel_Mode
 
# should be minimal, but shows optimistic (>=10.5) or conservative (<10.5)
 
--source include/show_slave_status.inc
 
 
 
--source include/reset_master_slave.inc
 
--disconnect slave1
 
 
 
--connection master1
 
--source include/reset_master_slave.inc
 
--disconnect master1
 
 
 
--connection master2
 
--source include/reset_master_slave.inc
 
--disconnect master2


!include my.cnf
 
 
 
[mysqld.3]
 
slave_parallel_mode=minimal



 Comments   
Comment by Angelique Sklavounos (Inactive) [ 2022-09-05 ]

Hi lathander,

Thank you for your report. Unfortunately, I cannot seem to reproduce the issue. I have a few questions...

I stop replication change every slave connection

  • How many slaves are there? How are they connected?
  • What is the exact command being used?

but after server restart all conection are again in "optimistic" mode

  • What exact command do you use to check for this?

And a general request:

  • Could you please also share the output of show variables; ?

Thank you.

Comment by Jozef Kováč [ 2022-09-05 ]

exact commands:

SHOW ALL SLAVES STATUS\G # showing optimistic

STOP ALL SLAVES;
SET GLOBAL x3.slave_parallel_mode = 'conservative';
SET GLOBAL x4.slave_parallel_mode = 'conservative';
SET GLOBAL x5.slave_parallel_mode = 'conservative';
START ALL SLAVES;

SHOW ALL SLAVES STATUS\G # showing conservative and retry count stop increasing

Comment by Angelique Sklavounos (Inactive) [ 2022-09-05 ]

Thanks, lathander, I now understand the behavior you are seeing. I believe it is intentional, but I am looking into it...

Comment by Angelique Sklavounos (Inactive) [ 2022-09-06 ]

I believe it is intentional, but I am looking into it...

I thought this might be due to the text in this page: https://mariadb.com/kb/en/multi-source-replication/

The new replication variable default_master_connection specifies which connection will be used for commands and variables if you don't specify a connection. By default this is '' (the default connection name).

But after some consultation with Elkin, it should be expected that setting slave_parallel_mode in the .cnf file would apply for all connections.

I've attached a test case for the desired behavior.

Generated at Thu Feb 08 10:08:26 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.