التصحيح واستكشاف الأخطاء وإصلاحها في النسخ المتماثل دفق PostgreSQL

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

أخبر Alexey Lesovsky ( lesovsky ) في Highload ++ 2017 كيفية تشخيص أنواع مختلفة من المشاكل باستخدام أدوات مدمجة وأدوات خارجية وكيفية إصلاحها . تحت التخفيضات ، فإن فك شفرة هذا التقرير ، مبني على مبدأ حلزوني: أولاً ، نقوم بإدراج جميع أدوات التشخيص الممكنة ، ثم ننتقل إلى قائمة المشاكل الشائعة وتشخيصها ، ثم نرى ما هي تدابير الطوارئ التي يمكن اتخاذها ، وأخيرًا كيفية التعامل مع المشكلة بشكل جذري.


حول المتحدث : أليكسي ليسوفسكي ، مدير قاعدة البيانات في Data Egret. أحد المواضيع المفضلة لدى أليكسي في PostgreSQL هو بث النسخ المتماثل والعمل مع الإحصائيات ، لذلك تم تخصيص التقرير في Highload ++ 2017 لكيفية العثور على المشاكل باستخدام الإحصائيات وما هي الطرق التي يجب استخدامها لحلها.

الخطة

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

لماذا كل هذا؟ ستساعدك هذه المقالة على فهم النسخ المتماثل للبث بشكل أفضل ، وتعلم كيفية العثور على المشكلات وإصلاحها بسرعة لتقليل وقت رد الفعل للحوادث غير السارة.

جزء من النظرية

يحتوي PostgreSQL على كيان مثل كتابة سجل للأمام (XLOG) ، سجل المعاملات. يتم تسجيل جميع التغييرات التي تحدث تقريبًا مع البيانات والبيانات الوصفية داخل قاعدة البيانات في هذا السجل. في حالة حدوث أي حادث فجأة ، يبدأ PostgreSQL ، ويقرأ سجل المعاملات ويستعيد التغييرات المسجلة على البيانات. وهذا يضمن الموثوقية - أحد أهم خصائص أي نظام DBMS و PostgreSQL أيضًا.

يمكن ملء سجل المعاملات بطريقتين:

1. افتراضيًا ، عندما تُجري الخلفية بعض التغييرات في قاعدة البيانات (INSERT ، UPDATE ، DELETE ، إلخ.) ، يتم تسجيل جميع التغييرات في سجل المعاملات بشكل متزامن :
   
   • أرسل العميل أمر COMMIT لتأكيد البيانات.
     
   • يتم تسجيل البيانات في سجل المعاملات.
     
   • بمجرد حدوث التثبيت ، يتم منح التحكم للواجهة الخلفية ، ويمكنه الاستمرار في تلقي الأوامر من العميل.
     
2. الخيار الثاني هو الكتابة غير المتزامنة في سجل المعاملات ، عندما تكتب عملية كاتب WAL مخصصة منفصلة التغييرات في سجل المعاملات مع فترة زمنية معينة. ونتيجة لذلك ، يتم تحقيق زيادة في أداء الواجهة الخلفية ، حيث لا توجد حاجة للانتظار حتى يكتمل الأمر COMMIT.
   

الأهم من ذلك ، يستند دفق النسخ المتماثل إلى سجل المعاملات هذا. لدينا العديد من أعضاء النسخ المتماثل الدفق:

• إتقان حيث تتم جميع التغييرات ؛
  
• العديد من النسخ المتماثلة التي تقبل سجل المعاملات من الرئيسي وتعيد إنتاج كل هذه التغييرات على بياناتهم المحلية. هذا هو دفق النسخ المتماثل.
  

من الجدير بالذكر أن جميع سجلات المعاملات هذه مخزنة في دليل pg_xlog في $ DATADIR - الدليل الذي يحتوي على ملفات بيانات DBMS الرئيسية. في الإصدار العاشر من PostgreSQL ، تمت إعادة تسمية هذا الدليل ليصبح pg_wal / ، لأنه ليس من غير المألوف أن تشغل pg_xlog / مساحة كبيرة ، ويقوم المطورون أو المسؤولون الذين يخلطون بينه دون علم بالسجلات ، ويحذفونه بلا مبالاة ويصبح كل شيء سيئًا.

