When the SQL thread cannot read an event from the relay log
("Event too big" etc), stop this thread instead of going on with the next event, which would certainly lead to slave's data corruption. BitKeeper/etc/logging_ok: Logging to logging@openlogging.org accepted
This commit is contained in:
parent
4c0f2f4591
commit
f29fb98d34
@ -16,6 +16,7 @@ bk@admin.bk
|
||||
davida@isil.mysql.com
|
||||
gluh@gluh.(none)
|
||||
greg@mysql.com
|
||||
guilhem@mysql.com
|
||||
gweir@work.mysql.com
|
||||
heikki@donna.mysql.fi
|
||||
heikki@hundin.mysql.fi
|
||||
|
@ -588,6 +588,15 @@ err:
|
||||
sql_print_error("Error in Log_event::read_log_event(): '%s', \
|
||||
data_len=%d,event_type=%d",error,data_len,head[EVENT_TYPE_OFFSET]);
|
||||
my_free(buf, MYF(MY_ALLOW_ZERO_PTR));
|
||||
/*
|
||||
The SQL slave thread will check if file->error<0 to know
|
||||
if there was an I/O error. Even if there is no "low-level" I/O errors
|
||||
with 'file', any of the high-level above errors is worrying
|
||||
enough to stop the SQL thread now ; as we are skipping the current event,
|
||||
going on with reading and successfully executing other events can
|
||||
only corrupt the slave's databases. So stop.
|
||||
*/
|
||||
file->error= -1;
|
||||
}
|
||||
return res;
|
||||
}
|
||||
|
Loading…
x
Reference in New Issue
Block a user