إعادة شحن حساب Google Cloud: GCP Cloud SQL دليل استكشاف الأخطاء وإصلاحها في وقت متأخر للغاية مع Read Replica

في الساعة الثالثة من منتصف الليل من الأسبوع الماضي ، كسر جرس الإنذار الخاص بـ PagerDuty الصمت: تأخر Read Replica ، وهو عمل أساسي على الإنترنت ، وذهب مباشرة إلى 3600 ثانية (ساعة واحدة) ، وأبلغ الاستعلام عن العقدة للقراءة فقط بشكل متكرر عن الأخطاء ، ويجب فصل السيد والعبد تمامًا عند المزامنة.

بالنسبة للفرق التي تعتمد على Google Cloud Cloud SQL (سواء كان MySQL أو PostgreSQL) لبناء بنية فصل القراءة والكتابة ، فإن تأخير Read Replica أو انقطاع التزامن هو بالتأكيد أحد أكثر المشاكل إزعاجًا.

بصفتي SRE الذي داس على الحفرة على GCP لسنوات عديدة ، سأعيد المشهد من خلال هذا المقال وأفرز مجموعة

عملية كاملة للتحقيق في تأخير النسخ المتماثل لـ Cloud SQL الحقيقي والقابل للهبوط وتحسينها

.

1. إعادة النظر في الظاهرة: كيف حدث الفشل ؟

بشكل عام ، هناك نوعان من المظاهر النموذجية للزيادة في تأخير النسخ:

نوع الضفدع المغلي في الماء الدافئ: على لوحة مراقبة Cloud SQL من Google Cloud Console ، يستمر مؤشر replica_lag في الارتفاع بزاوية 45 درجة.

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

لاستكشاف هذه المشكلة ، نحتاج أولاً إلى معرفة منطق النسخ المتماثل الأساسي لـ GCP.

2. تحليل موجز للمبادئ الأساسية: آلية مزامنة Cloud SQL

Cloud SQL لـ MySQL: نسخة قائمة على GTID. تسجل المكتبة الرئيسية الكتابة إلى Binlog ، و IO Thread من المكتبة مسؤول عن سحب Binlog ، و SQL Thread (أو عمال Parallel) مسؤول عن إعادة التشغيل محليًا.

Cloud SQL for PostgreSQL: استنادًا إلى Streaming Replication. تتم كتابة المكتبة الرئيسية بواسطة WAL ، والتي يتم تلقيها من WAL Receiver في المكتبة ويتم تقديمها بواسطة عملية WAL Startup/Replay.

يحدث التأخير عندما يكون التزامن في المكتبة الرئيسية مرتفعًا للغاية ، أو عندما يتعذر تطبيق هذه التغييرات في الوقت المناسب من المكتبة.

ثلاث أو أربع خطوات للتحقيق: ابحث عن الجاني الذي تسبب في تأخير المزامنة

في مواجهة بضعة آلاف من الثواني من التأخير ، لا إعادة التشغيل الأعمى من المكتبة. سيؤدي إعادة تشغيل عقدة القراءة فقط إلى فقدان Buffer المحلي ، وقد تؤدي إعادة Replay إلى تفاقم التأخير. اتبع الخطوات التالية للتحقيق التدريجي:

1. تحقق من اختناقات الموارد: هل مواصفات السيد والعقد متساوية ؟

هذه هي الحفرة الأكثر سهولة بالنسبة لـ 80 ٪ من المبتدئين. من أجل توفير المال ، يحب الكثير من الناس مطابقة المكتبة الرئيسية

16vCPU / 64G ، من المكتبة يعطي فقط 2vCPU/8G.

نقطة المشكلة: يمكن للمكتبة الرئيسية معالجة الكتابة الضخمة بسهولة من خلال وحدة المعالجة المركزية عالية التزامن ، ولكن من المكتبة ، عندما تكون الموارد محدودة ، فإن إعادة تشغيل Binlog/WAL من مؤشر ترابط واحد (أو خيوط متعددة محدودة) أمر لا يمكن تحمله على الإطلاق ، وغالبًا ما تصل وحدة المعالجة المركزية مباشرة إلى 100 ٪.

طريقة حل المشكلات: عرض استخدام وحدة المعالجة المركزية من المكتبة و Disk I/O Utilization في Cloud Monitoring.

2. ابحث عن الشؤون الكبيرة و "جدول بدون مفتاح أساسي" في المكتبة الرئيسية

المعاملات الكبيرة: قام شخص ما بتشغيل DELETE FROM في المكتبة الرئيسية WHERE status = 0 وحذف 5 ملايين بيانات. في MySQL ، سيتم إرسال هذه المعاملة إلى المكتبة بعد إرسال المكتبة الرئيسية. أثناء إعادة تشغيل المعاملة الكبيرة من المكتبة ، سيتم حظر جميع المزامنة اللاحقة.

