قيود MySQL binlog

Question

لدي مثيل MySQL يعمل على AWS، مع حوالي 5000 إدراج في الثانية.هل لديك أي فكرة عن تأثير الأداء إذا استخدمت binlog (صف) ومصمم binlog؟

تحقق من هذا الرابط

من وجهة نظري، يقوم مصمم سجل bin باستقصاء سجل MySQL بشكل دوري من أجل جعل اتصال البيانات "في الوقت الفعلي" ممكنًا.يعمل مُصمم binlog في NodeJS.

النقطة المهمة هي أنه يجب علي استخدام MySQL وأريد استخدام Meteor للحصول على البيانات في الوقت الفعلي لعملائي.ومن هنا جاءت فكرتي لاستخدام هذا الخياط binlog.

نظرًا لأن قاعدة بيانات MySQL سيتم ملؤها بشكل مكثف (5000 إدخال في الثانية)، أريد أن أعرف عند أي نقطة يواجه مصمم binlog/binlog مشكلات خطيرة في الأداء.

جراتس، توم

Answer 1

لقد قمت بتطوير برنامج بوظائف مماثلة، والقدرة على استخدام تدفق النسخ المتماثل MySQL (السجل الثنائي، binlog) لالتقاط الأحداث في الوقت الفعلي تقريبًا استجابةً لعمليات الإدراج/التحديثات/الحذف في قاعدة البيانات.

فيما يلي بعض الملاحظات التي أدليت بها فيما يتعلق بالأداء.ولحسن الحظ، فإن النقاط الساخنة المحتملة مستقلة إلى حد كبير عن بعضها البعض.

سأفترض، نظرًا لأنني لم أكن على دراية بحزمة Node التي استشهدت بها ولم أقم إلا الآن فقط بإعطاء الكود الخاص بها مراجعة سريعة، أنهم في الواقع لا يقومون "بتتبع" السجل الثنائي عبر الاقتراع، ولكنهم في الواقع يحاكيون خادمًا تابعًا/نسخة متماثلة ويتصلون إلى السيد وطلب دفق النسخ المتماثل.

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

النقطة التالية لاستهلاك الموارد هي الاتصال التابع الذي تجريه هذه الأداة بالسيد، حيث يدفع السيد البيانات.من المفاهيم الخاطئة الشائعة أن العبد "يستجوب" سيده.في الواقع، يبدأ العبد الاتصال، لكن السيد يدفع البيانات.يعد هذا في الواقع حملًا على الجهاز الرئيسي وله تأثير ضئيل جدًا على الأداء عندما يكون عدد العبيد المتصلين صغيرًا (على سبيل المثال، 5 أو أقل).يمكن التخلص من هذا الحمل من السيد بالكامل عن طريق ربط "مصمم binlog" ليس بالسيد، ولكن بالعبد الموجود للسيد، مع log_slave_updates تم تكوينه.

يمكن أن يستهلك نقل البيانات من الجهاز الرئيسي إلى الجهاز التابع الزائف نطاقًا تردديًا كبيرًا للشبكة، لذا يجب أن تدعم الأداة الخارجية الخاصة بك بروتوكول ضغط العميل/الخادم MySQL لتقليل عرض النطاق الترددي هذا.يمكن أن يؤدي تمكين هذه الإمكانية إلى تحقيق نسب ضغط تبلغ 10:1 اعتمادًا على الحمولة.

نقطة الألم الأخيرة هي الأداة الخارجية نفسها.يعد تنسيق MySQL Binlog تنسيقًا ثنائيًا محكمًا للغاية (وبالتالي "السجل الثنائي") ويجب تحليله وفك تشفيره.ستحدد الكفاءة التي يمكن للأداة المساعدة الخارجية من خلالها تفريغ تدفق البيانات ومعالجته مدى قرب إصدار الأحداث المكتشفة من الوقت الفعلي، نظرًا لأن التعليمات البرمجية غير الفعالة ستتسبب في تأخر تدفق الحدث المحدد أكثر فأكثر عن الحدث الرئيسي، على الرغم من هذا العامل لن يكون لها أي تأثير على الأداء على الخادم الرئيسي نفسه.

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