يحتوي PostgreSQL على العديد من خدمات الخلفية التي تشارك في دفق النسخ المتماثل. دعونا نلقي نظرة عليها من وجهة نظر نظام التشغيل.

• من جانب السيد - عملية المرسل WAL. هذه عملية ترسل سجلات المعاملات إلى النسخ المتماثلة ، وسيكون لكل نسخة متماثلة WAL Sender الخاص بها.
  
• تقوم النسخة المتماثلة بدورها بتشغيل عملية استقبال WAL ، والتي تتلقى سجلات المعاملات عبر اتصال الشبكة من مرسل WAL وتمريرها إلى عملية بدء التشغيل.
  
• تقوم عملية بدء التشغيل بقراءة السجلات وإعادة إنتاج كافة التغييرات التي تم تسجيلها في سجل المعاملات في دليل البيانات.
  

من الناحية التخطيطية ، يبدو الأمر مثل هذا:

• تتم كتابة التغييرات على مخازن WAL ، والتي سيتم كتابتها بعد ذلك في سجل المعاملات ؛
  
• السجلات في التخزين في الدليل pg_wal / ؛
  
• يقرأ WAL Sender سجل المعاملات من المستودع وينقله عبر الشبكة ؛
  
• يستقبل WAL Receiver ويخزن في مخزنه - في pg_wal / المحلية.
  
• تقرأ عملية بدء التشغيل كل ما يتم قبوله وإعادة إنتاجه.
  

المخطط بسيط. يعمل نسخ الدفق بشكل موثوق به تمامًا وقد تم استغلاله بشكل ممتاز لسنوات عديدة.

أدوات استكشاف الأخطاء وإصلاحها

دعونا نرى ما هي الأدوات والمرافق التي يقدمها المجتمع و PostgreSQL من أجل التحقيق في المشاكل التي تواجهها في النسخ المتماثل للدفق.

أدوات الطرف الثالث

لنبدأ بأدوات الطرف الثالث. هذه المرافق من خطة عالمية نوعًا ما ؛ يمكن استخدامها ليس فقط للتحقيق في الحوادث المتعلقة بتكرار الدفق. هذه أدوات مساعدة بشكل عام لأي مسؤول نظام .

• أعلى من حزمة procps. كبديل للأعلى ، يمكنك استخدام أي أدوات مساعدة مثل atop و htop وما شابه. أنها توفر وظائف مماثلة.

بمساعدة من الأعلى ، ننظر إلى: استخدام المعالجات (CPU) ومتوسط ​​الحمل (متوسط ​​التحميل) واستخدام الذاكرة ومساحة التبديل.

• iostat من sysstat و iotop. تظهر هذه الأدوات المساعدة استخدام أجهزة القرص وما يتم إنشاؤه من قبل العمليات في نظام التشغيل I / O.

بمساعدة iostat ، ننظر إلى: استخدام التخزين ، وعدد iops في الوقت الحالي ، وما الإنتاجية في الأجهزة ، وما التأخيرات عند معالجة طلبات I / O (الكمون). يتم أخذ هذه المعلومات المفصلة إلى حد ما من نظام الملفات procfs ويتم توفيرها للمستخدم في شكل مرئي.

• nicstat هو نظير iostat ، فقط لواجهات الشبكة. في هذه الأداة يمكنك مشاهدة استخدام الواجهات.

باستخدام nicstat ، ننظر: بالمثل ، استخدام الواجهة ، بعض الأخطاء التي تحدث على الواجهات ، الإنتاجية هي أيضًا أداة مفيدة جدًا.

• pgCenter هي أداة للعمل فقط مع PostgreSQL. يعرض إحصاءات PostgreSQL في واجهة تشبه إلى حد كبير ، ويمكنك أيضًا مشاهدة الإحصاءات المتعلقة بتدفق النسخ المتماثل فيها.

