11 messages in com.mysql.lists.bugsMore on replication ..| From | Sent On | Attachments |
|---|---|---|
| Weslee Bilodeau | 08 Sep 2000 14:46 | |
| sas...@mysql.com | 09 Sep 2000 20:27 | |
| Thimble Smith | 11 Sep 2000 06:39 | |
| sas...@mysql.com | 12 Sep 2000 14:12 | |
| sas...@mysql.com | 12 Sep 2000 17:20 | |
| Weslee Bilodeau | 12 Sep 2000 19:56 | |
| Michael Widenius | 13 Sep 2000 01:03 | |
| Michael Widenius | 13 Sep 2000 01:13 | |
| Benjamin Pflugmann | 23 Sep 2000 19:24 | |
| sas...@mysql.com | 25 Sep 2000 08:26 | |
| sas...@mysql.com | 04 Oct 2000 17:32 |
| Subject: | More on replication ..![]() |
|---|---|
| From: | Weslee Bilodeau (sha...@sell.com) |
| Date: | 09/08/2000 02:46:35 PM |
| List: | com.mysql.lists.bugs |
This ones an odd one, not fatal, just annoying ..
On the master server I created a table in a database that didn't exist on the slaves, as such the slaves exited with the error below. Thats not the bug though: ( But, speaking of which - Can there be an option to create databases which don't exist for which a table is created for on replication? )
00908 17:27:03 Error running query, slave aborted. Fix the problem, and re-start the slave thread with mysqladmin start-slave
mysql> mysql> mysql> show processlist ; +----+------+-----------+------+---------+------+-------+------------------+
| Id | User | Host | db | Command | Time | State | Info | +----+------+-----------+------+---------+------+-------+------------------+
| 5 | root | localhost | test | Query | 0 | NULL | show processlist | +----+------+-----------+------+---------+------+-------+------------------+
1 row in set (0.00 sec)
mysql> create database replication ; Query OK, 1 row affected (0.00 sec)
mysql> slave start ; Query OK, 0 rows affected (0.00 sec)
mysql> show processlist ; +----+-------------+-----------+------+---------+------+-----------------------+------------------+
| Id | User | Host | db | Command | Time | State | Info | +----+-------------+-----------+------+---------+------+-----------------------+------------------+
| 5 | root | localhost | test | Query | 0 | NULL | show processlist | | 48 | system user | none | NULL | Connect | 3960 | reading master update | NULL | +----+-------------+-----------+------+---------+------+-----------------------+------------------+
2 rows in set (0.00 sec)
The interesting part is that I just started the slave, and immediatly ran 'show processlist'. The Time is 3960.
The slaves been connected less then a few seconds and the counter is saying an hour.
Second one, goes back to my original 'slave stop' not removing thread.
I did further testing, and issued a 'slave stop' on one of the slaves, thread still didn't go away on the master, but no updates were done yet either ( Should the slave at least advise the master its no longer listening? ). I updated the master (meaning I inserted data in a table that was being replicated) and the 'zombie' slave was still there. Did another processlist and it showed two slave threads from the same machine, only one if which was actually connected.
+----+-----------+----------------------+-------------+-------------+------+--------------------+------------------+
| Id | User | Host | db | Command | Time | State | Info | +----+-----------+----------------------+-------------+-------------+------+--------------------+------------------+
| 1 | slave_rep | crashme.local.domain | NULL | Binlog Dump | 4457 | Waiting for update | NULL | | 2 | slave_rep | 192.168.1.34 | NULL | Binlog Dump | 4457 | Waiting for update | NULL | | 3 | root | localhost | replication | Query | 0 | NULL | show processlist | | 6 | slave_rep | | NULL | Binlog Dump | 393 | Waiting for update | NULL | | 7 | slave_rep | crashme.local.domain | NULL | Binlog Dump | 338 | Waiting for update | NULL | | 9 | slave_rep | | NULL | Binlog Dump | 8 | Waiting for update | NULL | +----+-----------+----------------------+-------------+-------------+------+--------------------+------------------+
After doing a few more inserts, the zombie threads disappeared (seems if only one update is done, they stick around, 2+ and they disappear).
More strangeness. Threads 6 and 9 are actually newer 'zombie' threads of '192.168.1.34', but for some reason they don't have a Host entry (unlike thread 2, which does have a Host entry). The 'crashme' server always has a host entry (but is also the only one with a reverse DNS entry).
If further information is needed I have on each server a second binary compiled w/'--with-debug=full' and can send the logs and replicate the problems if needed.
Weslee




