كيفية كتابة موضع السجل الثنائي Mysql للسيد عند القيام بـ mysqldump من العبد؟

Question

أقوم حاليًا بتشغيل mysqldump على تابع Mysql لإجراء نسخ احتياطي لقاعدة البيانات الخاصة بنا.لقد نجح هذا بشكل جيد في النسخ الاحتياطي لبياناتنا نفسها، ولكن ما أود استكماله هو موضع السجل الثنائي للوحدة الرئيسية الذي يتوافق مع البيانات التي تم إنشاؤها بواسطة mysqldump.

إن القيام بذلك سيسمح لنا باستعادة الرقيق الخاص بنا (أو إعداد العبيد الجدد) دون الحاجة إلى إجراء mysqldump منفصل في قاعدة البيانات الرئيسية حيث نحصل على موضع السجل الثنائي للسيد.سنقوم فقط بأخذ البيانات التي تم إنشاؤها بواسطة mysqldump، ودمجها مع معلومات السجل الثنائي التي قمنا بإنشائها، وفويلا...تتم إعادة مزامنتها.

حتى الآن، لقد جعلني بحثي قريبًا جدًا من القدرة على تحقيق هذا الهدف، لكن يبدو أنني لا أستطيع اكتشاف طريقة آلية لتحقيق ذلك.فيما يلي "تقريبًا" التي اكتشفتها:

