Mysql master log pos changes during a global lock?

Question

I have to set up a new mysql replication replicating two databases. So I have this script which locks tables, makes a dump and unlocks them.

runme.sh

mysql -uxxx -pxxx < 1.sql >> logpos.txt
mysqldump -uXXX -pXXX db1 > db1.sql
mysqldump -uXXX -pXXX db2 > db2.sql
mysql -uxxx -pxxx < 2.sql >> logpos.txt

first sql file locks tables and exports master status:

1.sql

FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

second file exports master status and unlocks tables

2.sql

SHOW MASTER STATUS;
UNLOCK TABLES;

the result looks like this:

logpos.txt

File    Position        Binlog_Do_DB    Binlog_Ignore_DB
mysql-bin.000335        49106285        fli_search,flimmit
File    Position        Binlog_Do_DB    Binlog_Ignore_DB
mysql-bin.000335        49139991        fli_search,flimmit

Question: How can the log position change while tables are locked?

Server version:  5.0.51a-24+lenny4-log (Debian)

I could do mysqldump for multiple databases and add --master-data, but I somehow felt unsafe because there are different database formats involved and I couldn't really find out how mysqldump --master-data behaves with multiple databases. So I had this script and got different log positions.... any idea why? I cannot use this to set up a replication...

UPDATE:

I finally decided to set up replication with mysqldump --master-data --databases db1 db2 the dump was created tonight at 1 am. today at about 10 am i set up the slave. i totally cleared the databases (dropped all tables) and imported the dump, which automatically set the master log file and log pos correctly. i checked that its the same as in the sql dump. everything looked fine. of course i stopped the slave before importing (otherwise i couldnt import the dump with change master to statement anway). i started the slave and eveyrthing looked just fine. the log pos increased, the seconds behind master decreased and went to 0 and some test data was replicated correctly.

but a major update from today ~7am (the time window between the dump creation and importing) was just missing. it pruned old records from a table, on the slave they were still present... any idea why?

any additional information needeD? comment...

Answer 1

If you want to see what was written to the binary log during between those two position values, you can use the mysqlbinlog tool to convert the relevant binary log entries to SQL. Just use the first pos as the start-position and the second pos + 1 as the stop-position. That way you will see all events that happened after your FLUSH (it will also show you the last event that happened before the flush, so just ignore the first event).

Using your example:

mysqlbinlog --start-position=49106286 --stop-position=49139992 mysql-bin.000335

Answer 2

looks like i also have to do:

FLUSH TABLES WITH WRITE LOCK;

the master data switch seems to be unrelyable...

Answer 3

The reason you saw changes is the lock is released as soon as the first script exits. From the manual :

Warning - Leave the client from which you issued the FLUSH TABLES statement running so that the read lock remains in effect. If you exit the client, the lock is released.