it-swarm.asia

هل من الآمن استخدام innodb_flush_log_at_trx_commit = 2

انا ألتفت innodb_flush_log_at_trx_commit = 2 واحصل على سرعة كتابة سريعة جدًا. ولكن هل يمكن استخدامها بأمان في موقع الإنتاج؟

57
Bruce Dou

يمكنك أن تخسر ما يصل إلى ثانية من المعاملات. القيمة الافتراضية هي 1 ، مما يساعد على إبقاء InnoDB متوافق مع ACID .

وفقًا لوثائق MySQL على innodb_flush_log_at_trx_commit

إذا كانت قيمة innodb_flush_log_at_trx_commit تساوي 0 ، تتم كتابة المخزن المؤقت للتسجيل في ملف السجل مرة واحدة في الثانية ويتم تنفيذ عملية التدفق إلى القرص على ملف السجل ، ولكن لا يتم فعل أي شيء عند تنفيذ المعاملة. عندما تكون القيمة 1 (الافتراضية) ، يتم كتابة المخزن المؤقت للتسجيل في ملف السجل عند كل عملية تنفيذ ويتم تنفيذ عملية التدفق إلى القرص على ملف السجل. عندما تكون القيمة 2 ، يتم كتابة المخزن المؤقت للتسجيل في الملف عند كل التزام ، ولكن لا يتم تنفيذ عملية التدفق إلى القرص عليه. ومع ذلك ، يتم إجراء مسح على ملف السجل مرة واحدة في الثانية أيضًا عندما تكون القيمة 2. لاحظ أن التنظيف مرة واحدة في الثانية ليس مضمونًا بنسبة 100٪ في كل ثانية ، بسبب مشاكل جدولة العملية.

القيمة الافتراضية 1 مطلوبة للتوافق الكامل مع ACID. يمكنك تحقيق أداء أفضل عن طريق تعيين قيمة مختلفة عن 1 ، ولكن بعد ذلك قد تفقد ما يصل إلى ثانية واحدة من المعاملات في حالة تعطل. مع قيمة 0 ، يمكن لأي تعطل عملية الخلية أن يمحو الثانية الأخيرة من المعاملات. مع قيمة 2 ، يمكن فقط لحالة تعطل نظام التشغيل أو انقطاع التيار الكهربائي محو آخر ثانية من المعاملات. يعمل استرداد التعطل في InnoDB بغض النظر عن القيمة.

للحصول على أكبر قدر ممكن من المتانة والاتساق في إعداد النسخ المتماثل باستخدام InnoDB مع المعاملات ، استخدم innodb_flush_log_at_trx_commit = 1 و sync_binlog = 1 في ملف my.cnf الخاص بالخادم الرئيسي.

الحذر

تخدع العديد من أنظمة التشغيل وبعض أجهزة القرص عملية التدفق إلى القرص. قد يخبرون الخلية أن التدفق قد حدث ، على الرغم من أنه لم يحدث. ثم لا يتم ضمان متانة المعاملات حتى مع الإعداد 1 ، وفي أسوأ الحالات يمكن أن يؤدي انقطاع التيار الكهربائي إلى تلف قاعدة بيانات InnoDB. يؤدي استخدام ذاكرة التخزين المؤقت للقرص المدعومة بالبطارية في وحدة تحكم القرص SCSI أو في القرص نفسه إلى زيادة سرعة تدفق الملفات ، ويجعل العملية أكثر أمانًا. يمكنك أيضًا محاولة استخدام الأمر hdparm الخاص بـ Unix لتعطيل التخزين المؤقت لعمليات الكتابة على القرص في ذاكرة التخزين المؤقت للأجهزة ، أو استخدام أمر آخر خاص ببائع الجهاز.

وبناءً على ذلك ، فإن القيم بخلاف 1 تضع InnoDB في خطر فقدان قيمة المعاملات لمدة ثانية واحدة ، أو قيمة بيانات التزام المعاملة.

وتقول الوثائق أيضا استخدام sync_binlog=1.

وفقًا لوثائق MySQL على sync_binlog

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

