comments about mutexes in replication.

Don't start the SQL slave thread with SQL_BIG_SELECTS;
it's better to inhibate max_join_size instead.

1 files changed, 24 insertions, 0 deletions

diff --git a/sql/slave.h b/sql/slave.h
index 19411aba497..67bf009763b 100644
--- a/sql/slave.h
+++ b/sql/slave.h
@@ -24,6 +24,30 @@
   having to re-read the master updates.
  */
 
+/*
+  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.
+
+  In MASTER_INFO: run_lock, data_lock
+  run_lock protects all information about the run state: slave_running, and the
+  existence of the I/O thread (to stop/start it, you need this mutex).
+  data_lock protects some moving members of the struct: counters (log name,
+  position) and relay log (MYSQL_LOG object).
+
+  In RELAY_LOG_INFO: run_lock, data_lock
+  see MASTER_INFO
+  
+  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).
+*/
+
 extern ulong slave_net_timeout, master_retry_count;
 extern MY_BITMAP slave_error_mask;
 extern bool use_slave_mask;