بمساعدة pgCenter ننظر: إحصاءات النسخ المتماثل. يمكنك مشاهدة تأخر النسخ المتماثل وتقييمه بطريقة ما والتنبؤ بالعمل المستقبلي.

• perf أداة مفيدة لإجراء تحقيق أعمق في أسباب "الطرق تحت الأرض" ، عندما تكون هناك مشكلات غريبة على مستوى رمز PostgreSQL.

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

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

أدوات مضمنة

ماذا تقدم PostgreSQL نفسها؟

طرق عرض النظام

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

هناك عدد غير قليل من طرق عرض النظام. من أجل التعامل مع النسخ المتماثل للدفق والتحقيق في المشكلات ، نحتاج فقط إلى: pg_stat_replication و pg_stat_wal_receiver و pg_stat_database و pg_stat_databases_conflicts و auxiliary pg_stat_activity و pg_stat_archiver.

هناك القليل منها ، لكن هذه المجموعة كافية للتحقق مما إذا كانت هناك أي مشاكل.

وظائف المساعد

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

• pg_current_wal_lsn () (النظير القديم لـ pg_current_xlog_location ()) هي الوظيفة الأكثر أهمية التي تسمح لك برؤية الموضع الحالي في سجل المعاملات. سجل المعاملات هو تسلسل مستمر للبيانات. باستخدام هذه الوظيفة ، يمكنك رؤية النقطة الأخيرة ، الحصول على الموضع الذي توقف سجل المعاملات الآن.
  
• pg_last_wal_receive_lsn () ، pg_last_xlog_receive_location () هي دالة مماثلة لما سبق ، فقط للنسخ المتماثلة. تتلقى النسخة المتماثلة سجل المعاملات ، ويمكنك رؤية آخر موضع سجل معاملة تم تلقيه ؛
  
• pg_wal_lsn_diff () ، pg_xlog_location_diff () هي وظيفة أخرى مفيدة. نعطيها موقعين من سجل المعاملات ، وتظهر اختلافًا - المسافة بين هاتين النقطتين بالبايت. هذه الوظيفة مفيدة دائمًا في تحديد الفاصل بين الرئيسي والنسخ المتماثلة بالبايت.
  

يمكن الحصول على قائمة كاملة بالوظائف باستخدام الأمر psql meta-command: \ df * (wal | xlog | lsn | location) *.

يمكنك كتابته في psql ورؤية جميع الوظائف التي يحتوي عليها wal ، xlog ، Isn ، location. سيكون هناك حوالي 20-30 مثل هذه الوظائف ، كما أنها توفر معلومات مختلفة في سجل المعاملات. أوصي بأن تتعرف على نفسك.

Pg_waldump فائدة

قبل الإصدار 10.0 ، كان يطلق عليه اسم pg_xlogdump. هناك حاجة إلى الأداة المساعدة pg_waldump عندما نريد النظر في مقاطع سجل المعاملات ، ومعرفة سجلات الموارد التي حصلت عليها ، وما كتب PostgreSQL هناك ، أي لإجراء دراسة أكثر تفصيلاً.

في الإصدار 10.0 ، تمت إعادة تسمية جميع طرق عرض النظام والوظائف والأدوات المساعدة التي تضمنت كلمة xlog. تم استبدال كل تكرارات الكلمات xlog والموقع بالكلمتين wal و lsn ، على التوالي. تم عمل نفس الشيء مع دليل pg_xlog الذي أصبح دليل pg_wal.

تقوم الأداة المساعدة pg_waldump ببساطة بفك تشفير محتويات مقاطع XLOG إلى تنسيق يمكن قراءته بواسطة الإنسان. يمكنك أن ترى ما يسمى سجلات الموارد التي تندرج في سجلات المقطع أثناء عمل PostgreSQL ، والتي تم تغيير الفهارس وملفات كومة الذاكرة المؤقتة ، وما هي المعلومات المخصصة للاستخدام الاحتياطي. وبالتالي ، يمكن عرض الكثير من المعلومات باستخدام pg_waldump.

