Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
M
mariadb
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
Kirill Smelkov
mariadb
Commits
96a4f1f6
Commit
96a4f1f6
authored
Oct 24, 2013
by
unknown
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
MDEV-4506: Parallel replication: Update some comments.
parent
a09d2b10
Changes
2
Hide whitespace changes
Inline
Side-by-side
Showing
2 changed files
with
8 additions
and
14 deletions
+8
-14
sql/rpl_parallel.cc
sql/rpl_parallel.cc
+4
-14
sql/rpl_rli.cc
sql/rpl_rli.cc
+4
-0
No files found.
sql/rpl_parallel.cc
View file @
96a4f1f6
...
...
@@ -14,20 +14,14 @@
following transactions, so slave binlog position will be correct.
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
fetch and queue events for parallel execution (otherwise if slave gets
behind we will fill up memory with pending malloc()'ed events).
- Fix update of relay-log.info and master.info. In non-GTID replication,
they must be serialised to preserve correctness. In GTID replication, we
should not update them at all except at slave thread stop.
- In GTID replication, we should not need to update master.info and
relay-log.info on disk at all except at slave thread stop. They are not
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
rpl_parallel_thread_pool::get_thread()) need to be killable. And on kill,
...
...
@@ -39,10 +33,6 @@
slave rolls back the transaction; parallel execution needs to be able
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.
*/
...
...
sql/rpl_rli.cc
View file @
96a4f1f6
...
...
@@ -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
)
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
);
if
(
cmp
<=
0
)
{
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment