Yesterday I set up 4 new MySQL 4.0.22 replication slaves on 2 FreeBSD
4.10-R machines (via mysqld_multi). We have 10 other identical slaves and
I followed the same procedure as always when seeding them. The new slaves
were working fine, however when I issued SHOW SLAVE STATUS the
Hi Atle,
Yesterday I set up 4 new MySQL 4.0.22 replication slaves on 2 FreeBSD
4.10-R machines (via mysqld_multi). We have 10 other identical slaves and
I followed the same procedure as always when seeding them. The new slaves
were working fine, however when I issued SHOW SLAVE STATUS the
On Mon, 14 Feb 2005, Jeremy Cole wrote:
AFAIK, the log file name is not known by the slave unless it either
receives a rotate log event (go to next log) or you have started it
against a particular log file. If you start replication from the
beginning (not specifying a log file) against a
Did you copy the relay-log.info and relay logs from the seed slave?
Relay_Master_Log_file is line 3 in the relay-log.info file. This file
is managed by the SQL thread and helps the slave keep track of what it
has execute in the relay logs.
http://dev.mysql.com/doc/mysql/en/slave-logs.html
-Eric
On Mon, 14 Feb 2005, Eric Bergen wrote:
Did you copy the relay-log.info and relay logs from the seed slave?
Relay_Master_Log_file is line 3 in the relay-log.info file. This file
is managed by the SQL thread and helps the slave keep track of what it
has execute in the relay logs.
My understanding is that relay-info.log stores Exec_Master_Log_Pos so
in order to only use master.info in a snapshot you need to make sure
that the slave is caught up when the snapshot is taken. It's common
for the I/O thread (controls master.info and downloads logs files) to
be a few queries
On Mon, 14 Feb 2005, Eric Bergen wrote:
My understanding is that relay-info.log stores Exec_Master_Log_Pos so
in order to only use master.info in a snapshot you need to make sure
that the slave is caught up when the snapshot is taken. It's common
for the I/O thread (controls master.info and