ولكن هناك إخلاء مسؤولية مكتوب في الوثائق الرسمية : قد تظهر pg_waldump بيانات غير صحيحة قليلاً عند تشغيل PostgreSQL (يمكن أن تعطي نتائج خاطئة عند تشغيل الخادم - مهما كان ذلك)

يمكنك استخدام الأمر:

pg_waldump -f - /wal_10 \ $(psql -qAtX - "select pg_walfile_name(pg_current_wal_lsn())") 

هذا تناظري للأمر tail-f لسجلات المعاملات فقط. يعرض هذا الأمر ذيل سجل المعاملات الذي يحدث الآن. يمكنك تشغيل هذا الأمر ، وسوف يجد الجزء الأخير مع إدخال سجل المعاملات الأحدث ، والاتصال به وبدء عرض محتويات سجل المعاملات. فريق صعب بعض الشيء ، ولكنه مع ذلك يعمل. كثيرا ما تستخدمه.

تحرّي الخلل وإصلاحه

هنا نلقي نظرة على المشاكل الأكثر شيوعًا التي تنشأ في ممارسة الاستشاريين ، وما هي الأعراض وكيفية تشخيصها:

تأخر النسخ المتماثل هي المشكلة الأكثر شيوعًا . في الآونة الأخيرة ، كان لدينا مراسلات مع العميل:

- لقد كسرنا النسخ المتماثل للعبد الرئيسي بين الخادمين.

- تأخر اكتشافه ساعتين ، بدأ pg_dump.

- حسنا ، فهمت. ما هو تأخرنا المسموح به؟

- 16 ساعة في الحد الأقصى للتأخير.

- ماذا سيحدث عندما يتم تجاوز هذا التأخر؟ صفارات الإنذار؟

- لا ، سيتم ضرب المعاملات ، وسيتم استئناف لفة WAL.

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

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

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

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

تأخر النسخ المتماثل

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

كيف تبحث عن مثل هذه المشاكل؟

• توجد طريقة عرض أساسية حول المعالج والنسخ المتماثلة - pg_stat_replication . يعرض معلومات عن كل مرسل WAL ، أي عن العمليات التي ترسل سجلات المعاملات. سيكون لكل نسخة متماثلة سطر منفصل يعرض إحصائيات هذه النسخة المتماثلة بالتحديد.
  
• تسمح لك الوظيفة الإضافية pg_wal_lsn_diff () بمقارنة المواضع المختلفة في سجل المعاملات وحساب التأخير نفسه. بمساعدتها ، يمكننا الحصول على أرقام محددة وتحديد أين لدينا تأخرًا كبيرًا ، وأين يكون صغيرًا ونستجيب بالفعل للمشكلة بطريقة أو بأخرى.
  
• تعمل وظيفة pg_last_xact_replay_timestamp () فقط على النسخة المتماثلة وتسمح لك بمعرفة الوقت الذي تم فيه تنفيذ آخر معاملة مفقودة. توجد دالة معروفة الآن () تُظهر الوقت الحالي ، ونطرح الوقت الذي تُظهره لنا دالة pg_last_xact_replay_timestamp () من الدالة now () ونحصل على فارق الوقت.
  

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

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

الرأي على النحو التالي.



يحتوي على معلومات عن كل مرسل WAL والعديد من المجالات التي تهمنا. هذا في المقام الأول client_addr - عنوان الشبكة للنسخة المتماثلة المتصلة (عادة ما يكون عنوان IP) ومجموعة من حقول lsn (في الإصدارات القديمة تسمى الموقع) ، سأتحدث عنها قليلاً.

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

كقاعدة ، أستخدم هذا الطلب.



هذا ليس الاستعلام الأكثر تعقيدًا الذي تطبعه pg_stat_replication بتنسيق أكثر ملاءمة ومفهومة. هنا أستخدم الوظائف التالية:

• pg_wal_lsn_diff () لقراءة الفروق. ولكن بين ما أعتقد يختلف؟ لدينا العديد من المجالات - sent_lsn و write_lsn و flush_lsn و replay_lsn. من خلال حساب الفرق بين الحقل الحالي والحقل السابق ، يمكننا أن نفهم بدقة أين تأخرنا ، وأين يحدث التأخر بالضبط.
  
• pg_current_wal_lsn () ، الذي يوضح الموضع الحالي لسجل المعاملات. هنا ننظر إلى المسافة بين الموضع الحالي في السجل والمرسل - عدد سجلات المعاملات التي تم إنشاؤها ولكن لم يتم إرسالها.
  
• sent_lsn ، write_lsn - هذا هو مقدار ما يتم إرساله إلى النسخة المتماثلة ، ولكن لم يتم تسجيله. أي أنه موجود الآن في مكان ما على الشبكة ، أو تم استلامه عن طريق نسخة متماثلة ، ولكن لم تتم كتابته بعد من المخازن المؤقتة للشبكة إلى تخزين القرص.
  
• write_lsn ، flush_lsn - هذا مكتوب ، ولكن لم يتم إصداره بواسطة الأمر fsync - كما لو كان مكتوبًا ، ولكن يمكن وضعه في مكان ما في ذاكرة الوصول العشوائي ، في ذاكرة التخزين المؤقت للصفحة لنظام التشغيل. بمجرد إجراء fsync ، تتم مزامنة البيانات مع القرص ، ويتم الوصول إلى التخزين المستمر ويبدو أن كل شيء يمكن الاعتماد عليه.
  
• replay_lsn ، flush_lsn - تم تفريغ البيانات ، تنفيذ fsync ، ولكن لم يتم نسخها.
  
• current_wal_lsn و replay_lsn هو نوع من التأخير الكلي الذي يشمل جميع المواقف السابقة.
  

بعض الأمثلة

تم تمييز النسخة المتماثلة 10.6.6.8 أعلاه. لديها تأخر معلق ، ولدت بعض سجلات المعاملات ، لكنها لا تزال غير مرسلة وتكمن على سيد. على الأرجح ، هناك نوع من المشاكل مع أداء الشبكة. سوف نتحقق من ذلك باستخدام الأداة المساعدة nicstat.

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



تأخر الكتابة تم وضع علامة عليه أعلاه. في الواقع ، هذا التأخر نادر جدًا ، لا أرى تقريبًا أنه كبير. قد تكون المشكلة في الأقراص ، ونحن نستخدم أداة iostat أو iotop - فنحن ننظر إلى استخدام مخازن القرص ، التي يتم إنشاؤها بواسطة العمليات / الإدخال ، ثم نكتشف السبب.



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

أيضًا مع أدوات iostat و iotop ، نلقي نظرة على ما يحدث مع استخدام القرص ولماذا الفرامل.

وأخيرًا total_lag هو مقياس مفيد لأنظمة المراقبة. إذا تم تجاوز الحد الإجمالي المسموح به لدينا ، فسيتم رفع مربع اختيار في المراقبة ، وسنبدأ في التحقيق في ما يحدث هناك.

اختبار الفرضيات

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

الآن يوفر جميع المضيفين تقريبًا 1 جيجابت / ثانية أو حتى 10 جيجابت / ثانية ، لذا فإن النطاق الترددي المسدود هو السيناريو الأكثر ترجيحًا . كقاعدة ، تحتاج إلى إلقاء نظرة على الأخطاء. يحتوي nicstat على معلومات حول الأخطاء في الواجهات ، يمكنك معرفة أن هناك مشاكل مع برامج التشغيل ، إما مع بطاقة الشبكة نفسها أو مع الكابلات.

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

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

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

وبالطبع pg_wal_lsn_diff () لتحديد التأخر وتحديد مكان التأخر على وجه التحديد - على الشبكة أو على الأقراص أو على المعالجات.

خيارات الحل

مشاكل الشبكة / التخزين

