[MDEV-9049] Userstats stop populating using multiple replication threads Created: 2015-10-30  Updated: 2015-11-05  Resolved: 2015-11-05

Status: Closed
Project: MariaDB Server
Component/s: Admin statements
Affects Version/s: 10.0.21
Fix Version/s: N/A

Type: Bug Priority: Minor
Reporter: VAROQUI Stephane Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 1
Labels: None
Environment:

Linux X86_64


Attachments: PNG File close_thread_tables.png    

 Description   
  • Bringing back number of threads to 0 is a workaround

To reproduce:
Setup master slave replication

Produce some writes on the master

On the slave:
SET GLOBAL userstat=1;
SHOW TABLE_STATISTICS;

Statistics is populated

STOP SLAVE;
FLUSH TABLE_STATISTICS;
SET GLOBAL slave-parallel-threads=16;
START SLAVE;
SHOW TABLE_STATISTICS;

Statistics is not populated



 Comments   
Comment by Elena Stepanova [ 2015-11-02 ]

stephane@skysql.com,

It works all right for me:

connection slave;
stop slave;
 
# Enable userstat on slave
set global userstat=1;
start slave;
 
# Make sure the statistics is empty so far
show table_statistics;
Table_schema	Table_name	Rows_read	Rows_changed	Rows_changed_x_#indexes
connection master;
 
# Create some writes on master
create table t1 (i int);
insert into t1 values (1),(2),(3),(4);
drop table t1;
connection slave;
 
# Slave shows statistics
show table_statistics;
Table_schema	Table_name	Rows_read	Rows_changed	Rows_changed_x_#indexes
test	t1	0	4	4
mysql	gtid_slave_pos	1	4	4
stop slave;
flush table_statistics;
 
# Make sure the statistics is empty again after flush
show table_statistics;
Table_schema	Table_name	Rows_read	Rows_changed	Rows_changed_x_#indexes
 
# Enable parallel slave
set global slave_parallel_threads=16;
start slave;
connection master;
 
# Create the same writes again
create table t1 (i int);
insert into t1 values (1),(2),(3),(4);
drop table t1;
connection slave;
 
# Slave shows statistics
show table_statistics;
Table_schema	Table_name	Rows_read	Rows_changed	Rows_changed_x_#indexes
test	t1	0	4	4
mysql	gtid_slave_pos	4	8	8

In your description I don't see a step when you created more writes on master after you enabled parallel slave – are you sure you did that?

MTR test case for the above

--source include/master-slave.inc
--source include/have_binlog_format_statement.inc
 
--enable_connect_log
 
--connection slave
stop slave;
--echo
--echo # Enable userstat on slave
set global userstat=1;
start slave;
--echo 
--echo # Make sure the statistics is empty so far
show table_statistics;
 
--connection master
--echo 
--echo # Create some writes on master
create table t1 (i int);
insert into t1 values (1),(2),(3),(4);
drop table t1;
 
--sync_slave_with_master
 
--echo 
--echo # Slave shows statistics
show table_statistics;
stop slave;
flush table_statistics;
--echo 
--echo # Make sure the statistics is empty again after flush
show table_statistics;
--echo 
--echo # Enable parallel slave
set global slave_parallel_threads=16;
start slave;
 
--connection master
--echo 
--echo # Create the same writes again
create table t1 (i int);
insert into t1 values (1),(2),(3),(4);
drop table t1;
 
--sync_slave_with_master
 
--echo 
--echo # Slave shows statistics
show table_statistics;

Comment by VAROQUI Stephane [ 2015-11-02 ]

Writes was heavy about 200/s, and replication was delayed , that's why we activated

  • userstat , to catch bad update , delete , QP
  • parallel replication to catch more aggressively

from what i recall
binlog_format=STATEMENT
replication was not using GTID

user stats are updated in function close_thread_tables via calling handler::update_global_table_stats() in handler.cc
Attached call graph close_thread_tables.

This close_thread_tables for replication happen in repl_rli.cc could it be that parallel does not follow the same path for relay log info and thus shortcut call to close_thread_tables?

Comment by VAROQUI Stephane [ 2015-11-02 ]

Elena,

I 'll contact the client to see if he can still reproduce that on his setup.
Thanks for trying to reproduce.

Comment by VAROQUI Stephane [ 2015-11-02 ]

Can be clause, unable to reproduce, we may have been confused by the requirement to stop, start slave to take into account userstat variable change.

Generated at Thu Feb 08 07:31:45 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.