We have a very weird problem with our replication. The replication works fine until max_bin_log_size is reached (max_relay_log_size is 0). When the relay-log is so big that it is about to exceed max_bin_log_size the whole replication crashes for some reason. Master.info gets corrupted and we can't do anything but to get a fresh copy from the master and start all over again. And then the same thing happens again when the relay-log's size reaches the limit max_bin_log_size.
We get error 13 in the error-log but it can't be anything wrong with file permissions cause we have tested to give mysql all permissions and changed all files and folder to full access for anyone and it still crashes.
I suspect this to be a bug but I haven't seen anyone anywhere who has had a similar problem and if this is bug it's pretty severe and should have effected a lot of people using replication. That's why I try to reach out to you here for help or comments, before I report this as a bug.
The slave is on a Linux with MySQL 4.0.23-standard (have also tried 4.0.21). The Master is on a Linux with MySQL 4.0.21.
We're at the point where we have tried everything and nothing seems to work. We have had this problem since we started replicating our database the first days in January this year.
I don't expect anyone to have the answer, but I hope anyone has some clue about what the problem is. Any answer is very appreciated.
Regards
Iwarson
This is what the master.info looks like after the crash:
------------------
GENT, TECHNICAL, CROSSING, TALKING, LEADER, BADTEMPER, MONEYMAN, HEART, COMPATFACTOR) VALUES ('Bernhard Allinger', 75566, 3, 42, 78, 0, 1, 10, 17, 'S', '2005-02-19 07:23:20', 78, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 81)<ë^VB^B^A
624603887
134159, 75566, 0, '2005-02-19 07:23:20', 42, 3, 30000, 17)<ë^VB^E^A
B^E^A
s~ID
3306
60
306
60
~
----------------
This is the errorlog when the crash occure:
---------------
050219 7:21:03 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.
050219 7:21:03 next log error: -1 offset: 22 log: ./ensim-relay-bin.004
050219 7:21:03 Error reading relay log event: Error purging processed log
050219 7:21:03 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
050219 7:21:03 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.002' position 624574097
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=5
max_connections=100
threads_connected=0
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
0x2d32302d
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.
Number of processes running now: 0
050219 07:25:52 mysqld restarted
050219 7:25:52 Warning: Asked for 196608 thread stack, but got 126976
050219 7:25:53 InnoDB: Started
050219 7:25:53 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.
050219 7:25:53 Failed in open_log() called from init_relay_log_info()
050219 7:25:53 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