Details
-
Task
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
Description
From MDEV-6457 was a suggestion for a status variable to report slave_skipped_errors.
Wasn't sure if I needed a mutex around this to account for potential parallel replication error faults occurring at the same time (probably yes).
attached patch against 10.0.15-trunk
Attachments
Issue Links
- relates to
-
-
- Open
-
Activity
| Summary | status variable for Slave_skipped_errors | [PATCH] status variable for Slave_skipped_errors |
| Fix Version/s | 10.1 [ 16100 ] |
| Assignee | Kristian Nielsen [ knielsen ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Status | In Progress [ 3 ] | Stalled [ 10000 ] |
| Priority | Minor [ 4 ] | Major [ 3 ] |
| Status | Stalled [ 10000 ] | In Progress [ 3 ] |
The patch changes file mysql-test/suite/engines/funcs/t/rpl_variables.test,
but not mysql-test/suite/engines/funcs/t/rpl_variables.result. Sounds like you
never actually ran this test?
(I'm not sure what the engines/funcs/ suite is actually used for, you should
double-check that or maybe better make the test in another place, like
mysql-test/suite/rpl/ for example).
Please also make sure that the tests actually fail with the code part of the
patch missing, and that it tests most important part of the functionality.
Also, please write up some text suitable for documentation in the
knowledge base.
The code part of the patch looks good now, I think, using statistic_increment
seems appropriate.
| Status | In Progress [ 3 ] | Stalled [ 10000 ] |
I've merged it into 10.1 and pushed to bb-10.1-knielsen for a buidbot run.
If everything looks ok, I'll push to main 10.1 tomorrow.
| Status | Stalled [ 10000 ] | In Progress [ 3 ] |
| Fix Version/s | 10.1.4 [ 18400 ] | |
| Fix Version/s | 10.1 [ 16100 ] | |
| Resolution | Fixed [ 1 ] | |
| Status | In Progress [ 3 ] | Closed [ 6 ] |
| Workflow | MariaDB v2 [ 58718 ] | MariaDB v3 [ 65294 ] |
I wonder if it's been done on purpose that FLUSH STATUS does not reset the value. Either way is reasonable, so I don't have a strong opinion about it, just something to note.
really? it isn't of type SHOW_LONG_NOFLUSH so it looks like sql_show.cc:reset_status_vars would reset this like other LONG global status variables.
And yet..
[connection master]
|
create table t1 (pk int primary key);
|
connection slave;
|
|
|
############### Initial status
|
show global status like 'Slave_skipped_errors';
|
Variable_name Value
|
Slave_skipped_errors 0
|
show global status like 'Table_locks_immediate';
|
Variable_name Value
|
Table_locks_immediate 44
|
###############
|
|
|
insert into t1 values (1);
|
connection master;
|
insert into t1 values (1);
|
connection slave;
|
|
|
############### After one skipped error
|
show global status like 'Slave_skipped_errors';
|
Variable_name Value
|
Slave_skipped_errors 1
|
show global status like 'Table_locks_immediate';
|
Variable_name Value
|
Table_locks_immediate 47
|
###############
|
|
|
flush status;
|
|
|
############### Locks are flushed, but the skipped error isn't
|
show global status like 'Slave_skipped_errors';
|
Variable_name Value
|
Slave_skipped_errors 1
|
show global status like 'Table_locks_immediate';
|
Variable_name Value
|
Table_locks_immediate 0
|
###############
|
|
|
connection master;
|
drop table t1;
|
connection slave;
|
connection master;
|
ah type SHOW_LONGLONG for Slave_skipped_errors and only SHOW_LONG get reset.
I guess someone made a decision a while ago that big vars weren't to be reset.
well noted.
| Workflow | MariaDB v3 [ 65294 ] | MariaDB v4 [ 132467 ] |
> Wasn't sure if I needed a mutex around this to account for potential
> parallel replication error faults occurring at the same time (probably yes).
Yes, you will need a mutex when setting and reading. Or you can use an atomic
increment and corresponding atomic read.
It's not just for parallel replication, also for multi-source.