diff options
Diffstat (limited to 'sql/slave.h')
| -rw-r--r-- | sql/slave.h | 52 |
1 files changed, 25 insertions, 27 deletions
diff --git a/sql/slave.h b/sql/slave.h index 016944534f7..f4080f3ca8d 100644 --- a/sql/slave.h +++ b/sql/slave.h @@ -35,12 +35,19 @@ /* MUTEXES in replication: - LOCK_active_mi: this is meant for multimaster, when we can switch from a - master to another. It protects active_mi. We don't care of it for the moment, - as active_mi never moves (it's created at startup and deleted at shutdown, - and not changed: it always points to the same MASTER_INFO struct), because we - don't have multimaster. So for the moment, mi does not move, and mi->rli does - not either. + LOCK_active_mi: [note: this was originally meant for multimaster, to switch + from a master to another, to protect active_mi] It is used to SERIALIZE ALL + administrative commands of replication: START SLAVE, STOP SLAVE, CHANGE + MASTER, RESET SLAVE, end_slave() (when mysqld stops) [init_slave() does not + need it it's called early]. Any of these commands holds the mutex from the + start till the end. This thus protects us against a handful of deadlocks + (consider start_slave_thread() which, when starting the I/O thread, releases + mi->run_lock, keeps rli->run_lock, and tries to re-acquire mi->run_lock). + + Currently active_mi never moves (it's created at startup and deleted at + shutdown, and not changed: it always points to the same MASTER_INFO struct), + because we don't have multimaster. So for the moment, mi does not move, and + mi->rli does not either. In MASTER_INFO: run_lock, data_lock run_lock protects all information about the run state: slave_running, and the @@ -51,6 +58,9 @@ In RELAY_LOG_INFO: run_lock, data_lock see MASTER_INFO + Order of acquisition: if you want to have LOCK_active_mi and a run_lock, you + must acquire LOCK_active_mi first. + In MYSQL_LOG: LOCK_log, LOCK_index of the binlog and the relay log LOCK_log: when you write to it. LOCK_index: when you create/delete a binlog (so that you have to update the .index file). @@ -67,20 +77,7 @@ extern my_bool opt_log_slave_updates; extern ulonglong relay_log_space_limit; struct st_master_info; -/* - TODO: this needs to be redone, but for now it does not matter since - we do not have multi-master yet. -*/ - -#define LOCK_ACTIVE_MI { pthread_mutex_lock(&LOCK_active_mi); \ - ++active_mi_in_use; \ - pthread_mutex_unlock(&LOCK_active_mi);} - -#define UNLOCK_ACTIVE_MI { pthread_mutex_lock(&LOCK_active_mi); \ - --active_mi_in_use; \ - pthread_mutex_unlock(&LOCK_active_mi); } - -/***************************************************************************** +/**************************************************************************** Replication SQL Thread @@ -203,14 +200,16 @@ typedef struct st_relay_log_info bool ignore_log_space_limit; /* - InnoDB internally stores the master log position it has processed - so far; when the InnoDB code to store this position is called, we have not - updated rli->group_master_log_pos yet. So the position is the event's - log_pos (the position of the end of the event); we save it in the variable - below. It's the *coming* group_master_log_pos (the one which will be - group_master_log_pos in the coming milliseconds). + When it commits, InnoDB internally stores the master log position it has + processed so far; the position to store is the one of the end of the + committing event (the COMMIT query event, or the event if in autocommit + mode). */ +#if MYSQL_VERSION_ID < 40100 + ulonglong future_master_log_pos; +#else ulonglong future_group_master_log_pos; +#endif time_t last_master_timestamp; @@ -574,7 +573,6 @@ extern "C" pthread_handler_decl(handle_slave_io,arg); extern "C" pthread_handler_decl(handle_slave_sql,arg); extern bool volatile abort_loop; extern MASTER_INFO main_mi, *active_mi; /* active_mi for multi-master */ -extern volatile int active_mi_in_use; extern LIST master_list; extern HASH replicate_do_table, replicate_ignore_table; extern DYNAMIC_ARRAY replicate_wild_do_table, replicate_wild_ignore_table; |