Re: MySQL 4.0.2 replication going bonkers?

2002-07-18 Thread Jeremy Zawodny

On Wed, Jul 17, 2002 at 12:02:08PM +0300, Heikki Tuuri wrote:
 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.

How likely is that to happen again?  I just upgraded my last slave to
4.0.3 and all the othres are running various builds of 4.0.2.  The master
is running 3.23.51.  I'm planning to upgrade it to 4.0.x after OSCON.  But
if this is likely to happen a few more times, I'll wait.  I don't want
upgrades to be an all servers or no servers situation.

Thanks,

Jeremy
-- 
Jeremy D. Zawodny |  Perl, Web, MySQL, Linux Magazine, Yahoo!
[EMAIL PROTECTED]  |  http://jeremy.zawodny.com/

MySQL 3.23.51: up 50 days, processed 1,073,978,230 queries (247/sec. avg)

-
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




Re: MySQL 4.0.2 replication going bonkers?

2002-07-18 Thread Heikki Tuuri

Jeremy,

- Original Message -
From: Jeremy Zawodny [EMAIL PROTECTED]
To: Heikki Tuuri [EMAIL PROTECTED]
Cc: Jon Frisby [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Friday, July 19, 2002 7:17 AM
Subject: Re: MySQL 4.0.2 replication going bonkers?


 On Wed, Jul 17, 2002 at 12:02:08PM +0300, Heikki Tuuri wrote:
  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.

 How likely is that to happen again?  I just upgraded my last slave to
 4.0.3 and all the othres are running various builds of 4.0.2.  The master
 is running 3.23.51.  I'm planning to upgrade it to 4.0.x after OSCON.  But
 if this is likely to happen a few more times, I'll wait.  I don't want
 upgrades to be an all servers or no servers situation.

4.0.1 was 6 months old when 4.0.2 came. I guess no changes, except bug
fixes, in the 4.0 series happen any more; they are put to to the 4.1 branch.

 Thanks,

 Jeremy
 --
 Jeremy D. Zawodny |  Perl, Web, MySQL, Linux Magazine, Yahoo!
 [EMAIL PROTECTED]  |  http://jeremy.zawodny.com/

 MySQL 3.23.51: up 50 days, processed 1,073,978,230 queries (247/sec. avg)

Best regards,

Heikki Tuuri
Innobase Oy
---
InnoDB - transactions, row level locking, and foreign key support for MySQL
See http://www.innodb.com, download MySQL-Max from http://www.mysql.com






-
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




Re: MySQL 4.0.2 replication going bonkers?

2002-07-17 Thread Heikki Tuuri

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

RE: MySQL 4.0.2 replication going bonkers?

2002-07-15 Thread Jon Frisby

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!