اختيارك الآمن هو

[mysqld]
innodb_flush_log_at_trx_commit=1
sync_binlog=1

إذا كنت لا تمانع فقدان البيانات المحتمل (تصل إلى ثانية واحدة) ، فيمكنك استخدام إما 0 أو 2 على مسؤوليتك الخاصة إذا كانت المكافآت (سرعة كتابة أسرع) تستحق ذلك.

59
RolandoMySQLDBA

ال innodb_flush_log_at_trx_commit يستخدم لغرض ..

إذا كانت قيمة innodb_flush_log_at_trx_commit يساوي 0 ، ويتم تخزين المخزن المؤقت للتسجيل في ملف السجل مرة واحدة في الثانية ويتم تنفيذ عملية التدفق إلى القرص على ملف السجل ، ولكن لا يتم تنفيذ أي شيء عند تنفيذ المعاملة.

عندما تكون القيمة 1 (الافتراضية) ، يتم كتابة المخزن المؤقت للتسجيل في ملف السجل عند كل عملية تنفيذ ويتم تنفيذ عملية التدفق إلى القرص على ملف السجل.

عندما تكون القيمة 2 ، يتم كتابة المخزن المؤقت للتسجيل في الملف عند كل التزام ، ولكن لا يتم تنفيذ عملية التدفق إلى القرص عليه. ومع ذلك ، يتم إجراء مسح على ملف السجل مرة واحدة في الثانية أيضًا عندما تكون القيمة 2. لاحظ أن التنظيف مرة واحدة في الثانية ليس مضمونًا بنسبة 100٪ في كل ثانية ، بسبب مشاكل جدولة العملية.

القيمة الافتراضية 1 مطلوبة للتوافق الكامل مع ACID. يمكنك تحقيق أداء أفضل عن طريق تعيين قيمة مختلفة عن 1 ، ولكن بعد ذلك قد تفقد ما يصل إلى ثانية واحدة من المعاملات في حالة تعطل. مع قيمة 0 ، يمكن لأي تعطل عملية الخلية أن يمحو الثانية الأخيرة من المعاملات. مع قيمة 2 ، يمكن فقط لحالة تعطل نظام التشغيل أو انقطاع التيار الكهربائي محو آخر ثانية من المعاملات. يعمل استرداد التعطل في InnoDB بغض النظر عن القيمة.

في رأيي باستخدام innodb_flush_log_at_trx_commit إلى 2 لا ينبغي أن يكون مشكلة ، ولكن استخدام 1 هو الأكثر أمانًا.

26
Abdul Manaf

رأيي يختلف عن الآخر. innodb_flush_log_at_trx_commit = 0 إذا: كان جهاز الكمبيوتر الخاص بي أو قاعدة بيانات المنزل الصغيرة حيث لا توجد بيانات حساسة.

innodb_flush_log_at_trx_commit = 2 if: إنها مدونة/إحصائيات/تجارة إلكترونية (مع ~ 100x متجر في اليوم) ، إلخ.

innodb_flush_log_at_trx_commit = 1 إذا: كان لديك الكثير من العملاء أو كنت بحاجة للعمل مع المعاملات المالية مثل البنوك. لذا هذه المرة يجب عليك تقسيم تدفق البيانات بين عدة خوادم للحصول على السرعة والأمان.

أنا أفضل 2 ، لأنه يحتوي على سرعة كتابة أسرع 75x تقريبًا ويفشل فقط في حالة فشل الأجهزة.

على أي حال ، يجب أن تعرف ما تحتاجه أكثر سرعة كتابة أو ما يصل إلى 1 ثانية من المعلومات؟

25
Sertekmedia

أحاول الإجابة ، ما هو الغرض من innodb_flush_log_at_trx_commit?

ينفذ InnoDB معظم عملياته في الذاكرة (InnoDB Buffer Pool). جميع البيانات المعدلة مكتوبة على InnoDB transaction log file ثم يتم مسحها (مكتوبة) إلى التخزين الدائم (القرص الصلب).

