Commit 96a4f1f6 authored by unknown's avatar unknown

MDEV-4506: Parallel replication: Update some comments.

parent a09d2b10
...@@ -14,20 +14,14 @@ ...@@ -14,20 +14,14 @@
following transactions, so slave binlog position will be correct. following transactions, so slave binlog position will be correct.
And all the retry logic for temporary errors like deadlock. And all the retry logic for temporary errors like deadlock.
- Stopping the slave needs to handle stopping all parallel executions. And
the logic in sql_slave_killed() that waits for current event group to
complete needs to be extended appropriately...
- Audit the use of Relay_log_info::data_lock. Make sure it is held
correctly in all needed places also when using parallel replication.
- We need some user-configurable limit on how far ahead the SQL thread will - We need some user-configurable limit on how far ahead the SQL thread will
fetch and queue events for parallel execution (otherwise if slave gets fetch and queue events for parallel execution (otherwise if slave gets
behind we will fill up memory with pending malloc()'ed events). behind we will fill up memory with pending malloc()'ed events).
- Fix update of relay-log.info and master.info. In non-GTID replication, - In GTID replication, we should not need to update master.info and
they must be serialised to preserve correctness. In GTID replication, we relay-log.info on disk at all except at slave thread stop. They are not
should not update them at all except at slave thread stop. used to know where to restart, the updates are not crash-safe, and it
could negatively affect performance.
- All the waits (eg. in struct wait_for_commit and in - All the waits (eg. in struct wait_for_commit and in
rpl_parallel_thread_pool::get_thread()) need to be killable. And on kill, rpl_parallel_thread_pool::get_thread()) need to be killable. And on kill,
...@@ -39,10 +33,6 @@ ...@@ -39,10 +33,6 @@
slave rolls back the transaction; parallel execution needs to be able slave rolls back the transaction; parallel execution needs to be able
to deal with this wrt. commit_orderer and such. to deal with this wrt. commit_orderer and such.
- We should notice if the master doesn't support GTID, and then run in
single threaded mode against that master. This is needed to be able to
support multi-master-replication with old and new masters.
- Retry of failed transactions is not yet implemented for the parallel case. - Retry of failed transactions is not yet implemented for the parallel case.
*/ */
......
...@@ -891,6 +891,10 @@ void Relay_log_info::inc_group_relay_log_pos(ulonglong log_pos, ...@@ -891,6 +891,10 @@ void Relay_log_info::inc_group_relay_log_pos(ulonglong log_pos,
} else if (cmp == 0 && group_relay_log_pos < event_relay_log_pos) } else if (cmp == 0 && group_relay_log_pos < event_relay_log_pos)
group_relay_log_pos= event_relay_log_pos; group_relay_log_pos= event_relay_log_pos;
/*
In the parallel case we need to update the master_log_name here, rather
than in Rotate_log_event::do_update_pos().
*/
cmp= strcmp(group_master_log_name, rgi->future_event_master_log_name); cmp= strcmp(group_master_log_name, rgi->future_event_master_log_name);
if (cmp <= 0) if (cmp <= 0)
{ {
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment