وكيل سحابة أمازون: AWS RDS النسخ الاحتياطي التلقائي لتقلبات أداء قاعدة البيانات أثناء النافذة التشخيص والتحقيق الفعلي

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

بالنظر إلى لوحة مراقبة RDS الخاصة بـ AWS Console ، فإن الفترة الزمنية التي وجدت فيها المشكلة تتزامن تمامًا مع نافذة النسخ الاحتياطي التلقائي لـ RDS.

كان النسخ الاحتياطي التلقائي في الأصل وظيفة "إنقاذ الحياة" لضمان أمان البيانات وتحقيق الاستعادة حسب الوقت (PITR). لماذا أصبحت "قاتل الأداء" لنظام الأعمال أثناء التشغيل ؟ ستأخذك هذه المقالة إلى فهم هذه المشكلة وحلها تمامًا من أربعة أبعاد: الآلية المادية الأساسية لـ AWS RDS ، واختناقات هندسة التخزين ، ومسار التشخيص والتحقيق ، وخطة الحوكمة المعمارية.

1. تتبع المصدر: في نافذة النسخ الاحتياطي ، ماذا حدث للطبقة السفلية ؟

لتشخيص هذه المشكلة بدقة ، تحتاج أولاً إلى فهم كيفية عمل النسخ الاحتياطي التلقائي لـ AWS RDS. النسخ الاحتياطي لقطة RDS ليست قاعدة بيانات بسيطة

Mysqldump

أو تصدير منطقي ، ولكن على أساس الطبقة السفلية

لقطة على مستوى الكتلة (Snapshot) من حجم Amazon EBS (متجر Elastic Block)

.

عند بدء تشغيل نافذة النسخ الاحتياطي التلقائي ، تقوم AWS بتفعيل آلية اللقطة. الأسباب الأساسية لهذه العملية للتأثير على أداء قاعدة البيانات هي كما يلي:

1. تأخر الإدخال/الإخراج الناجم عن النسخ عند الكتابة (Copy-on-Write ، COW)

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

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

2. الاختلافات الآلية بين Single-AZ (منطقة واحدة قابلة للاستخدام) و Multi-AZ (منطقة متعددة قابلة للاستخدام)

بنية واحدة-AZ: يحتوي مثيل RDS على عقدة رئيسية واحدة فقط ، ويجب تنفيذ اللقطة مباشرة على وحدة تخزين EBS للعقدة الرئيسية. في المرحلة الأولى من إنشاء اللقطة ، ستحدث لفة EBS تعليق I/O اللحظي (I/O Suspension) ، والذي يستغرق من بضع ثوانٍ إلى عشرات الثواني. بالنسبة لأعمال الكتابة المتزامنة للغاية ، فإن تعليق الإدخال/الإخراج في هذه الثواني يكفي لإحداث تراكم طلبات المنبع ومجمع الاتصال الكامل.

بنية Multi-AZ: ستقوم AWS بتفويض النسخ الاحتياطي التلقائي إلى عقدة بديلة (Standby Instance)

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

3. تخزين IOPS ونفاد نقاط الطوارئ (Burst Balance)

إذا كان RDS يستخدم الجيل الأكبر سنا

GP2 (SSD العام)

التخزين ، يعتمد أداء IOPS على "Burst Balance".

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

GP3

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

طريقة التشخيص المكونة من أربع خطوات: كيفية تحديد مصدر عنق الزجاجة بدقة ؟

عندما يتقلب أداء قاعدة البيانات بشكل كبير في نافذة النسخ الاحتياطي ، لا توسع السعة بشكل أعمى. يوصى بوضع السبب الحقيقي وفقًا لـ "طريقة التشخيص المكونة من أربع خطوات" التالية:

[الخطوة 1: محاذاة الجدول الزمني CloudWatch] ──> [الخطوة 2: Performance Insights تحقق من حدث الانتظار]

│

[الخطوة 4: التحقق من مهام توقيت الأعمال/الشؤون الكبيرة] <── [الخطوة 3: التحقق من نوع التخزين واختناقات IOPS]

الخطوة الأولى: محاذاة الخط الزمني (CloudWatch مراقبة التباين)

أدخل لوحة مراقبة CloudWatch ، وقياس النطاق الزمني إلى ساعتين قبل وبعد حدوث الشذوذ ، لاحظ المؤشرات الأساسية التالية:

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

ReadIOPS / WriteIOPS و DiskQueueDepth: تحقق مما إذا كانت IOPS قد وصلت إلى الحد الأعلى لحجم التخزين الحالي ، وفي نفس الوقت لاحظ ما إذا كان عمق قائمة انتظار القرص يتجاوز بكثير القيمة العادية (يوصى عادةً بالحفاظ على عمق قائمة الانتظار عند حوالي IOPS / 500 ، مما يشير إلى تراكم I/O الخطير).

EBSSurplusBalance / BurstBalance: إذا كنت تستخدم وحدة تخزين GP2 ، تحقق مما إذا كان مؤشر Burst Balance ينخفض إلى 0 ٪.

الخطوة الثانية: مع Perfo

Rmance Insights (تحليل الأداء المتعمق)

يمكن أن يساعدنا فتح RDS Performance Insights في معرفة ما هو SQL الذي يبطئ قاعدة البيانات. التركيز

AAS(Average Active Sessions ، متوسط عدد الجلسات النشطة)

وأحداث الانتظار (Wait Events):

إذا كان هناك عدد كبير من io/file/innodb/innodb_data_file أو IO:DataFileRead / IO:DataFileWrite الانتظار ، فهذا يعني أن عنق الزجاجة الرئيسي يتركز على I/O لفيزياء القرص.

إذا كان هناك عدد كبير من القفل/synch/sxlock/innodb/btr_arch_latch أو قفل الذاكرة ينتظر ، فهذا يعني أن صفحة البيانات لا يمكن تمريرها في الوقت المناسب بسبب انسداد الإدخال/الإخراج ، مما يؤدي إلى منافسة القفل داخل قاعدة البيانات.

الخطوة الثالثة: التحقق من بنية المثيل ونوع التخزين

تأكيد تكوين خصائص مثيلات RDS الحالية:

هل هو Single-AZ أم Multi-AZ ؟

هل نوع التخزين GP2 أو GP3 أو IOPS Provisioned (io1/io2) ؟

هل يقوم محرك قاعدة البيانات بتشغيل تنظيف Undo Log الكبير أو صفحات Dirty (الصفحات القذرة) على قرص فرشاة عالي الحجم ؟

الخطوة 4: التحقيق في تعارضات مهام التوقيت بين جانب التطبيق والخلفية

اعتاد العديد من الفرق على تشغيل المهام المنتظمة مثل الشؤون الطويلة ، وأرشفة البيانات ، وإنشاء تقارير ETL في الليل. إذا تزامنت مهام توقيت الأعمال هذه مع نافذة النسخ الاحتياطي التلقائي لـ AWS RDS ، فإنها ستشكل تأثيرًا متراكبًا لـ "قراءة لقطة مكبرة للكتابة" ، مما يؤدي مباشرة إلى تفجير القرص I/O.

3. خطة الحوكمة الشاملة وتحسين الهيكل

بعد تحديد موقع مصدر المشكلة ، يمكننا تنفيذ حوكمة مستهدفة من أربعة جوانب: "فصل الهندسة المعمارية" ، و "ترقية التخزين" ، و "تعديل التكوين" و "ضمان التشغيل والصيانة".

1. ترقية الهيكل: منطقة واحدة إلى منطقة متعددة (ترقية واحدة-AZ إلى Multi-AZ)

إذا كان RDS في بيئة الإنتاج لا يزال يستخدم Single-AZ ، فمن المستحسن بشدة ترقيته إلى نشر Multi-AZ.

التأثير: بعد الترقية ، ستقوم AWS تلقائيًا بنقل مهام النسخ الاحتياطي التلقائي اليومية إلى العقدة الاحتياطية لـ Standby للتنفيذ ، مما يؤدي تمامًا إلى قطع التأثير المباشر لتعليق لقطة الإدخال/الإخراج على أعمال إنتاج العقدة الرئيسية.

2. إعادة تشكيل التخزين: الانتقال السلس من GP2 إلى GP3 ، أو IOPS المُحددة مسبقًا

وداع GP2: يعتمد GP2 على Burst Balance ، والأداء غير مستقر للغاية. يوفر GP3 IOPS مستقل وقدرة مسبقة للإنتاجية ، ويوفر التكوين الأساسي 3000 IOPS و 125 ميجابايت/ثانية

الإنتاجية.

يستخدم المشهد عالي التحميل io1/io2: بالنسبة لقاعدة البيانات الأساسية ذات التزامن العالي للغاية ومتطلبات الكمون المنخفضة ، يوصى باستخدام IOPS Provisioned (io1/io2) للتخزين مباشرة ، وتعيين قيم IOPS مسبقة كافية وفقًا لاحتياجات القوة الحسابية للأعمال.

3. إعادة ترتيب نافذة النسخ الاحتياطي ومهمة التوقيت

إعادة تعيين نافذة Backup: في إعدادات RDS ، اضبط نافذة النسخ الاحتياطي التلقائي إلى أدنى فترة زمنية لحركة المرور على مدار اليوم (مثل 03:00 - 04:00 صباحًا).

ذروة تحويل مهمة التوقيت: قم بفك ارتباط مهام التوقيت مثل معالجة الدُفعات ، وأرشفة البيانات ، وإعادة بناء الفهرس في النظام مع نافذة النسخ الاحتياطي التلقائي لمدة 1-2 ساعات على الأقل لتجنب تراكب حركة المرور.

4. ضمان التشغيل والصيانة: توسيع الموارد السحابية وإدارة الميزانية

سواء كان الأمر يتعلق بترقية Single-AZ إلى Multi-AZ ، أو ترقية GP2 إلى GP3/io2 ، أو تحسين مواصفات المثيل والتركيب المسبق لـ IOPS ، فسيحدث بعض التغييرات في تكلفة البنية التحتية السحابية.

عند إجراء هذه التعديلات الهيكلية وتغييرات الموارد ، من الضروري التأكد من أن حسابات AWS في حالة صحية وحصص كافية. بالنسبة لمستخدمي الأعمال ، تحقق بانتظام من تمويل الحساب وإكماله في الوقت المناسب

شحن حساب AWS

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

رابعاً-الملخص وأفضل الممارسات Checklist

تقلبات الأداء الناجمة عن النسخ الاحتياطي التلقائي AWS RDS ، في الأساس

التخزين المادي لموارد الإدخال/الإخراج تصل إلى عنق الزجاجة تحت ضغط اللقطة

تجسيد. من خلال التصميم المعماري المعقول وضبط المعلمات ، يمكن تحقيق "النسخ الاحتياطي غير المحسوب" تمامًا.

في عمليات الصيانة اليومية ، يوصى بالرجوع إلى قائمة التحقق من أفضل الممارسات التالية (Checklist):

التحقق من الأبعاد

متطلبات أفضل الممارسات

الشرح

هيكل النشر

يجب فتح قاعدة بيانات الإنتاج Multi-AZ

تطبيق ضغط I/O للنسخ الاحتياطي على عقدة Standby البديلة

نوع التخزين

التخلي عن GP2 ، ترقية كاملة إلى GP3 أو io1/io2

توفير IOPS والإنتاجية التي يمكن التنبؤ بها ، وتجنب نقاط الطوارئ من السقوط إلى الصفر

إدارة النوافذ

نافذة النسخ الاحتياطي (نافذة النسخ الاحتياطي) تجنب ذروة الأعمال

تأكد من عدم وجود مهام ETL أو Delete/Update الثقيلة خلال فترة النسخ الاحتياطي

مراقبة الإنذار

تكوين CloudWatch WriteLatency و DiskQueueDepth

العثور على علامات تدهور أداء التخزين مقدما

العمليات المالية والصيانة

الحفاظ على

إعادة شحن حساب AWS والتمويل الكافي

ضمان التنفيذ السلس للتوسع المرن وتغييرات التخزين وترقيات Multi-AZ

طالما أنك تفهم آلية تشغيل EBS Snapshot الأساسية ، جنبًا إلى جنب مع خطوات التشخيص والتحقق الواضحة والتحول الهيكلي المعقول ، يمكنك بسهولة التغلب على مشكلة التقلبات العنيفة في الأداء أثناء النسخ الاحتياطي التلقائي لـ RDS ومرافقة التشغيل السلس للأعمال عبر الإنترنت.