105
107
"Waiting to reconnect after a failed binlog dump request",
106
108
"Slave I/O thread killed while retrying master dump",
107
109
"Reconnecting after a failed binlog dump request",
108
"failed dump request, reconnecting to try again, log '%s' at postion %s",
110
"failed dump request, reconnecting to try again, log '%s' at position %s",
109
111
"COM_BINLOG_DUMP",
110
112
"Slave I/O thread killed during or after reconnect"
408
410
int error,force_all = (thread_mask & SLAVE_FORCE_ALL);
409
411
pthread_mutex_t *sql_lock = &mi->rli.run_lock, *io_lock = &mi->run_lock;
413
if (thread_mask & (SLAVE_SQL|SLAVE_FORCE_ALL))
415
DBUG_PRINT("info",("Terminating SQL thread"));
416
mi->rli.abort_slave=1;
417
if ((error=terminate_slave_thread(mi->rli.sql_thd, sql_lock,
419
&mi->rli.slave_running,
411
424
if (thread_mask & (SLAVE_IO|SLAVE_FORCE_ALL))
413
426
DBUG_PRINT("info",("Terminating IO thread"));
596
598
DBUG_PRINT("sleep",("Waiting for slave thread to start"));
597
599
const char* old_msg = thd->enter_cond(start_cond,cond_lock,
598
600
"Waiting for slave thread to start");
599
pthread_cond_wait(start_cond,cond_lock);
601
pthread_cond_wait(start_cond, cond_lock);
600
602
thd->exit_cond(old_msg);
601
603
pthread_mutex_lock(cond_lock); // re-acquire it as exit_cond() released
607
pthread_mutex_unlock(start_lock);
603
608
DBUG_RETURN(thd->killed_errno());
740
746
DBUG_ASSERT(rli->slave_running == 1);// tracking buffer overrun
741
747
if (abort_loop || thd->killed || rli->abort_slave)
750
The transaction should always be binlogged if OPTION_KEEP_LOG is set
751
(it implies that something can not be rolled back). And such case
752
should be regarded similarly as modifing a non-transactional table
753
because retrying of the transaction will lead to an error or inconsistency
755
Example: OPTION_KEEP_LOG is set if a temporary table is created or dropped.
743
757
if (rli->abort_slave && rli->is_in_group() &&
744
thd->transaction.all.modified_non_trans_table)
758
(thd->transaction.all.modified_non_trans_table ||
759
(thd->options & OPTION_KEEP_LOG)))
747
762
If we are in an unsafe situation (stopping could corrupt replication),
3035
3051
pthread_mutex_lock(&rli->data_lock);
3036
3052
if (rli->slave_skip_counter)
3039
pos= strmake(saved_log_name, rli->group_relay_log_name, FN_REFLEN - 1);
3041
pos= strmake(saved_master_log_name, rli->group_master_log_name, FN_REFLEN - 1);
3054
strmake(saved_log_name, rli->group_relay_log_name, FN_REFLEN - 1);
3055
strmake(saved_master_log_name, rli->group_master_log_name, FN_REFLEN - 1);
3043
3056
saved_log_pos= rli->group_relay_log_pos;
3044
3057
saved_master_log_pos= rli->group_master_log_pos;
3045
3058
saved_skip= rli->slave_skip_counter;
4352
4365
DBUG_ASSERT(rli->cur_log_fd == -1);
4355
Read pointer has to be at the start since we are the only
4357
We must keep the LOCK_log to read the 4 first bytes, as this is a hot
4358
log (same as when we call read_log_event() above: for a hot log we
4368
When the SQL thread is [stopped and] (re)started the
4369
following may happen:
4371
1. Log was hot at stop time and remains hot at restart
4373
SQL thread reads again from hot_log (SQL thread was
4374
reading from the active log when it was stopped and the
4375
very same log is still active on SQL thread restart).
4377
In this case, my_b_seek is performed on cur_log, while
4378
cur_log points to relay_log.get_log_file();
4380
2. Log was hot at stop time but got cold before restart
4382
The log was hot when SQL thread stopped, but it is not
4383
anymore when the SQL thread restarts.
4385
In this case, the SQL thread reopens the log, using
4386
cache_buf, ie, cur_log points to &cache_buf, and thence
4387
its coordinates are reset.
4389
3. Log was already cold at stop time
4391
The log was not hot when the SQL thread stopped, and, of
4392
course, it will not be hot when it restarts.
4394
In this case, the SQL thread opens the cold log again,
4395
using cache_buf, ie, cur_log points to &cache_buf, and
4396
thence its coordinates are reset.
4398
4. Log was hot at stop time, DBA changes to previous cold
4399
log and restarts SQL thread
4401
The log was hot when the SQL thread was stopped, but the
4402
user changed the coordinates of the SQL thread to
4403
restart from a previous cold log.
4405
In this case, at start time, cur_log points to a cold
4406
log, opened using &cache_buf as cache, and coordinates
4407
are reset. However, as it moves on to the next logs, it
4408
will eventually reach the hot log. If the hot log is the
4409
same at the time the SQL thread was stopped, then
4410
coordinates were not reset - the cur_log will point to
4411
relay_log.get_log_file(), and not a freshly opened
4412
IO_CACHE through cache_buf. For this reason we need to
4413
deploy a my_b_seek before calling check_binlog_magic at
4414
this point of the code (see: BUG#55263 for more
4418
- We must keep the LOCK_log to read the 4 first bytes, as
4419
this is a hot log (same as when we call read_log_event()
4420
above: for a hot log we take the mutex).
4422
- Because of scenario #4 above, we need to have a
4423
my_b_seek here. Otherwise, we might hit the assertion
4424
inside check_binlog_magic.
4427
my_b_seek(cur_log, (my_off_t) 0);
4361
4428
if (check_binlog_magic(cur_log,&errmsg))
4363
4430
if (!hot_log) pthread_mutex_unlock(log_lock);
added
removed
sql/slave.cc