كل شيء بسيط للغاية هنا ، ولكن من وجهة نظر التكوين ، لا يتم حل هذا عادةً. يمكنك تشديد بعض المكسرات ، ولكن بشكل عام هناك خياران:

• تحقق من عبء العمل

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

• ترقية الأجهزة
  

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

تأخيرات الاسترداد

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

إذا كانت الاستعلامات الطويلة متعلقة بعدم المثالية لاستعلام SQL نفسه (نجد ذلك باستخدام EXPLAIN ANALYZE) ، ما عليك سوى التعامل مع هذا الاستعلام بشكل مختلف وإعادة كتابته. أو هناك خيار لتكوين نسخة متماثلة منفصلة لاستعلامات التقارير . إذا قمنا بعمل أي تقارير تعمل لفترة طويلة ، فيجب إرسالها إلى نسخة متماثلة منفصلة.

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

WAL عالي الحجم

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

يتم ذلك عادة من خلال التكوين . الحل الجزئي في تعيين full_page_writes = إيقاف المعلمة. يقوم هذا الخيار بتشغيل / إيقاف تسجيل الصور الكاملة للصفحات المتغيرة في سجل المعاملات. هذا يعني أنه عندما كانت لدينا عملية الخدمة لكتابة نقطة تحقق (CHECKPOINT) ، في المرة التالية التي نغير فيها بعض كتلة البيانات في منطقة المخازن المؤقتة المشتركة ، ستذهب الصورة الكاملة لهذه الصفحة إلى سجل المعاملات ، وليس فقط التغيير نفسه. مع جميع التغييرات اللاحقة على نفس الصفحة ، سيتم تسجيل التغييرات فقط في سجل المعاملات. وهكذا إلى نقطة التفتيش التالية.

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

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

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

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

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

تورم pg_wal /

الآن ، لنتحدث عن كيف يمكنك العثور على أن الدليل pg_wal / متورم.

نظريًا ، يحتفظ PostgreSQL دائمًا في حالة مثلى لنفسه على مستوى ملفات تكوين معينة ، وكقاعدة عامة ، يجب ألا ينمو فوق حدود معينة.

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

بعد حساب مجموع max_wal_size و wal_keep_segments ، يمكننا تقدير المساحة التي سيشغلها الدليل pg_wal /. إذا كان ينمو بسرعة ويستهلك مساحة أكبر بكثير من القيمة المحسوبة ، فهذا يعني أن هناك بعض المشاكل ، وعليك أن تفعل شيئًا حيال ذلك.

كيف تكشف مثل هذه المشاكل؟

على نظام التشغيل Linux ، يوجد أمر du-csh . يمكننا ببساطة مراقبة القيمة ومراقبة عدد سجلات المعاملات الموجودة لدينا ؛ احتفظ بعلامة محسوبة ، ومديوني وكم يأخذ في الواقع ، والاستجابة بطريقة أو بأخرى للتغيرات في الأرقام.

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

وبالطبع ، هناك دائمًا أخطاء في سجلات PostgreSQL المرتبطة بأمر الأرشيف. للأسف ، لن تكون هناك أسباب أخرى تتعلق بـ pg_wal / overflow. يمكننا التقاط أخطاء الأرشيف فقط هناك.

خيارات المشاكل:

الثقيلة CRUD - عمليات تحديث البيانات الثقيلة - INSERT ، DELETE ، UPDATE ، المرتبطة بتغيير عدة ملايين من الصفوف. إذا كانت PostgreSQL بحاجة إلى القيام بهذه العملية ، فمن الواضح أنه سيتم إنشاء كمية كبيرة من سجل المعاملات. سيتم تخزينه في pg_wal / ، وسيؤدي ذلك إلى زيادة المساحة المشغولة. هذا ، مرة أخرى ، كما قلت سابقًا ، من الممارسات الجيدة تقسيمها ببساطة إلى حزم ، وليس تحديث الصفيف بأكمله ، ولكن 100 ، 200 ، 300 ألف لكل منهما.

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

