Jon,
replication 4.0.1 -> 4.0.2 does not work because the format in the 4.0
series has evolved. Currently, if your master of the 4.0 series, your slave
must be of the exact same release.
All 3.23 versions after 3.23.33 can be replicated from each other
4.0.0 can only replicate to/from 4.0.0.
4.0.1 slave can replicate from a 3.23.33 and newer 3.23 master, and can only
replicate from a 4.0.1 master in the 4.0 branch.
4.0.2 slave can replicate from a 3.23 master, and can only replicate from a
4.0.2 master in the 4.0 branch.
| | Master
| | 3.23.33 and up | 4.0.0 | 4.0.1 | 4.0.2
Slave | 3.23.33 and up | yes | no | no | no
| 4.0.0 | no | yes | no | no
| 4.0.1 | yes | no | yes | no
| 4.0.2 | yes | no | no | yes
Best regards,
Heikki Tuuri
Innobase Oy
---
Order technical MySQL/InnoDB support at https://order.mysql.com/
See http://www.innodb.com for the online manual and latest news on InnoDB
----- Original Message -----
From: ""Jon Frisby"" <[EMAIL PROTECTED]>
Newsgroups: mailing.database.mysql
Sent: Tuesday, July 16, 2002 4:30 AM
Subject: RE: MySQL 4.0.2 replication going bonkers?
> This seems to have not gotten through... Perhaps the spam filter ate it?
> (sql, query)
>
> -JF
>
> > -----Original Message-----
> > From: Jon Frisby [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, July 15, 2002 4:27 PM
> > To: [EMAIL PROTECTED]
> > Subject: MySQL 4.0.2 replication going bonkers?
> >
> >
> > We recently set up a 4.0.2 slave, which worked fine -- we loaded
> > our data snapshot (taken via mysqldump) and were able to perform
> > complex queries without problems...
> >
> > However, as soon as we tried to get this machine to act as a
> > slave to a 4.0.1 server it crashed. Immediately upon executing
> > "SLAVE START", we get messages like this in the error log:
> >
> > 020714 01:32:03 mysqld started
> > 020714 1:32:05 InnoDB: Started
> > /usr/sbin/mysqld-max: ready for connections
> > 020714 8:00:28 Slave SQL thread initialized, starting
> > replication in log 'server2-bin.035' at position 579285542, relay
> > log './db1-relay-bin.001' position: 4
> > 020714 8:00:29 Slave I/O thread: connected to master
> > '[EMAIL PROTECTED]:3306', replication started in log
> > 'server2-bin.035' at position 579285542 ERROR: 1146 Table
> > 'test.response' doesn't exist
> > 020714 8:00:30 Slave: error 'Table 'test.response' doesn't
> > exist' on query 'INSERT INTO response SET
> > connect_time=0.073868989944458, page_time=1.53695404529572,
> > site_id='Apt'', error_code=1146
> > 020714 8:00:30 Error running query, slave SQL thread aborted.
> > Fix the problem, and restart the slave SQL thread with "SLAVE
> > START". We stopped at log 'server2-bin.035' position 579285542
> > 020714 8:00:30 Slave SQL thread exiting, replication stopped in
> > log 'server2-bin.035' at position 579285542
> > 020714 8:00:54 Error reading packet from server: (server_errno=1159)
> > 020714 8:00:54 Slave I/O thread killed while reading event
> > 020714 8:00:54 Slave I/O thread exiting, read up to log
> > 'server2-bin.035', position 579993154
> > 020714 8:01:58 /usr/sbin/mysqld-max: Normal shutdown
> >
> > 020714 8:01:58 InnoDB: Starting shutdown...
> > 020714 8:02:05 InnoDB: Shutdown completed
> > 020714 8:02:06 /usr/sbin/mysqld-max: Shutdown Complete
> >
> > 020714 08:02:06 mysqld ended
> >
> > 020714 08:02:16 mysqld started
> > 020714 8:02:17 InnoDB: Started
> > /usr/sbin/mysqld-max: ready for connections
> > 020714 8:02:34 Slave SQL thread initialized, starting
> > replication in log 'FIRST' at position 0, relay log
> > './db1-relay-bin.001' position: 4
> > ERROR: 1146 Table 'test.response' doesn't exist
> > 020714 8:02:34 Slave: error 'Table 'test.response' doesn't
> > exist' on query 'INSERT INTO response SET
> > connect_time=0.073868989944458, page_time=1.53695404529572, site_id='Apt
> > '', error_code=1146
> > 020714 8:02:34 Error running query, slave SQL thread aborted.
> > Fix the problem, and restart the slave SQL thread with "SLAVE
> > START". We stopped at log 'FIRST' position 0
> > 020714 8:02:34 Slave SQL thread exiting, replication stopped in
> > log 'FIRST' at position 0
> > 020714 8:02:34 Slave I/O thread: connected to master
> > '[EMAIL PROTECTED]:3306', replication started in log
> > 'server2-bin.035' at position 579993154
> > 020714 8:03:02 Error reading packet from server: (server_errno=1159)
> > 020714 8:03:02 Slave I/O thread killed while reading event
> > 020714 8:03:02 Slave I/O thread exiting, read up to log
> > 'server2-bin.035', position 579993478
> > 020714 8:03:25 /usr/sbin/mysqld-max: Normal shutdown
> >
> > 020714 8:03:25 InnoDB: Starting shutdown...
> > 020714 8:03:28 InnoDB: Shutdown completed
> > 020714 8:03:28 /usr/sbin/mysqld-max: Shutdown Complete
> >
> > 020714 08:03:28 mysqld ended
> >
> > 020714 08:03:36 mysqld started
> > 020714 8:03:38 InnoDB: Started
> > /usr/sbin/mysqld-max: ready for connections
> > 020714 8:04:02 Slave SQL thread initialized, starting
> > replication in log 'FIRST' at position 0, relay log
> > './db1-relay-bin.001' position: 4
> > 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=67104768
> > record_buffer=16773120
> > sort_buffer=16777208
> > max_used_connections=0
> > max_connections=100
> > threads_connected=1
> > It is possible that mysqld could use up to
> > key_buffer_size + (record_buffer + sort_buffer)*max_connections =
> > 3341931 K bytes of memory
> > Hope that's ok; if not, decrease some variables in the equation.
> >
> > thd=0x85204a0
> > 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=0xbfe3f248, backtrace may not be correct.
> > Stack range sanity check OK, backtrace follows:
> > 0x80722d8
> > 0x82de908
> > 0x82cb534
> > 0x80e9a58
> > 0x80af595
> > 0x80b04f4
> > 0x80ebf71
> > 0x80ece8f
> > 0x82dbf1c
> > 0x831193a
> > New value of fp=(nil) failed sanity check, terminating stack trace!
> > Please read http://www.mysql.com/doc/U/s/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=3
> >
> > Successfully dumped variables, if you ran with --log, take a look at the
> > details of what thread 3 did to cause the crash. In some cases of
really
> > bad corruption, the values shown above may be invalid.
> >
> > The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains
> > information that should help you find out what is causing the crash.
> >
> > Number of processes running now: 0
> > 020714 08:04:02 mysqld restarted
> > 020714 8:04:04 InnoDB: Started
> > /usr/sbin/mysqld-max: ready for connections
> > 020714 8:04:16 Slave SQL thread initialized, starting
> > replication in log 'FIRST' at position 5600514, relay log
> > './db1-relay-bin.001' position: 51184
> > 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=67104768
> > record_buffer=16773120
> > sort_buffer=16777208
> > max_used_connections=0
> > max_connections=100
> > threads_connected=1
> > It is possible that mysqld could use up to
> > key_buffer_size + (record_buffer + sort_buffer)*max_connections =
> > 3341931 K
> > bytes of memory
> > Hope that's ok; if not, decrease some variables in the equation.
> >
> > thd=0x85204a0
> > 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=0xbfe3f248, backtrace may not be correct.
> > Stack range sanity check OK, backtrace follows:
> > 0x80722d8
> > 0x82de908
> > 0x82cb534
> > 0x80e9a58
> > 0x80af595
> > 0x80b04f4
> > 0x80ebf71
> > 0x80ece8f
> > 0x82dbf1c
> > 0x831193a
> > New value of fp=(nil) failed sanity check, terminating stack trace!
> > Please read http://www.mysql.com/doc/U/s/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=3
> >
> > Successfully dumped variables, if you ran with --log, take a look at the
> > details of what thread 3 did to cause the crash. In some cases of
really
> > bad corruption, the values shown above may be invalid.
> >
> > The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains
> > information that should help you find out what is causing the crash.
> >
> > Number of processes running now: 0
> >
> >
> >
> > Configuration-wise, we've increased the various memory pools
> > somewhat, but that's it. Also, we rely heavily on InnoDB tables
> > and have about 32GB allocated to the InnoDB tablespace (on the slave).
> >
> > Any ideas?
> >
> > -JF
>
>
> ---------------------------------------------------------------------
> Before posting, please check:
> http://www.mysql.com/manual.php (the manual)
> http://lists.mysql.com/ (the list archive)
>
> To request this thread, e-mail <[EMAIL PROTECTED]>
> To unsubscribe, e-mail
<[EMAIL PROTECTED]>
> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
>
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