لسلامة البيانات (Durability from ACID) ، يتعين على InnoDB تخزين البيانات المعدلة لكل معاملة في مخزن دائم. في الوقت نفسه ، يعد الالتزام بالقرص لكل معاملة عملية مكلفة.

يعد القرص I/O عملية حظر وهو بطيء جدًا ، إنه قرص بطيء ، بالإضافة إلى أنه سيقلل عدد InnoDB transaction per seconds (إنتاجية القرص).

يوفر InnoDB متغير innodb_flush_log_at_trx_commit للتحكم في تردد عملية التدفق هذه. بناءً على القيمة ، تتصرف عملية تدفق InnoDB بشكل مختلف.

(شرح بالفعل في إجابات أخرى)

0 - اكتب إلى ملف السجل وانتقل إلى القرص في كل ثانية (البيانات في تجمع المخزن المؤقت لم تتم كتابتها إلى ملف السجل - للحصول على أداء). 1 - التدفق إلى القرص عند تنفيذ المعاملة - افتراضي (لسلامة البيانات - التوافق مع ACID) 2 - الكتابة إلى ملف السجل لكل المعاملات والدفقات إلى القرص في كل ثانية. (لكسب الأداء)

بناءً على متطلبات التطبيق (Performance Vs data safety) ، يمكنك تعيين هذا المتغير. الفرق بين 0 و 2 - كلاهما سيزيد الأداء ، والقيمة 2 تخزن البيانات في ملف المعاملة ويمكن استردادها ، في حالة حدوث عطل أو فشل ، ولكن ليس في 0.

في كثير من الحالات ، يعد التدفق إلى القرص وسيلة ، ويتم كتابة البيانات من InnoDB buffer pool (memory) to Operating systems cache غير المكتوبة بالفعل إلى قرص التخزين (التخزين الدائم). في حالة الفشل ، في أسوأ الأحوال ، قد تفقد البيانات حتى ثانية واحدة)

يعتمد اكتساب الأداء على البيئة ويمكنك قياسه وتحديده. في بيئة النسخ المتماثل ، لضمان سلامة البيانات واتساقها ، قم بتعيين innodb_flush_log_trx_commit = 1 و sync_binlog=1.

إذا كان الأداء هو الهدف الرئيسي للتطبيق ، فإن InnoDB يوفر متغيرًا للتحكم في تكرار تنظيف السجل - innodb_flush_log_at_timeout - والذي يسمح لك بتعيين نطاق تردد تنظيف السجل من 1 to 2700 seconds ، افتراضيًا هو 1.

كن على علم ، عندما تزيد من فترة التنظيف حتى N ثانية ، فإن مكاسب الأداء تأتي مع حل وسط في سلامة البيانات حتى N ثانية. على سبيل المثال - إذا قمت بتعيين تدفق في كل 5 ثوانٍ - يكون معدل النقل مرتفعًا جدًا ، ولكن في حالة انقطاع التيار الكهربائي أو تعطل النظام ، ستفقد بيانات بقيمة 5 ثوانٍ.

تناقش هذه المقالة حول عمليات فلاش InnoDB وارتكاب المعاملات .

يمكنك التغيير بعد القيام بالوضع 2 على aws rds:

can change after you do mode 2 on aws

previewchanges

غير قابل للتعديل في بعض الحالات مثل إذا كان لديك النسخ المتماثل متعدد الألف إلى الياء:

FYI unmodifiable in some cases

3
Rathish

إذا فشل الجهاز الخاص بك ، يمكنك أن تفقد جميع بياناتك ، لذلك أستخدم param = 2 دون أي قلق. على أي حال ، يمكنك تقسيم بياناتك الحساسة (طلب ، أموال افتراضية ، ...) والبيانات العادية (إحصائيات ، سلة تسوق ، ...) بين خوادم 2 ديسيبل والحفاظ عليها آمنة وسريعة. للمعاملات بين قواعد البيانات يمكنك استخدام http://dev.mysql.com/doc/refman/5.7/en/xa.html

1
Karolis Mačiulskis