MySQL Forums
Forum List  »  Replication

Re: Replication crashes when max_bin_log_size is reached
Posted by: Pär Iwarson
Date: May 20, 2005 02:56PM

Hi again!

I have let it crash again and this time the result was a little different.

I said that the crazy content in master.info only showed up if we tried "START SLAVE" directly after the crash. Forget that. This time master.info got the crazy content directly due to the crash. Also the relay-log.info got the crazy content.

I also did a backtrace of this crash and this one is similar but different from the one I posted earlier.

Here is the result this time:

-------------------------------------------------------------------
----------------------BACKTRACE----------------------------------

0x8072d44 handle_segfault + 420
0x826ca28 pthread_sighandler + 184
0x82989ef memcpy + 31
0x8251103 my_b_vprintf + 467
0x8250f2a my_b_printf + 26
0x80ee218 flush_master_info__FP14st_master_infob + 136
0x80ef697 handle_slave_io + 1719
0x826a1dc pthread_start_thread + 220
0x82a008a thread_start + 4


---------------------------------------------------------------------
-----------------------ERROR LOG------------------------------------

050520 19:56:33 Could not use ensim-relay-bin for logging (error 13). Turning logging off for the whole duration of the MySQL server process. To turn it on again: fix the cause, shutdown the MySQL server and restart it.
mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=8388600
read_buffer_size=131072
max_used_connections=24
max_connections=100
threads_connected=10
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 225791 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x87a5360
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0xbfe7f608, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x8072d44
0x826ca28
0x82989ef
0x8251103
0x8250f2a
0x80ee218
0x80ef697
0x826a1dc
0x82a008a
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at (nil) is invalid pointer
thd->thread_id=1
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.
050520 19:56:33 Error in Log_event::read_log_event(): 'Event too big', data_len: 1096237394, event_type: 65
050520 19:56:33 Error reading relay log event: slave SQL thread aborted because of I/O error
050520 19:56:33 Slave: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave. Error_code: 0
050520 19:56:33 Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'freebsds-bin.021' position 40776468

Number of processes running now: 0
050520 19:56:34 mysqld restarted
050520 19:56:34 Warning: Asked for 196608 thread stack, but got 126976
050520 19:56:35 InnoDB: Started
050520 19:56:35 Could not use ensim-relay-bin for logging (error 13). Turning logging off for the whole duration of the MySQL server process. To turn it on again: fix the cause, shutdown the MySQL server and restart it.
050520 19:56:35 Failed in open_log() called from init_relay_log_info()
050520 19:56:35 Failed to initialize the master info structure
/usr/sbin/mysqld: ready for connections.
Version: '4.0.23-standard' socket: '/home/virtual/FILESYSTEMTEMPLATE/.mysqlsock/mysql.sock' port: 3306 Official MySQL RPM

------------------------------------------------------------------
--------------------MASTER.INFO---------------------------------
3 = FORM2, FORM2 = FORM1, FORM1 = FORM, FORM = 91, FORMTEND = 0, NOGOALSSEASON = 0, NOGOALSEVER = 0, NOASSEVER = 2, NOASSSEASON = 2, NOOWNGOALSSEASON = 0, NOOWNGOALSEVER = 0, NOREDSEVER = 0, NOREDSSEASON = 0, NOYELLOWSEVER = 0, NOYELLOWSSEASON = 0, GAMESPLAYEDEVER = 10, GAMESPLAYEDSEASON = 10, COMPATFACTOR = 96, BESTPERFORMANCE = 75, LASTPERFORMANCE = 55, LASTSTARTLINEUP = 3, BESTGAMEID = 1236245, LASTGAMEID = 1236252, BESTGAMECUP = 0, LASTGAMECUP = 0, YELLOWSUSPCOUNT = 0, ADDEDFORM = 1683, NOFORMS = 12 WHERE PLAYERID = 2306428sql
wpphpadmin^Ktables_priv^BDb
42314470
RE PLAYERID = 2306428sql
wpphpadmin^Ktables_priv^BDb
repl_user
repl_pass
3306
60

--------------------------------------------------------------------------
-----------------------RELAY-LOG.INFO-----------------------------------
WSSEASON = 0, GAMESPLAYEDEVER = 10, GAMESPLAYEDSEASON = 10, COMPATFACTOR = 99, BESTPERFORMANCE = 60, LASTPERFORMANCE = 32, LASTSTARTLINEUP = 3, BESTGAMEID = 1236245, LASTGAMEID = 1236252, BESTGAMECUP = 0, LASTGAMECUP = 0, YELLOWSUSPCOUNT = 0, ADDEDFORM = 1319, NOFORMS = 12 WHERE PLAYERID = 2306429
1072233644
freebsds-bin.021
40776468

-----------------------------------------------------------------------

The difference this time compared to the crash I posted a few days ago was that this time the crash occured during a really busy time for the database. When the crash a few days ago occured it was also pretty busy but not under as heavy load as it was this time. If the heavier load is the cause of the crazy content in the master.info I don't know but I guess you'd have to suspect that. :/

Don't know if this help narrowing the problem but it won't hurt at least :)

I don't think I can recover the replication this time without getting a fresh copy of the master.

Regards
Iwarson

Options: ReplyQuote


Subject
Views
Written By
Posted
Re: Replication crashes when max_bin_log_size is reached
5224
May 20, 2005 02:56PM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.