mariadb

Tree: 25ede13611

Author	SHA1	Message	Date
Monty	895e9950b2	Fix for timeout in rpl.rpl_parallel_retry MDEV-17109 rpl.rpl_parallel_retry fails in buildbot with timeout I was not able to prove that this fix works, but at least it simplifies the problem as it removes some possible timing issues.	5 years ago
Andrei Elkin	30019a48bf	MDEV-12746 rpl.rpl_parallel_optimistic_nobinlog fails committing out of order at retry The test failures were of two sorts. One is that the number of retries what the slave thought as a temporary error exceeded the default value of the slave retry option. The 2nd issue was an out of order commit by transactions that were supposed to error out instead. Both issues are caused by the same reason that the post-temporary-error retry did not check possibly already existing error status. This is mended with refining conditions to retry. Specifically, a retrying worker checks `rpl_parallel_entry::stop_on_error_sub_id` that a potential failing predecessor could set to its own sub id. Now should the member be set the retrying follower errors out with ER_PRIOR_COMMIT_FAILED.	8 years ago
Sergey Vojtovich	282497dd6d	MDEV-6720 - enable connection log in mysqltest by default	10 years ago
Kristian Nielsen	26b1113032	MDEV-6917: Parallel replication: "Commit failed due to failure of an earlier commit on which this one depends", but no prior failure seen This bug was seen when parallel replication experienced a deadlock between transactions T1 and T2, where T2 has reached the commit phase and is waiting for T1 to commit first. In this case, the deadlock is broken by sending a kill to T2; that kill error is then later detected and converted to a deadlock error, which causes T2 to be rolled back and retried. The problem was that the kill caused ha_commit_trans() to errorneously call wakeup_subsequent_commits() on T3, signalling it to abort because T2 failed during commit. This is incorrect, because the error in T2 is only a temporary error, which will be resolved by normal transaction retry. We should not signal error to the next transaction until we have executed the code that handles such temporary errors. So this patch just removes the calls to wakeup_subsequent_commits() from ha_commit_trans(). They are incorrect in this case, and they are not needed in general, as wakeup_subsequent_commits() must in any case be called in finish_event_group() to wakeup any transactions that may have started to wait after ha_commit_trans(). And normally, wakeup will in fact have happened earlier, either from the binlog group commit code, or (in case of no binlogging) after the fast part of InnoDB/XtraDB group commit. The symptom of this bug was that replication would break on some transaction with "Commit failed due to failure of an earlier commit on which this one depends", but with no such failure of an earlier commit visible anywhere.	11 years ago
Kristian Nielsen	3dcd01e5e6	MDEV-7065: Incorrect relay log position in parallel replication after retry of transaction The retry of an event group in parallel replication set the wrong value for the end log position of the event that was retried (qev->future_event_relay_log_pos). It was too large by the size of the event, so it pointed into the middle of the following event. If the retry happened in the very last event of the event group, _and_ the SQL thread was stopped just after successfully retrying that event, then the SQL threads's relay log position would be left incorrect. Restarting the SQL thread could then try to read events from a garbage offset in the relay log, usually leading to an error about not being able to read the event.	11 years ago
unknown	787c470cef	MDEV-5262: Missing retry after temp error in parallel replication Handle retry of event groups that span multiple relay log files. - If retry reaches the end of one relay log file, move on to the next. - Handle refcounting of relay log files, and avoid purging relay log files until all event groups have completed that might have needed them for transaction retry.	12 years ago
unknown	d60915692c	MDEV-5262: Missing retry after temp error in parallel replication Implement that if first retry fails, we can do another attempt. Add testcases to test multi-retry that succeeds in second attempt, and multi-retry that eventually fails due to exceeding slave_trans_retries.	12 years ago
unknown	b0b60f2498	MDEV-5262: Missing retry after temp error in parallel replication Start implementing that an event group can be re-tried in parallel replication if it fails with a temporary error (like deadlock). Patch is very incomplete, just some very basic retry works. Stuff still missing (not complete list): - Handle moving to the next relay log file, if event group to be retried spans multiple relay log files. - Handle refcounting of relay log files, to ensure that we do not purge a relay log file and then later attempt to re-execute events out of it. - Handle description_event_for_exec - we need to save this somehow for the possible retry - and use the correct one in case it differs between relay logs. - Do another retry attempt in case the first retry also fails. - Limit the max number of retries. - Lots of testing will be needed for the various edge cases.	12 years ago

8 Commits (25ede13611b3c1f736be22fc581a0c371d212f61)