• إذا كنا نقوم بتشغيل mysqldump من قاعدة البيانات الرئيسية، فيمكننا استخدام المعلمة "--master-data" مع mysqldump لتسجيل الموضع الثنائي للسيد مع بيانات التفريغ (أفترض أن هذا ربما يعمل أيضًا إذا بدأنا في إنشاء سجلات ثنائية من عبدنا، ولكن هذا يبدو مبالغة في ما نريد تحقيقه)
• إذا أردنا القيام بذلك بطريقة غير أوتومات ، فيمكننا تسجيل الدخول إلى قاعدة بيانات العبد وتشغيل "إيقاف SPIL SQL_THREAD ؛" تليها "عرض حالة الرقيق" ؛ ((http://dev.mysql.com/doc/refman/5.0/en/mysqldump.html).لكن هذا لن يفيدنا إلا إذا علمنا مسبقًا أننا نريد دعم شيء ما من المرهم.
• إذا كان لدينا 500 دولار سنويًا لننفقها، فيمكننا استخدام البرنامج الإضافي للنسخ الاحتياطي السريع InnoDb وتشغيل mysqldumps الخاص بنا من قاعدة البيانات الرئيسية.لكن ليس لدينا هذا المال، ولا أريد إضافة أي إدخال/إخراج إضافي إلى قاعدة بياناتنا الرئيسية على أي حال.

يبدو هذا أمرًا شائعًا بدرجة كافية بحيث يجب أن يكون شخص ما قد اكتشفه من قبل، ونأمل أن يستخدم شخص ما Stack Overflow؟

Answer 1

سيتم تشغيل البرنامج النصي Shell التالي في كرون أو دوري، واستبدال المتغيرات حسب الضرورة (يتم كتابة الإعدادات الافتراضية freeBSD):

# MySQL executable location
mysql=/usr/local/bin/mysql

# MySQLDump location
mysqldump=/usr/local/bin/mysqldump

# MySQL Username and password
userpassword=" --user=<username> --password=<password>"

# MySQL dump options
dumpoptions=" --quick --add-drop-table --add-locks --extended-insert"

# Databases
databases="db1 db2 db3"

# Backup Directory
backupdir=/usr/backups

# Flush and Lock
mysql $userpassword -e 'STOP SLAVE SQL_THREAD;'

set `date +'%Y %m %d'`

# Binary Log Positions
masterlogfile=`$mysql $userpassword -e 'SHOW SLAVE STATUS \G' | grep '[^_]Master_Log_File'`
masterlogpos=`$mysql $userpassword -e 'SHOW SLAVE STATUS \G' | grep 'Read_Master_Log_Pos'`

# Write Binlog Info
echo $masterlogfile >> ${backupdir}/info-$1-$2-$3.txt
echo $masterlogpos >> ${backupdir}/info-$1-$2-$3.txt

# Dump all of our databases
echo "Dumping MySQL Databases"
for database in $databases
do
$mysqldump $userpassword $dumpoptions $database | gzip - > ${backupdir}/${database}-$1-$2-$3.sql.gz
done

# Unlock
$mysql $userpassword -e 'START SLAVE'

echo "Dump Complete!"

exit 0

Answer 2

على الرغم من أن نص روس يسير على المسار الصحيح، إلا أن @joatis كان على حق عندما طلب إيقاف العبد قبل التحقق من موضع السجل الرئيسي.والسبب هو أن قفل القراءة لن يحافظ على الملف Read_Master_Log_Pos الذي يتم استرجاعه مع SHOW SLAVE STATUS.

لمعرفة ذلك، قم بتسجيل الدخول إلى MySQL على جهازك التابع وقم بتشغيل:

FLUSH TABLES WITH READ LOCK

SHOW SLAVE STATUS \G

لاحظ ال Read_Master_Log_Pos

انتظر بضع ثوان وقم بتشغيل مرة أخرى:

SHOW SLAVE STATUS \G

يجب أن تلاحظ أن Read_Master_Log_Pos تغير.

نظرًا لبدء النسخ الاحتياطي بسرعة بعد التحقق من الحالة، فقد يكون موضع السجل المسجل بواسطة البرنامج النصي دقيقًا.ومع ذلك، فمن الأفضل بدلاً من ذلك اتباع الإجراء هنا:http://dev.mysql.com/doc/refman/5.0/en/replication-solutions-backups-mysqldump.html

و اهرب STOP SLAVE SQL_THREAD; بدلاً من FLUSH TABLES WITH READ LOCK طوال مدة النسخة الاحتياطية.

عند الانتهاء، ابدأ النسخ المتماثل مرة أخرى باستخدام START SLAVE

أيضًا، إذا كنت ترغب في إجراء نسخ احتياطي لسجلات bin-logs لإجراء نسخ احتياطية تزايدية أو كإجراء أمان إضافي، فمن المفيد إلحاق --flush-logs بالمتغير $dumpoptions أعلاه

Answer 3

أنت الخيار الثاني يشبه المسار الصحيح.

اضطررت إلى معرفة وسيلة للقيام النسخ الاحتياطية التفاضلية باستخدام mysqldump. انتهى بي الأمر بكتابة برنامج نصي اختار قواعد البيانات التي سيتم عملها احتياطيا ثم تنفيذ mysqldump. لا يمكن أن تنشئ برنامج نصي يتبع الخطوات المذكورة في http://dev.mysql.com/doc/refman/5.1/ar/mysqldump.html#option_mysqldump_master-data. واتصل بذلك من وظيفة كرون؟

1. الاتصال مع MySQL و "وقف العبد"
2. تنفيذ عرض حالة الرقيق
3. تخزين file_name، file_pos في المتغيرات
4. تفريغ وإعادة تشغيل العبد.

مجرد فكر ولكني أظن أنه يمكنك إلحاق خط "تغيير ماجستير إلى" إلى Dumpfile وسيتم تنفيذه عند استعادته / إعداد الرقيق الجديد.

Answer 4

باستخدام Read_Master_Log_POS كمركز للمتابعة من الماجستير يعني أنه يمكنك الانتهاء من البيانات المفقودة.

المتغير Read_master_log_pos هو الموضع في ملف السجل الثنائي الرئيسي الذي يرتكب مؤشر ترابط الرقيق IO.

المشكلة هنا هي أنه حتى في كمية صغيرة من الوقت بين إيقاف مؤشر ترابط Slave SQL وإعادة التقاط Read_Master_log_Pos قد تلقى مؤشر ترابط IO مزيدا من البيانات من برنامج Master الذي لم يتم تطبيقه بواسطة مؤشر ترابط SQL بعد إيقافه.

يؤدي ذلك إلى عرض Read_Master_Log_POS أكثر من البيانات التي يتم إرجاعها في MySQLDump، وترك فجوة في البيانات عند المستوردة واستمرت في عبدا آخر.

القيمة الصحيحة للاستخدام في الرقيق هي exec_master_log_pos، وهو الموقع في ملف السجل الثنائي الرئيسي الذي تم تنفيذ مؤشر ترابط SQL الرقيق، مما يعني عدم وجود فجوة بيانات بين mysqldump و exec_master_log_pos.

باستخدام برنامج Ross's Script فوق الاستخدام الصحيح سيكون:

# MySQL executable location
mysql=/usr/bin/mysql

# MySQLDump executable location
mysqldump=/usr/bin/mysqldump

# MySQL Username and password
userpassword=" --user=<username> --password=<password>"

# MySQL dump options
dumpoptions=" --quick --add-drop-table --add-locks --extended-insert"

# Databases to dump
databases="db1 db2 db3"

# Backup Directory
# You need to create this dir
backupdir=~/mysqldump


# Stop slave sql thread

echo -n "Stopping slave SQL_THREAD... "
mysql $userpassword -e 'STOP SLAVE SQL_THREAD;'
echo "Done."

set `date +'%Y %m %d'`

# Get Binary Log Positions

echo "Logging master status..."
masterlogfile=`$mysql $userpassword -e 'SHOW SLAVE STATUS \G' | grep '[^_]Master_Log_File'`
masterlogpos=`$mysql $userpassword -e 'SHOW SLAVE STATUS \G' | grep 'Exec_Master_Log_Pos'`

# Write log Info

echo $masterlogfile
echo $masterlogpos
echo $masterlogfile >> ${backupdir}/$1-$2-$3_info.txt
echo $masterlogpos >> ${backupdir}/$1-$2-$3_info.txt

# Dump the databases

echo "Dumping MySQL Databases..."
for database in $databases
do
echo -n "$database... "
$mysqldump $userpassword $dumpoptions $database | gzip - > ${backupdir}/$1-$2-$3_${database}.sql.gz
echo "Done."
done

# Start slave again

echo -n "Starting slave... "
$mysql $userpassword -e 'START SLAVE'
echo "Done."

echo "All complete!"

exit 0

Answer 5

يبدو أن mysqldump (في 5.6) لديه خيار - عبدا - عبدا عند تنفيذها على عبوة يسجل أرقام السجل الثنائي للمدرجة أن العقدة كانت عبدا. نية مثل هذه التفريغ هي بالضبط ما تصفه.

(أنا متأخر، وأنا أعلم)