Hello.
> But I use 4.1.7, not 4.0.21 ...weird. As said at: http://dev.mysql.com/doc/mysql/en/news-4-1-8.html "Fixed a bug which caused a crash when only the slave I/O thread was stopped and started. (Bug #6148)" I suggest you to upgrade to the latest release (4.1.9 now). Jan Kirchhoff <[EMAIL PROTECTED]> wrote: > Gleb Paharenko schrieb: > >>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 >> >> > I had been looking around the Changelogs, but I had not found that one. > Sounds pretty much like my problem :( > 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 >>> >>> >> >> >> > > -- For technical support contracts, goto https://order.mysql.com/?ref=ensita This email is sponsored by Ensita.NET http://www.ensita.net/ __ ___ ___ ____ __ / |/ /_ __/ __/ __ \/ / Gleb Paharenko / /|_/ / // /\ \/ /_/ / /__ [EMAIL PROTECTED] /_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.NET <___/ www.mysql.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
