La position du journal maître de Mysql change pendant un verrou global?

Question

Je dois configurer une nouvelle réplication mysql en répliquant deux bases de données. J'ai donc ce script qui verrouille les tables, fait un vidage et les déverrouille.

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 

premières tables serrures fichier SQL et exporte l'état de maître:

1.SQL

FLUSH TABLES WITH READ LOCK; 
SHOW MASTER STATUS; 

secondes exportations de fichiers statut de maître et déverrouille tables

2.sql

SHOW MASTER STATUS; 
UNLOCK TABLES; 

le résultat ressemble à ceci:

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: Comment le changement de position du journal alors que les tables sont verrouillées?

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

que je pouvais faire mysqldump pour plusieurs bases de données et ajouter --master-données, mais je en quelque sorte sentie en danger car il existe différents formats de bases de données impliqués et je ne pouvais pas vraiment trouver comment mysqldump --master-données se conduit avec plusieurs bases de données. J'ai donc eu ce script et j'ai eu différentes positions de log ... une idée pourquoi? Je ne peux pas l'utiliser pour mettre en place une réplication ...

MISE À JOUR:

J'ai finalement décidé de mettre en place la réplication avec mysqldump --master-data --databases db1 db2 la décharge a été créée ce soir à 1h du matin. aujourd'hui vers 10 heures j'ai mis en place l'esclave. J'ai complètement effacé les bases de données (a chuté toutes les tables) et ai importé le cliché, qui a placé automatiquement le dossier de notation principal et log pos correctement. J'ai vérifié que c'est le même que dans le vidage sql. Tout a l'air bien. bien sûr, j'ai arrêté l'esclave avant l'importation (sinon je ne pouvais pas importer le vidage avec changement de maître à déclaration anway). J'ai commencé l'esclave et tout semblait bien. le log pos a augmenté, les secondes derrière master ont diminué et sont passées à 0 et certaines données de test ont été répliquées correctement.

mais une mise à jour majeure à partir d'aujourd'hui ~ 7h du matin (la fenêtre de temps entre la création du fichier de vidage et l'importation) était juste manquante. il a taillé les vieux disques d'une table, sur l'esclave ils étaient encore présents ... aucune idée pourquoi?

des informations supplémentaires nécessaires? comment ...

Answer 1

semble que je dois aussi faire:

FLUSH TABLES WITH WRITE LOCK; 

le commutateur de données de base semble être unrelyable ...

Answer 2

Si vous souhaitez voir ce qui a été écrit dans le journal binaire entre ces deux valeurs de position, vous pouvez utiliser l'outil mysqlbinlog pour convertir les entrées de journal binaires correspondantes en SQL. Utilisez simplement le premier pos comme position de départ et le second pos + 1 comme position d'arrêt. De cette façon, vous verrez tous les événements qui se sont produits après votre FLUSH (il vous montrera également le dernier événement qui s'est passé avant le flush, donc ignorez simplement le premier événement).

En utilisant votre exemple:

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

Answer 3

La raison pour laquelle vous avez vu des changements est le verrou est libéré dès que le premier script se termine. De l'manual:

Avertissement - Laissez le client à partir duquel vous avez lancé la FLUSH TABLES en cours d'exécution afin que le verrou de lecture reste en vigueur. Si vous quittez le client, le verrou est libéré.