Bug 83098 - slave setup causes mysql to crash - cannot be manually restarted
Summary: slave setup causes mysql to crash - cannot be manually restarted
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: mysql
Version: 8.0
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Patrick Macdonald
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-01-30 08:03 UTC by Bernard Johnson
Modified: 2007-04-18 16:50 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-04-08 19:23:59 UTC
Embargoed:


Attachments (Terms of Use)

Description Bernard Johnson 2003-01-30 08:03:52 UTC
Description of problem:
When setting my mysql to slave to a master, the server will crash as soon as 
the slave is started.  Then the mysql server can't be restarted until 
the /var/lib/mysql databases are removed and re-initialized.

Version-Release number of selected component (if applicable):

How reproducible:
Always

Steps to Reproduce:
1.  Apply a server-id to the mysql server:
--- /etc/my.cnf.orig    2003-01-30 02:24:43.000000000 -0500
+++ /etc/my.cnf 2003-01-30 02:10:45.000000000 -0500
@@ -1,4 +1,5 @@
 [mysqld]
+server-id=2
 datadir=/var/lib/mysql
 socket=/var/lib/mysql/mysql.sock

2.  start the server - "service start mysqld";
3.  run the following sql commands "mysql -u root < crash.sql";
--- /dev/null   2002-08-30 19:31:37.000000000 -0400
+++ crash.sql    2003-01-30 02:19:02.000000000 -0500
@@ -0,0 +1,6 @@
+change master to master_host='dummy',
+    master_user='repl',
+    master_password='password',
+    master_log_file='dummy-bin.001',
+    master_log_pos=0;
+slave start;
 
Actual results:
Server dies with the following in the /var/log/mysql.log file:

Number of processes running now: 2
mysqld process hanging, pid 17744 - killed
mysqld process hanging, pid 17744 - killed
030130 02:19:07  mysqld restarted
030130  2:19:07  Can't start server: Bind on TCP/IP port: Address already in 
use
030130  2:19:07  Do you already have another mysqld server running on port: 
3306 ?
030130  2:19:07  Aborting
030130  2:19:07  /usr/libexec/mysqld: Shutdown Complete
030130 02:19:07  mysqld ended


Expected results:
replication should begin, but instead server dies

Additional info:
This occurs on RedHat Linux 8.0 with all errata applied (for installed 
components).  It affects both mysql-3.23.52-3 and mysql-3.23.54a-4.

Comment 1 Eje Gustafsson 2003-03-03 00:23:18 UTC
I see the same issues. 

RH 8.0 all updates installed. When I connect to the main mysql server from 
another machine over the net I see the same results. 

on a separate Linux or Windows machine I do 
mysql -h mainsqlserver -p 
get the password prompt and type in the password and hit enter
and get the following 
ERROR 2013: Lost connection to MySQL server during query

In the main mysqld servers log I get the following error message

Number of processes running now: 1
mysqld process hanging, pid 3373 - killed
030302 19:10:17  mysqld restarted
030302 19:10:17  Can't start server: Bind on TCP/IP port: Address already in 
use
030302 19:10:17  Do you already have another mysqld server running on port: 
3306
 ?
030302 19:10:17  Aborting

030302 19:10:17  /usr/libexec/mysqld: Shutdown Complete

030302 19:10:17  mysqld ended

This happens on 2 different RH 8 machines tried with both mysql-server-3.23.52-
3 and mysql-server-3.23.54a-4
I can do the same thing to a RH 7.0 box running mysql-server-3.23.54a-3.70 
and not have any problems. 



Comment 2 Eje Gustafsson 2003-03-03 01:54:29 UTC
uninstalled mysql & mysql-server with a --nodeps and downloaded latest rpm 
release of mysql.com (MySQL-3.223.55-1.i386.rpm & MySQL-client-3.23.55-
1.i386.rpm) and I can now successfully connect to my mysql server over the 
network. 

Seems that something gotten broken with RedHats mysql release for RH 8.0. 

Comment 3 Patrick Macdonald 2003-04-08 19:23:59 UTC
We were able to get the replication going on RHL 8.0 using MySQL versions
3.23.52, 3.23.54 and 3.23.56 (which will be available soon as an erratum).
However, during the time between your opening of the bug and now, there
have been glibc and kernel updates. Please perform an up2date on these
packages and retry your scenario.

The problem the Eje was seeing may be related.  There was a glibc/mysql
interaction bug for remote connections which has since been fixed.

Here's what we modified to get replication going.  The master is toddnrodd
and the slave is tool.


/etc/my.cnf
----------------------
master:
server-id=2
log-bin

slave:
server-id=4

. removed any master.info file in /var/lib/mysql
. restarted mysqld on the master
. tar'd the database and issued a "show master status" to get the
  appropriate log and position
. untar'd the database on the slave
. restart mysqld on the slave
. user 'repl' was granted FILE with password 'passwd'

INPUT
-----
On the slave, I issued the following commands:

mysql> change master to master_host='toddnrodd',
    -> master_user='repl',
    -> master_password='passwd',
    -> master_log_file='toddnrodd-bin.003',
    -> master_log_pos=315;
Query OK, 0 rows affected (0.03 sec)

mysql> slave start;
Query OK, 0 rows affected (0.00 sec)


OUTPUT
------

On master (toddnrodd):

mysql> show master status;
+-------------------+----------+--------------+------------------+
| File              | Position | Binlog_do_db | Binlog_ignore_db |
+-------------------+----------+--------------+------------------+
| toddnrodd-bin.003 | 315      |              |                  |
+-------------------+----------+--------------+------------------+
1 row in set (0.00 sec)


On slave (tool - output chopped):

mysql> show slave status;
+-------------+-------------+-------------+---------------+-------------------+-----+--------------
| Master_Host | Master_User | Master_Port | Connect_retry | Log_File          |
Pos | Slave_Running
+-------------+-------------+-------------+---------------+-------------------+-----+--------------
| toddnrodd   | repl        | 3306        | 60            | toddnrodd-bin.003 |
315 | Yes
+-------------+-------------+-------------+---------------+-------------------+-----+--------------
1 row in set (0.00 sec)

Closing this as works for me (as it does).  However, if you can not get
replication going, feel free to append to this bug.  Cheers, Patrick.


Note You need to log in before you can comment on or make changes to this bug.