يحفظ PostgreSQL لكل فتحة نسخ متماثل مقاطع من سجل المعاملات في حالة اتصال تطبيق أو نسخة متماثلة عن بعد بهذه الفتحة مرة أخرى ، ومن ثم يمكن للمعالج إرسال سجلات المعاملات هذه إليهم.

لكن الوقت يمر ، لا أحد يتصل بالفتحة ، ويتم تجميع سجلات المعاملات ، وفي وقت ما تشغل 90٪ من المساحة. نحن بحاجة لمعرفة ما هو ، ولماذا يتم أخذ مساحة كبيرة. كقاعدة ، تحتاج فقط إلى إزالة هذه الفتحة المنسية وغير المستخدمة ، وسيتم حل المشكلة. لكن المزيد عن ذلك لاحقًا.

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

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

إذا كان الأمر archive يعمل بمخرج ليس 0 ، فسيتم كتابة رسالة حول هذا في السجل ، وسيبقى المقطع في الدليل pg_wal /. حتى نجد أن فريق الأرشيف قد انكسر ، ستتراكم الأجزاء ، وينتهي المكان أيضًا في مرحلة ما.

مجموعة من تدابير الطوارئ (المساحة المستخدمة 100٪):

1. CRUD , — pg_terminate_backend().
- , , , .. , pg_wal/, .

2. root — reserved space ratio (ext filesystems).
ext ext 5%. , , 5% — . , , 1% , tune2fs -m 1. PostgreSQL , . 100% .

3. (LVM, ZFS,...).
LVM ZFS, LVM ZFS, , , . , .

4. — , , HE pg_wal/ .
, , , . ! PostgreSQL , . , , , .

, pg_xlog/ pg_wal/ — log , , , , - — !

, 100% CPU, .

workload . , ? , - , -. : , tablespace, tablespace.

. , , , , , , . — .

checkpoints_segments/max_wal_size, wal_keep_segments . , , — 10-20 wal_keep_segments, max_wal_size. , . PostgreSQL pg_wal/ .

pg_replication_slots — . , , — . , , . .

WAL, , pg_stat_archiver , . , , , , .

checkpoint . , , . , PostgreSQL . , checkpoint .

, , — . - , . , .

— PostgreSQL :

• User was holding shared bufer pin for too long.
  
• User query might have needed to see row versions that must be removed.
  
• User was holding a relation lock for too long.
  
• User was or might have been using table space that must be dropped.
  
• User transaction caused bufer deadlock with recovery.
  
• User was connected to a database that must be dropped.
  

2 — , , . : , , . ( 30 ), PostgreSQL — .

. , , . - , timeout . — ALTER, , .

. , tablespace , tablespace. , , - — .

?

pg_stat_databases, pg_stat_databases_conflicts . , . , .

, . , . , . , , , .

?

, — :

1. max_standby_streaming_delay ( ). , . .
   
2. hot_stadby_feedback ( /). , vacuum - , . bloat . , , , hot_stadby_feedback .
   
3. DBA — . , . , , , - , .
   
4. , , , , DBA — , , . max_standby_streaming_delay . , . , , , . — , .
   

Recovery process: 100% CPU usage

, , , 100% . , , 100%. , pg_stat_replication, , replay, , .

:

• top — — 100% CPU usage recovery process;
  
• pg_stat_replication — , , .
  

, . , :

• perf top/record/report ( debug—);
  
• GDB;
  
• pg_waldump.
  

, , . workload, . , , PostgreSQL shared buffers ( ). .

الحل

, . - workload, - , - : « , - ».

pgsql-hackers , pgsql-bugs , , . , .

— - , , .

الملخص

. , , , .

. , , , , , — .

, , — . , , , .

, , — , , .

روابط مفيدة

• PostgreSQL official documentation — The Statistics Collector
• PostgreSQL Mailing Lists ( general , performance , hackers )
• PostgreSQL-Consulting company blog

, Highload++ Siberia , 25 26 . , , .

• MySQL ClickHouse.
• , Oracle.
• , , — , .
• , VK ClickHouse, , .