Gleb Paharenko schrieb:
I had been looking around the Changelogs, but I had not found that one. Sounds pretty much like my problem :(Hello.
I've looked through the bug database, and the only thing
that I've found was an already-closed bug:
http://bugs.mysql.com/bug.php?id=6148
But I use 4.1.7, not 4.0.21 ...weird.
Check that your server passes rpl_relayspace.test. Go to the mysql-test
directory and execute:
./mysql-test-run t/rpl_relayspace.test
This one runs wirhout errors on the master and the slave...:
hostname:/usr/local/mysql-standard-4.1.7-pc-linux-i686-icc-glibc23/mysql-test# ./mysql-test-run t/rpl_relayspace.test Installing Test Databases
Removing Stale Files
Installing Master Databases
running ../bin/mysqld --no-defaults --bootstrap --skip-grant-tables --basedir=.. --datadir=mysql-test/var/master-data --skip-innodb --skip-ndbcluster --skip-bdb Installing Slave Databases
running ../bin/mysqld --no-defaults --bootstrap --skip-grant-tables --basedir=.. --datadir=mysql-test/var/slave-data --skip-innodb --skip-ndbcluster --skip-bdb Manager disabled, skipping manager start.
Loading Standard Test Databases
Starting Tests
TEST RESULT
-------------------------------------------------------
rpl_relayspace [ pass ] -------------------------------------------------------
Ending Tests Shutting-down MySQL daemon
Master shutdown finished Slave shutdown finished All 1 tests were successful.
I'm not able to exchange the mysql-software itself (I use the icc-binary) to a gcc-version or to upgrade to 4.1.9 in the next 2-3 weeks. And looking at the changelogs on mysql.com I don't think it would change anything...
Hasn't anybody else had such problems with 4.1.x?
hostname:/usr/local/mysql-standard-4.1.7-pc-linux-i686-icc-glibc23/bin# ./mysqld --version
./mysqld Ver 4.1.7-standard for pc-linux on i686 (Official MySQL-standard binary)
(more detailed information on my systems in my initial mail from 2005-1-27)
btw: I also ran mysqlcheck -q and mysqlcheck -o on all tables last week to make sure the tables are OK...
Jan Kirchhoff <[EMAIL PROTECTED]> wrote:
Hi,
My problem still goes on... After having had the problem 2 more times
within 1 day, I decided to re-do the replication (copy the whole
database onto the slave with rsync and reset master and slave). That
only lasted for little more than 1 day and I ended up with the same error:
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.
I can look at the binlog with mysqlbinlog on the master and the slave;
no errors or problems.
After a simple "SLAVE START" without having done any changes to the
database, the slave thread startet again and caught up with the master.
I've been using mysql's replication-feature since it first came up in
1999 or 2000 and dealt with lots of problems and workarounds, but this
one is weird. Any ideas anybody?
Jan
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
