database/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-08-01 03:47:19 +03:00
Code Activity

Replication: small bug fixes in mysql-test-run.sh and in replication code (more reinitializations)

Browse Source 
+ fix for #70 
+ test result fix for LOAD DATA LOCAL bug #82


client/mysqltest.c:
  Removed wrong comment and useless sleep
mysql-test/mysql-test-run.sh:
  Fix $slave_datadir variable because this
    if [ -n "$1" ] ; 
     slave_datadir="var/$slave_ident-data/"
    else
      slave_datadir=$SLAVE_MYDDIR
  was not coherent and led to problems of master.info not being deleted.
  Delete relay-log.info too.
mysql-test/r/rpl000001.result:
  SUM is 1022 (1021 was when we had the LOAD DATA LOCAL bug #82).
  It's logical to have an even number as we load the same file twice.
sql/slave.cc:
  When we RESET SLAVE, clear rli->master_log_* to give a good display in SHOW SLAVE STATUS ;
  seeing the old values may confuse the user.
  When we START SLAVE, clear rli->master_log_name, not only rli->master_log_pos.
sql/sql_repl.cc:
  When we RESET SLAVE, clear mi->master_log_* to give a good display in SHOW SLAVE STATUS (bug #70)
This commit is contained in:
unknown
2003-03-03 14:57:02 +01:00
parent 5387425aeb
commit 2855415058
5 changed files with 38 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
sql/slave.cc
View File

@ -322,17 +322,37 @@ int purge_relay_logs(RELAY_LOG_INFO* rli, THD *thd, bool just_reset,
{
int error=0;
DBUG_ENTER("purge_relay_logs");
/*
Even if rli->inited==0, we still try to empty rli->master_log_* variables.
Indeed, rli->inited==0 does not imply that they already are empty.
It could be that slave's info initialization partly succeeded :
for example if relay-log.info existed but *relay-bin*.*
have been manually removed, init_relay_log_info reads the old
relay-log.info and fills rli->master_log_*, then init_relay_log_info
checks for the existence of the relay log, this fails and
init_relay_log_info leaves rli->inited to 0.
In that pathological case, rli->master_log_pos* will be properly reinited
at the next START SLAVE (as RESET SLAVE or CHANGE
MASTER, the callers of purge_relay_logs, will delete bogus *.info files
or replace them with correct files), however if the user does SHOW SLAVE
STATUS before START SLAVE, he will see old, confusing rli->master_log_*.
In other words, we reinit rli->master_log_* for SHOW SLAVE STATUS
to display fine in any case.
*/
rli->master_log_name[0]= 0;
rli->master_log_pos= 0;
rli->pending= 0;
if (!rli->inited)
DBUG_RETURN(0); /* successfully do nothing */
DBUG_RETURN(0);
DBUG_ASSERT(rli->slave_running == 0);
DBUG_ASSERT(rli->mi->slave_running == 0);
rli->slave_skip_counter=0;
pthread_mutex_lock(&rli->data_lock);
rli->pending=0;
rli->master_log_name[0]=0;
rli->master_log_pos=0; // 0 means uninitialized
if (rli->relay_log.reset_logs(thd))
{
*errmsg = "Failed during log reset";
@ -1193,8 +1213,9 @@ int init_relay_log_info(RELAY_LOG_INFO* rli, const char* info_fname)
if (init_relay_log_pos(rli,NullS,BIN_LOG_HEADER_SIZE,0 /* no data lock */,
&msg))
goto err;
rli->master_log_pos = 0; // uninitialized
rli->info_fd = info_fd;
rli->master_log_name[0]= 0;
rli->master_log_pos= 0;
rli->info_fd= info_fd;
}
else // file exists
{