جدول بدون مفتاح أساسي: في وضع النسخ Row-Based ، إذا لم يكن هناك مفتاح أساسي لطاولة كبيرة ، فإن تحديث سجل واحد للمكتبة الرئيسية يحتاج فقط إلى مسح الجدول بالكامل مرة واحدة ، ولكن كل سطر يتغير عند إعادة وضعه من المكتبة. قم بإجراء مسح كامل للجدول مرة واحدة! عندما يكون هناك 10000 سطر من التحديثات ، يجب إجراء 10000 مسح كامل من المكتبة ، ويذهب التأخير مباشرة إلى السماء.

3. هل هناك تضارب في قفل الاستعلام الطويل من المكتبة ؟

لا تقوم عقدة القراءة فقط بمزامنة البيانات فحسب ، بل إنها تستجيب أيضًا لطلبات Read للأعمال.

في PostgreSQL ، إذا كان تحليل SQL يستغرق 10 دقائق يتم تشغيله من المكتبة ، ويحدث WAL من المكتبة الرئيسية تعديل الجدول الذي يقرأه SQL ، فسيحدث تعارض. وفقًا لتكوين المعلمة في PostgreSQL ، ستنتظر المكتبة إكمال الاستعلام ، وبالتالي تعليق تطبيق WAL.

في MySQL ، قد يحتفظ الاستعلام الكبير من المكتبة بقفل الجدول أو القفل الضمني ، مما يمنع كتابة SQL Thread.

4. التحقق من الشبكة والتأخير عبر المناطق (منطقة كروس)

إذا تم نشر Read Replica في مكان آخر (مثل المكتبة الرئيسية في طوكيو

Asia-northeast1

، من المكتبة في سنغافورة

Asia-southeast1

) ، سوف تطول الشبكة عبر المناطق والتأخير المادي مباشرة

Network_lag

.

رابعًا ، خطة الإيقاف السريع والعلاج الجذري

بالنسبة للأسباب الجذرية الموجودة في الترتيب أعلاه ، يمكننا التعامل معها بسرعة بالوسائل التالية:

1. الإرقاء الطارئ: الترقية الديناميكية وعملية القتل الاستعلام

نقرة واحدة للترقية المؤقتة للمكتبة: لا حاجة لتعديل المكتبة الرئيسية ، مباشرة في GCP Console vCPU/Read Replica

يتم تحسين الذاكرة لتتوافق مع المكتبة الرئيسية (حتى أعلى قليلاً من المكتبة الرئيسية) ، مما يوفر لها ما يكفي من موارد وحدة المعالجة المركزية و I/O لمواكبة التقدم.

استعلام Kill البطيء من المكتبة: إذا وجدت تحليلًا معقدًا لـ SQL يستهلك الموارد من المكتبة ، فسيتم استخدامها بشكل حاسم.

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

2. MySQL تحسين خاص: تشغيل النسخ المتماثل المتوازي

قد لا يؤدي Cloud SQL MySQL إلى أقصى حد من أداء إعادة التشغيل المتوازي افتراضيًا. يمكنك تمكين النسخ المتوازي عن طريق تعديل Flag:

اضبط replica_parallel_workers (أو slave_parallel_workers) على القيم التي تتوافق مع عدد وحدات vCPU من المكتبة.

مع إعداد replica_parallel_type = LOGICAL_CLOCK ، يتم تحسين كفاءة تطبيق Binlog من المكتبة بشكل كبير.

3. PostgreSQL تحسين خاص: وزن الاستعلام والمزامنة

إذا كان تأخير PG Read Replica مرتفعًا للغاية بسبب تضارب الاستعلام ، يمكنك محاولة ضبط المعلمات التالية في قاعدة البيانات الخاصة بك من المكتبة:

قم بتصغير max_standby_streaming_delay (إذا تم ضبطه على 30s) ، مما يعني أنه عند حدوث تعارضات متزامنة ، سيعطي النظام الأولوية لإلغاء استعلام القراءة فقط (الإبلاغ عن استعلام القراءة فقط) لضمان التزامن في الوقت الحقيقي.

4-التغييرات في مستوى الأعمال: تجنب المعاملات الأحادية الكبيرة

قم بتقسيم عمليات UPDATE أو DELETE الكبيرة إلى دفعات صغيرة وتقديمها على دفعات.

تنظيم صارم لمواصفات جدول قاعدة البيانات: يجب أن تحتوي جميع الجداول على مفاتيح رئيسية.

خامساً-الملخص

حل تأخير Read Replica لـ GCP Cloud SQL هو في الأساس

الموارد والتزامن والقفل

اللعبة. عند مواجهة الإنذار المتأخر ، اتبع"

تحقق من المواصفات-> تأكيد المعاملات الكبيرة/المفاتيح الرئيسية-> استبعاد التعارض من قفل المكتبة-> ضبط قاعدة البيانات Flag/الترقية المؤقتة

"يمكن حل معظم مشاكل المزامنة في هذه المجموعة من اللكمات.

حامل

إن الطبيعة العلمية للهيكل ، وموارد التشغيل والصيانة الوفيرة ، ومعايير قاعدة البيانات الصارمة هي الطريقة الوحيدة لجعل الأعمال مستلقية دون قلق.