English | 简体中文 | 繁體中文 | Русский язык | Français | Español | Português | Deutsch | 日本語 | 한국어 | Italiano | بالعربية
كل من عمل على نظام كبير يعلم أن دور السجلات لا يمكن تجاهله، غالباً ما يتم اتخاذ قرارات تحسين وتحديث المشروع بناءً على السجلات في المراحل المتأخرة من المشروع. لذا، فإن دراسة MySQL، جزء السجلات بالطبع لا يمكن تجاوزه. جميع التحسينات التي نتحدث عنها في المقابلات العملية تأتي من السجلات. دراسة سجلات MySQL بشكل شامل تساعدنا على تحديد المشاكل بشكل دقيق وتحسين مستوى عملنا. بالإضافة إلى ذلك، سينتمي سلسلة السجلات التالية إلى جانب التشغيل من قبل مدير قاعدة البيانات، لفهم إعدادات MySQL بشكل شامل، لفهم الذات والآخر، وجعل MySQL مخزن بيانات يمكن الوصول إليه بسهولة.
الجزء الأول: أنواع سجلات MySQL
بشكل افتراضي، جميع سجلات MySQL مخزنة كملفات في مجلد جذور قاعدة البيانات:
[root@roverliang data]# pwd /usr/local/webserver/extend_lib/mysql/data [root@roverliang data]# ls auto.cnf ibdata1 ib_logfile0 ib_logfile1 mysql mytest performance_schema roverliang roverliang.err roverliang.pid test
توجد أنواعًا مختلفة من سجلات MySQL من بينها:}}
السجل الخطأ (error)، يحتوي على معلومات حول بدء تشغيل أو تشغيل أو إنهاء تشغيل خدمة MySQL.
السجل العادي (general)، يحتوي على جميع تعليمات SQL أو الأوامر التي تنفذها خدمة MySQL.
السجل الثنائي (binary)، يحتوي على جميع تعليمات التحديث التي يتم تنفيذها على قاعدة البيانات، باستثناء تعليمات select وshow.
السجل البطيء (slow)، يحتوي على تعليمات SQL التي تستغرق وقت تنفيذ أطول من قيمة long_query_time المحددة، أو تعليمات SQL لا تستخدم المؤشرات.
الجزء الثاني: تخزين سجلات MySQL
نظام سريع ومستقر وموثوق به، يلعب التخزين المؤقت فيه دورًا حاسمًا. يستخدم معالج سجلات MySQL أيضًا ميكانيكية التخزين المؤقت. يتم تخزين سجلات MySQL أولاً في ذاكرة نموذج خدمة MySQL، إذا تجاوزت الكمية المحددة من الحجم، يتم كتابة سجلات الذاكرة (أو تحديثها) إلى الذاكرة الخارجية، ويتم حفظها إلى الأبد على القرص الصلب كجدول أو ملف.
الجزء الثالث: سجل الأخطاء لMySQL (error log)
يحتوي سجل الأخطاء لMySQL بشكل رئيسي على تفاصيل كل مرة يبدأ فيها نموذج خدمة MySQL أو ينتهي، بالإضافة إلى تحذيرات أو أخطاء تحدث أثناء تشغيل نموذج MySQL. على عكس السجلات الأخرى، يجب تشغيل سجل الأخطاء لMySQL وعدم إيقافه.
بالتجريد، يكون اسم ملف سجل الأخطاء: اسم المضيف.err. ولكن لا يسجل سجل الأخطاء جميع الأخطاء، بل يسجل فقط الأخطاء (critical) التي تحدث أثناء تشغيل نموذج خدمة MySQL.
mysql> show variables like 'log_error'\G *************************** 1. row *************************** اسم المتغير: log_error القيمة: /usr/local/webserver/extend_lib/mysql/data/roverliang.err 1 سطر في المجموعة (0.02 ثانية)
الجزء الرابع: سجل العمليات العادية لMySQL (general log)
MySQL عادةً يسجل سجلات العمليات التي يقوم بها نموذج خدمة MySQL، مثل select،update،insert،delete وما إلى ذلك، بغض النظر عما إذا كانت هذه العمليات تنجح في التنفيذ. بالإضافة إلى ذلك، يحتوي سجل العمليات العادية على معلومات حول اتصال وإنهاء اتصال عميل MySQL مع خدمة MySQL، بغض النظر عما إذا كانت الاتصالات تنجح أم لا. هناك ثلاثة معلمات مرتبطة بسجل العمليات العادية لMySQL.
[]()general_log mysql> show variables like 'general_log'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | general_log | OFF | +---------------+-------+ 1 row in set (0.01 sec)
يمكن تشغيل سجلات الاستعلام العادي باستخدام الأمر set @@global.general_log = 1.
mysql> set @@global.general_log =1; mysql> show variables like 'general_log'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | general_log | ON | +---------------+-------+
لكن تعديل متغيرات MySQL بهذه الطريقة سيكون فعالًا فقط خلال تشغيل وحدة MySQL الحالية، وسيعود إلى حالة التشغيل الافتراضية عند إعادة تشغيل MySQL. الطريقة الدائمة لتطبيق التغيير هي تعديل ملف my.cnf الخاص بـ mysql. يمكنك إضافة ما يلي إلى ملف التكوين:
general_log = 1
general_log_file
إذا تم تشغيل سجلات الاستعلام العادي، فإن وحدة خدمة MySQL ستجد سجلات الاستعلام العادي تلقائيًا، وتم تعيين معامل general_log_file لتعيين موقع ملف سجلات الاستعلام العادي. مثلما يلي:
mysql> show variables like 'general_log_file'; +------------------+-----------------------------------------------------------+ | Variable_name | Value | +------------------+-----------------------------------------------------------+ | general_log_file | /usr/local/webserver/extend_lib/mysql/data/roverliang.log | +------------------+-----------------------------------------------------------+
ملاحظة: نظرًا لأن سجلات الاستعلام العادي تقوم بتسجيل تقريبًا جميع العمليات في MySQL، فإن تشغيل سجلات الاستعلام العادي في خادم قاعدة البيانات الذي يتم فيه الوصول إلى البيانات بشكل متكرر يمكن أن يقلل من أداء قاعدة البيانات بشكل كبير. لذلك، يُنصح بتعطيل سجلات الاستعلام العادي. يمكن فتح سجلات الاستعلام العادي بشكل مؤقت فقط في أوقات خاصة، مثل الحاجة إلى تتبع بعض سجلات الاستعلام الخاصة.
log_output
تم تعيين معامل log_output لتخزين محتويات سجلات الاستعلام العادي وسجلات الاستعلام البطيئة في جدول قاعدة البيانات. يمكن استخدام الأمر set @@global.log_output='table' لتحديد أن يتم تخزين سجلات الاستعلام العادي وسجلات الاستعلام البطيئة في جدول general في قاعدة البيانات النظامية الخاصة بـ mysql وجدول slow_log. يجب الانتباه إلى أن محركات التخزين لهذه الجداول هي CSV، وبالتالي يمكن استخدام جملة SQL لعرض محتويات سجلات الاستعلام العادي الجديدة;
set @@global.log_output = 'table'; mysql> show variables like 'log_output'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | log_output | TABLE | +---------------+-------+
خامسًا، سجلات الاستعلام البطيئة لـ MySQL (slow log)
أسئلة حول سجلات الاستعلام البطيئة، يتم تقدير من قبل المسؤولين في المقابلات. كان يمكن في الماضي فقط مناقشة هيكل MySQL الرئيسي من خلال تحسين MySQL من جميع الجوانب، ولكن لم يتم التحقق من كيفية تشغيل سجلات الاستعلام البطيئة وكيفية تكوينها.
يمكن استخدام سجلات الاستعلام البطيئة في MySQL لمراقبة استعلامات تأخذ وقتًا طويلاً أو لا تستخدم المؤشرات. تشمل هذه الاستعلامات استعلامات select، استعلامات update، استعلامات delete، واستعلامات insert، مما يساعد في تحسين الاستعلامات. على عكس سجلات الاستعلام العادية، تحتوي سجلات الاستعلام البطيئة فقط على استعلامات تم تنفيذها بنجاح. هناك خمس متغيرات تتعلق بسجلات الاستعلام البطيئة في MySQL.
1. slow_query_log
slow_query_log يُستخدم لتحديد ما إذا كان سجل الاستعلام البطيئ مفعلاً.
mysql> show variables like 'slow_query_log'; +----------------+-------+ | Variable_name | Value | +----------------+-------+ | slow_query_log | OFF | +----------------+-------+
2. slow_query_log_file
بمجرد تشغيل سجلات الاستعلام البطيئة، سيقوم مثيل MySQL تلقائيًا بإنشاء ملف سجلات الاستعلام البطيئة. يتم حفظ محتويات سجلات الاستعلام البطيئة في الملف المحدد بواسطة slowquerylog_file. يمكن تعديل الطريقة كما هو موضح في النص السابق. قم بتغيير إعدادات ملف my.cnf مباشرة.
3. long_query_time
long_query_time تم تعيين مستوى الحد الزمني للاستعلام البطيئ. القيمة الافتراضية هي 10 ثانية.
4. log_quries_not_using_indexes
هل سيتم تسجيل استعلامات لا تستخدم المؤشرات في سجلات الاستعلام البطيئة، بغض النظر عن سرعة الاستعلام؟
mysql> set @@global.log_queries_not_using_indexes=1; mysql> show variables like 'log_queries_not_using_indexes'; +-------------------------------+-------+ | Variable_name | Value | +-------------------------------+-------+ | log_queries_not_using_indexes | ON | +-------------------------------+-------+
النقطة الخامسة: log_output
تم تعيين شكل ملفات السجلات العادية وسجلات الاستعلام البطيئ، ويوجد قيمتان هما file وtable;
الجزء السادس: عرض سجلات الاستعلام البطيئ في MySQL
يمكن تعيين معامل log_output لتحديد شكل ملف سجلات الاستعلام البطيئ. الافتراضي هو FILE، يمكن تعيينه كـ TABLE;
mysql> desc mysql.slow_log; +----------------+---------------------+ | Field | Type | +----------------+---------------------+ | start_time | timestamp | | user_host | mediumtext | | query_time | time | | lock_time | time | | rows_sent | int(11) | | rows_examined | int(11) | | db | varchar(512) | | last_insert_id | int(11) | | insert_id | int(11) | | server_id | int(10) unsigned | | sql_text | mediumtext | | thread_id | bigint(21) unsigned | +----------------+---------------------+
من بينها: lock_time يعني الوقت الذي يتم فيه حظر تنفيذ SQL. rows_send يعني عدد السطور المرسلة بعد تنفيذ SQL. rows_examined يعني عدد السجلات الممسوحة أثناء تنفيذ SQL.
لكن استخدام TABLE لتخزين سجلات الاستعلام البطيئ ليس شائعًا، في حالة وجود كميات كبيرة من العمل، سيكون هناك تأثير على الخدمة الرئيسية للنظام. يمكننا استخدام طريقة FILE لتخزين السجلات. عند تثبيت MySQL، تم تثبيت أداة mysqldumpslow.pl بشكل افتراضي في مجلد bin لـ MySQL لتحليل سجلات الاستعلام البطيئ. قد تحتاج إلى بعض التكوينات عند استخدام هذه الأداة في Windows، ولم يكن ذلك في نطاق هذا المقال، لذا ننصحك بتعلم خدمات النظام في Linux. يمكن استخدام الأوامر والأدوات في Linux باستخدام خيار --help مع الأوامر نفسها لعرض المساعدة.
-s يعني كيفية الترتيب
خيارات الفرعية: c، t، l، r
c: عدد مرات تنفيذ SQL
t: وقت التنفيذ
l: وقت الانتظار على القفل
r: العودة إلى عدد السجلات
at، al، ar هي متوسطات t، l، r. -t: يعني العودة إلى N سجل.
-g: اختصار grep. يحتوي على مطابقة غير محددة
استخدامات شائعة كما يلي:
//يعود يحتوي على 20 تعليمات SQL تحتوي على أكبر عدد من الأدوار ./mysqldumpslow -s c -t 20 /usr/local/webserver/extend_lib/mysql/data/roverliang-slow.log //يعود يحتوي على 20 تعليمات SQL تحتوي على أكبر عدد من السجلات ./mysqldumpslow -s r -t 20 /usr/local/webserver/extend_lib/mysql/data/roverliang-slow.log //يعود يحتوي على تعليمات SQL تحتوي على like ./mysqldumpslow -g 'like' 20 /usr/local/webserver/extend_lib/mysql/data/roverliang-slow.log
الجلسة السابعة: مجلدات الثنائية (binary)
مجلدات الثنائية تختلف عن أنواع المجلدات المذكورة مسبقًا، لا يمكن عرض الثنائية مباشرة باستخدام cat أو مشاهدات النص مثل less. يتطلب ذلك أدوات متخصصة. يُسجل في مجلدات الثنائية تغييرات قاعدة البيانات، لذا يمكن استخدامها لسحب البيانات بين المستودعات الرئيسية والفرعية. تتضمن المحتويات جميع عمليات تحديث قاعدة البيانات، استبدال use، استبدال insert، استبدال delete، استبدال update، استبدال create، استبدال alter، استبدال drop. يمكن تلخيصها بعبارة بسيطة وسهلة الفهم: يجب تسجيل جميع العمليات التي تتعلق بالتغييرات في البيانات في مجلدات الثنائية.
بدء سجل السجل الثنائي استخدم الأمر show variables like 'log_bin'\G للتحقق من تشغيل سجل السجل الثنائي.
mysql> show variables like 'log_bin'\G
*************************** 1. row ***************************
اسم المتغير: log_bin
القيمة: معطلة
1 سطر في مجموعة (0.00 ثانية)
mysql> set @@global.log_bin=1;
خطأ 1238 (HY000): المتغير 'log_bin' هو متغير قابل للقراءة فقط
mysql>
ترى log_bin غير المفعلة بشكل افتراضي وهي متغير قابلة للقراءة فقط، يجب تكوينها في my.cnf ثم إعادة تشغيل MySQL. تشغيل الأمر service mysql restart لإعادة تشغيل MySQL، بعد ذلك في مجلد data سيتم إنشاء ملف 1.000001. في الواقع، في كل مرة يتم فيها إعادة تشغيل MySQL، يتم إنشاء ملف مثل هذا في الدليل، وسيكون اسم الملف متدرجاً. بالإضافة إلى ذلك، سيقوم MySQL بإنشاء ملف محور سجل ثنائي في هذا الدليل، يمكن التحقق من موقع ملف المحور باستخدام الأمر show variables like 'log_bin_index'\G، ثم استخدام الأمر cat لمعاينة. سيكون هناك سجلات لمناسيب الملفات الثنائية.
للتحقق من سجل السجل الثنائي يمكن استخدام أدوات MySQL المدمجة. الموقع في مجلد bin لـ mysql. خيارات الأمر mysqlbinlog الشائعة:
-s عرض محتويات السجل بشكل مختصر
-v عرض محتويات السجل بشكل مفصل
-d=اسم قاعدة البيانات عرض محتويات السجل لقاعدة البيانات المحددة فقط
-o=n تجاهل n سطراً أولاً من أوامر MySQL في السجل
-r=file كتب محتوى الملف المحدد في ملف معين
--start-datetime
عرض محتويات السجل في نطاق التاريخ المحدد
--stop-datetime
--start-position
عرض محتويات السجل بين المواضع المحددة
--stop-position
الحصول على ملف السجل الثنائي الحالي
mysql> show master status; +----------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +----------+----------+--------------+------------------+-------------------+ | 1.000002 | 120 | | | | +----------+----------+--------------+------------------+-------------------+ 1 سطر في مجموعة (0.00 ثانية)
استعادة البيانات باستخدام السجلات الثنائية
النحو بسيط جداً:
mysqlbinlog -s 1.000001 | mysql -h 192.168.1.188 -u root -p
يمكن اتباع mysqlbinlog بـ --start-datetime و --stop-datetime و start-position و stop-position وغيرها من العوامل.
--start-datetime و --stop-datetime هاتان العاملتان يمكن استخدامهما لاستعادة البيانات بناءً على نقاط زمنية;
start-position و stop-position يمكن استخدامهما لتحديد نقاط تحديدية دقيقة لاستعادة البيانات;
MySQL الحزم الثنائية المرتبطة بالسجلات
mysql> show variables like '%binlog%'; +-----------------------------------------+----------------------+ | Variable_name | Value | +-----------------------------------------+----------------------+ | binlog_cache_size | 32768 | | binlog_checksum | CRC32 | | binlog_direct_non_transactional_updates | OFF | | binlog_error_action | IGNORE_ERROR | | binlog_format | STATEMENT | | binlog_gtid_simple_recovery | OFF | | binlog_max_flush_queue_time | 0 | | binlog_order_commits | ON | | binlog_row_image | FULL | | binlog_rows_query_log_events | OFF | | binlog_stmt_cache_size | 32768 | | binlogging_impossible_mode | IGNORE_ERROR | | innodb_api_enable_binlog | OFF | | innodb_locks_unsafe_for_binlog | OFF | | max_binlog_cache_size | 18446744073709547520 | | max_binlog_size | 1073741824 | | max_binlog_stmt_cache_size | 18446744073709547520 | | simplified_binlog_gtid_recovery | OFF | | sync_binlog | 0 | +-----------------------------------------+----------------------+
max_binlog_size
maxbinlogsize حجم ملف السجل الثنائي الواحد. إذا تجاوز هذا الحد، يتم إنشاء ملف جديد، واسم النهاية +1؛
binlog_cache_size
binlogcachesize حجم المخزن المؤقت للسجلات الثنائية في الذاكرة.
sync_binlog
sync_binlog يكتب مرة أخرى في مخزن التخزين ثنائي النسخ، ثم يبدأ في تحديث التزامن إلى الذاكرة الخارجية (القرص الصلب).
log_slave_updates
logslvaeupdates用于主从复制
تنظيف سجلات الثنائية
بشكل عام يجب أولاً إجراء نسخ احتياطية مادية للسجلات التي سيتم تنظيفها إلى أجهزة تخزين أخرى، للحفاظ عليها دائمًا. ثم يُنصح باستخدام أحد الطرق التالية للتنظيف التي تقلل من المخاطر:
第一种：
purge master logs before '2017-02-16 00:00:00';
النوع الثاني:
يمكنك تعيين معاملته expire_logs_days في ملف تكوين MySQL my.cnf لتحديد عدد أيام انتهاء صلاحية ملفات الثنائية، وسيتم حذف الملفات الثنائية القديمة تلقائيًا. يُنصح ببدء مهمة خطة المواعيد الزمنية الجديدة قبل الحذف، لتحديد النسخ الاحتياطية للملفات الثنائية بشكل دوري. لتجنب فقدان بعض البيانات لأيام عديدة بعد اكتشاف وجود خطأ، وسيتم حذف سجلات الثنائية تلقائيًا.
expire_logs_days=90
ثامنًا، سجلات المعاملات الخاصة بـ InnoDB
سجلات المعاملات الخاصة بـ InnoDB مختلفة عن السجلات التي ذكرناها من قبل، سجلات المعاملات الخاصة بـ InnoDB يتم حفظها بشكل مستقل من قبل محرك التخزين InnoDB، و لا يمكن للإداريين البيانيين قراءتها. MySQL يستخدم كثيرًا من ذاكرة التخزين المؤقت لزيادة كفاءة الوصول إلى البيانات. لذا يمكننا القول أيضًا، أن أي نظام عالي الأداء يجب أن يستخدم ذاكرة التخزين المؤقت، من جميع الجوانب، تلعب ذاكرة التخزين المؤقت دورًا كبيرًا. إذا نحن نرقي إلى مستوى أعلى من التعبير، فإن ذاكرة التخزين المؤقت وخطط الانتظار هي الطريق الذي يجب أن يسلكه لتحقيق الأداء العالي. بالنسبة لقاعدة البيانات، هذا مشكلة معقدة، حيث يجب ضمان قراءة وتخزين البيانات بسرعة، لذا يجب استخدام ذاكرة التخزين المؤقت. ولكن لضمان التزامن البياني، يجب ضمان أن يتم تخزين جميع البيانات بشكل دقيق في قاعدة البيانات، حتى في حالة حدوث أي مشكلة، يجب ضمان أن البيانات قابلة للاستعادة. نحن نعلم أن InnoDB هو محرك تخزين آمن للمعاملات، وأن التزامن هو ميزة مهمة في ACID. يتم تحقيق التزامن البياني من خلال سجلات المعاملات الخاصة بـ InnoDB، التي تشمل سجلات التأكيد (redo) وسجلات التراجع (undo).
سجلات التأكيد (redo)
سجلات التأكيد (redo) تُسجل بشكل رئيسي المعاملات التي تم إكمالها بالكامل، أي سجلات تم تنفيذ commit، في الحالة الافتراضية، يتم تسجيل قيم سجلات التأكيد في ملفات iblogfile0 وiblogfile1.
[root@roverliang data]# pwd /usr/local/webserver/mysql/data [root@roverliang data]# ls ib* ibdata1 ib_logfile0 ib_logfile1
سجلات التراجع (undo)
سجلات التراجع (undo) تُسجل بشكل رئيسي المعاملات التي تم إكمالها جزئيًا وتسجيلها على القرص الصلب، في الحالة الافتراضية، يتم تسجيل معلومات سجلات التراجع في ملفات مساحة العمل، ملفات مساحة العمل المشتركة ibdata1 أو ملفات مساحة العمل المخصصة لمستخدمين معينين في ibd.
بالمعادلة السابقة يمكننا معرفة أن سجلات التراجع يتم تسجيلها بشكل افتراضي في ibdta1. إصدار نظام MySQL الخاص بي هو: 5.6.24.
آلية نقطة التحقق
بعد انهيار الخادم MySQL، عند إعادة تشغيل خدمة MySQL، بسبب وجود سجلات إعادة التدوين (redo) وسجلات التراجع (undo)، يقوم InnoDB بإلغاء جميع المعاملات التي تم إكمالها جزئيًا ولكن لم يتم كتابتها بعد في القرص الصلب من خلال سجلات التراجع (undo) من خلال سجلات إعادة التدوين (redo). ثم يتم إعادة تنفيذ جميع المعاملات في سجلات إعادة التدوين (undo) مرة أخرى لاستعادة جميع البيانات. ولكن إذا كانت كمية البيانات كبيرة، فإن InnoDB يقدم آلية نقطة التحقق لقصر وقت الإصلاح.
الصفحة القذرة (dirty page)
عندما يحتاج المعامل إلى تعديل سجل معين، يقوم InnoDB أولاً بقراءة الكتلة التي تحتوي على البيانات من خارج الذاكرة إلى القرص الصلب، بعد تقديم المعامل، يقوم InnoDB بتعديل السجل في صفحة البيانات، في هذه الحالة تكون الصفحة الذاكرية المؤقتة قد تغيرت عن الكتلة في خارج الذاكرة، وتسمى الصفحة الذاكرية المؤقتة (dirty page). يتم إعادة كتابة الصفحة القذرة إلى خارج الذاكرة، وتصبح صفحة نظيفة (clean page).
ملاحظة: الصفحة الذاكرية الافتراضية هي 4K أو مضاعف 4K. يمكنك تخيل الذاكرة ككتاب يمكن مسحه، حيث يتم طلب بعض الصفحات النظيفة من الذاكرة عند قراءة MySQL للبيانات، ثم يتم كتابة عليها. عند إعادة كتابة البيانات إلى القرص الصلب، يتم مسح هذه الصفحات الفارغة على الفور لاستخدامها من قبل برامج أخرى.
رقم سلسلة السجل (log sequence number)
رقم سلسلة السجل (LSN) هو نقطة النهاية لكل سجل في مساحة السجلات، تمثل بالتحويل البايتي، تستخدم في نقطة التحقق وإصلاح البيانات.
مبدأ آلية نقطة التحقق (Checkpoint) افترض في وقت معين، جميع الصفحات القذرة (dirty page) قد تمت إعادة كتابتها إلى القرص الصلب، لا يحتاج إلى إعادة كتابة جميع سجلات إعادة التدوين (redo) قبل هذا الوقت. يعتبر النقطة التي تنتهي فيها سجلات إعادة التدوين النقطة التي تعتبر نقطة التحقق، ولا يحتاج إلى إعادة كتابة سجلات إعادة التدوين قبل نقطة التحقق، يمكن حذفها بثقة. من أجل استخدام مساحة سجلات إعادة التدوين (redo) بشكل أفضل، يستخدم InnoDB استراتيجية الدوران في استخدام مساحة سجلات إعادة التدوين، لذا يجب أن تكون ملفات سجلات إعادة التدوين في InnoDB على الأقل 2. من خلال آلية نقطة التحقق، يتم إعادة كتابة جميع المعاملات التي تم إكمالها ولكن لم يتم كتابتها بعد في ذاكرة التخزين المؤقت إلى خارج الذاكرة (undo) من خلال سجلات إعادة التدوين (redo)، مما يضمن توافق البيانات ويقصر وقت الإصلاح.
م参数ات سجل إعادة التدوين (redo) لـ InnoDB
innodb_log_buffer_size: قام بتعيين حجم حافظة سجلات إعادة التدوين.
innodb_log_files_in_group : قام بتعيين عدد سجلات إعادة التدوين (redo) في مجموعة ملفات السجلات.
innodb_log_file_size: يحدد حجم ملفات سجلات التكرار، وكلما زاد حجم الملف، كلما استغرقت عملية الاستعادة وقتًا أطول.
innodb_mirrored_log_groups: يحدد عدد مجموعات ملفات سجلات التكرار، ويجب إعدادها على 1 فقط.
innodb_log_group_home_dir: يحدد الدليل الذي يتم فيه حفظ ملفات مجموعة سجلات الدخول، والقيمة الافتراضية هي في مجلد جذور قاعدة البيانات.
معلمات سجلات التراجع (undo) لـ InnoDB
innodb_undo_directory: يحدد الدليل الذي يتم فيه حفظ سجلات التراجع.
innodb_undo_logs: يحدد حجم سجلات التراجع، والقيمة الافتراضية هي 128k
innodb_undo_tablespace: يحدد عدد ملفات سجلات التراجع التي تشكل سجلات التراجع، والقيمة الافتراضية هي 0.
تحذير: بعد تثبيت MySQL، يجب إعداد معلمات سجلات التراجع في ملف my.cnf. إذا تم إنشاء قاعدة البيانات بعد إعداد معلمات سجلات التراجع، سيقوم MySQL بتقديم خطأ، وسيكون من المستحيل تعديل أو إضافة سجلات التراجع بعد إنشائها.
الجزء التاسع: نسخ احتياطي ملفات السجلات
يمكن استخدام flush logs عند إجراء النسخ الاحتياطي، لإغلاق جميع ملفات السجلات الحالية، ثم إنشاء ملفات سجلات جديدة. بعد إغلاق ملفات السجلات، يمكنك إجراء النسخ الاحتياطي بشكل مادي. بالإضافة إلى ذلك، يمكن إضافة نوع محدد من السجلات إلى flush logs:
flush error logs flush general logs flush binary logs flush slow logs
بيان: محتوى هذا المقال تم جمعه من الإنترنت، يحق للمالك الأصلي الحصول عليه، تم جمع المحتوى من قبل المستخدمين عبر الإنترنت بطرق متعددة، هذا الموقع لا يمتلك حقوق الملكية، لم يتم تعديل المحتوى بشكل يدوي، ولا يتحمل هذا الموقع أي مسؤولية قانونية متعلقة بذلك. إذا اكتشفت محتوى يشتبه في انتهاك حقوق النسخ، فلا تتردد في إرسال بريد إلكتروني إلى: notice#oldtoolbag.com (عند إرسال البريد الإلكتروني، يرجى استبدال # ب @) لإبلاغنا، وتقديم الدليل المتعلق، وستقوم الموقع على الفور بإزالة المحتوى المزعوم.