Replication Problem: Waiting for master to send event (MySQL 4.1.12-standard-log)
Hi
I have setup Replication on MySQL 4.1.12 between two machines (master and slave). Both are running on: Red Hat 3.4.3-9.EL4.
mysql> show slave status \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.1.1
Master_User: rep
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: dev-db1.004806
Read_Master_Log_Pos: 730334
Relay_Log_File: dev-db2-relay-bin.000001
Relay_Log_Pos: 2434121
Relay_Master_Log_File: dev-db1.004806
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: habeas hdns opdb web2lead
The slave doesn't seem to do anything at this point. The master status is:
mysql> show master status;
+----------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+----------------+----------+--------------+------------------+
| dev-db1.004806 | 1110612 | | |
+----------------+----------+--------------+------------------+
1 row in set (0.00 sec)
The messages in the master's log shows:
060513 9:52:08 [Note] Slave SQL thread initialized, starting replication in log 'dev-db1.004805' at position 32234, relay log './dev-db2-relay-bin.000001' position: 4
060513 9:52:08 [Note] Slave I/O thread: connected to master 'rep@192.168.1.1:3306', replication started in log 'dev-db1.004805' at position 32234
There are no visible errors on the Slave's log. I tried to explicitly doing change master on slave but no luck.
Is there anyway that I can see more information about what is happening here?
-Srinivas
Subject
Views
Written By
Posted
Replication Problem: Waiting for master to send event (MySQL 4.1.12-standard-log)
54675
May 13, 2006 11:21AM
28063
May 13, 2006 11:38AM
22751
May 14, 2006 06:51PM
22340
May 15, 2006 11:09PM
Sorry, you can't reply to this topic. It has been closed.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion
of Oracle or any other party.