قامت شركة Fujitsu بإجراء بعض التحسينات على اتصال النسخ المتماثل المنطقي في PostgreSQL 15. دعني أوضح لك بعض التفاصيل. في هذا المنشور ، سأشرح التحسينات التي تم إدخالها في PostgreSQL 15 لمعالجة المسألتين التاليتين في اتصال النسخ المتماثل المنطقي:
1. إذا لم يتم نشر جميع DMLs في المعاملة وفقًا لمرشح الاشتراك ، فسيقوم المرسل بإرسال معاملة فارغة ، مما سيؤدي إلى إهدار الموارد مثل وحدة المعالجة المركزية / الذاكرة / الشبكة.
2. عند معالجة معاملة كبيرة ، إذا كان الولسندر مشغولاً بمعالجة DML غير المنشور في المعاملة ، فقد لا يتمكن من التواصل مع متلقي الفالس لفترة طويلة. يمكن أن يؤدي هذا إلى أخطاء غير متوقعة في المهلة على الرغم من أن والسندر يعمل كما هو متوقع.
> الاتصال في النسخ المتماثل المنطقي
> أنواع معلومات الاتصال
> التصفية
> نظرة عامة
على التحسينات> تحسينات على المعاملات الفارغة>
خطأ مهلة ثابت غير متوقع
> تأثير الأداء
> الخطط المستقبلية
قبل أن أذهب إلى أبعد من ذلك ، أود أن أقدم بإيجاز مفهومين للاتصال في النسخ المنطقي: أنواع رسائل الاتصال وتصفيتها.
نوع رسالة الاتصال
في النسخ المنطقي ، هناك نوعان من الرسائل المرسلة من قبل والسندر إلى walreceiver:
تُستخدم هذه الرسالة لإخبار متلقي الفالسة أن الوالسندير يعمل كما هو متوقع.
يمكن للمستخدم ضبط مهلة walreceiver GUC باستخدام المعلمة wal_receiver_timeout (60 ثانية بشكل افتراضي). ضمن wal_receiver_timeout ، إذا لم يتلقى walreceiver أي نوع من الرسائل من walsender ، فسيخرج مع وجود خطأ في المهلة.
هناك أنواع عديدة من رسائل بروتوكول النسخ المنطقي (المرجع 1 في نهاية المقالة) ، في هذه المدونة سنركز على اثنين فقط منهم:
-
رسائل DML ، بما في ذلك INSERT و UPDATE و DELETE و TRUNCATE ؛
-
الرسائل التي تحدد بداية ونهاية المعاملة ، مثل رسائل BEGIN و COMMIT.
يمكن الاطلاع على قائمة كاملة ببروتوكولات النسخ المنطقي على موقع PostgreSQL.
قد لا تدرك ذلك ، ولكن لا يتم إرسال كل DML في المعاملة إلى walreceiver. هذا لأنه يمكن تحديد عوامل التصفية في جدول أو صف أو نوع إجراء عند إنشاء منشور. لذلك ، لن يتم إرسال بعض DMLs إذا تم استيفاء شروط المرشح.
الآن ، سأصف كيف تم تحسين / إصلاح المشكلتين المذكورتين في بداية هذه المقالة بشكل منفصل.
إذا تمت تصفية جميع DMLs في معاملة ما أثناء فك التشفير ، فإننا نسمي المعاملة معاملة فارغة. قبل PostgreSQL 15 ، كان المكوّن الإضافي القياسي لفك التشفير المنطقي pgoutput (المكون الإضافي للنسخ المنطقي المستخدم افتراضيًا في PostgreSQL) يرسل كل معاملة إلى walreceiver. حتى بالنسبة للمعاملة الفارغة ، على الرغم من عدم إرسال رسائل متعلقة بـ DML ، يتم إرسال الرسائل التي تحدد بداية المعاملة ونهايتها. يعد بناء / نقل هذه المعاملات الفارغة مضيعة لدورات وحدة المعالجة المركزية وعرض النطاق الترددي للشبكة. يمكننا أن نرى العملية أدناه.
كيف تعامل PostgreSQL مع المعاملات الفارغة قبل الإصدار 15
لحل هذه المشكلة ، سمحنا للوالسندر بتأجيل رسالة BEGIN حتى يتم إرسال أول رسالة DML. في نهاية فك التشفير ، إذا لم يتم إرسال رسالة BEGIN ، فلن يتم إرسال رسالة COMMIT أيضًا. يمكن الاطلاع على معلومات التطوير التفصيلية على GitHub.
بالنسبة للمعاملات غير الفارغة ، هناك أيضًا تغيير في وقت إرسال الرسالة. لنلقِ نظرة على هذا التغيير بمثال - لنفترض أن لدينا المعاملة التالية T1:
ALTER TABLE tab_1 DISABLE TRIGGER ALL;
导入数据
ALTER TABLE tab_1 ENABLE TRIGGER ALL;postgres=#BEGIN；
BEGIN
postgres=*# INSERT INTO tab_not_publish VALUES (1) ; -- 这个DML会被过滤掉
INSERT 0 1
postgres=*# INSERT INTO tab_publish VALUES (1); -- 这个 DML 将被发布
INSERT 0 1
postgres=*# COMMIT;
COMMIT
يظهر تسلسل إرسال رسالة BEGIN ورسالة COMMIT في الشكل التالي.
متى يتم إرسال رسائل BEGIN و COMMIT - قبل التعديل
كما رأينا أعلاه ، يمكن فقط إرسال رسائل INSERT للجدول tab_publish من walsender إلى walreceiver.
توقيت إرسال رسائل BEGIN و COMMIT - تم تعديله
كما هو موضح في الشكل أعلاه ، بعد التعديل ، إذا تمت تصفية جميع DMLs في المعاملة ، فلن يتم إرسال رسائل BEGIN ورسائل COMMIT. بهذه الطريقة يمكن للوالسندر تخطي إرسال المعاملات الفارغة.
ومع ذلك ، في النسخ المتماثل المنطقي المتزامن ، قبل PostgreSQL15 ، من أجل التأكد من مزامنة البيانات ، عندما يتلقى walreceiver رسالة COMMIT لمعاملة فارغة ، سيقوم بمزامنة البيانات المحلية وإرسال رسالة ملاحظات إلى walsender لتأكيد ذلك تمت مزامنة البيانات.
سيستمر الوكيل فقط بعد تلقي رسالة ملاحظات من متلقي الفالس ، وإلا فإن المرسل سيمنع العميل الخلفي من تنفيذ المعاملة. لذلك في PostgreSQL 15 ، بعد تخطي والسندر لمعاملة فارغة في النسخ المتماثل المنطقي المتزامن ، يرسل رسالة البقاء على قيد الحياة إلى walreceiver ويطلب رسالة ملاحظات. ثم سيقوم walreceiver بمزامنة البيانات وإرسال رسالة ملاحظات إلى walsender بناءً على هذه الرسالة. بهذه الطريقة يمكننا تجنب المواقف التي تؤخر فيها المعاملات الاستجابات في النسخ المتماثل المنطقي المتزامن. يوضح الرسم البياني التالي التغييرات في الاتصال في النسخ المتماثل المنطقي المتزامن.
الاتصال في النسخ المتماثل المنطقي المتزامن - قبل التعديل
الاتصال في النسخ المتماثل المنطقي المتزامن - معدل
قبل PostgreSQL 15 ، إذا كانت هناك معاملة تحتوي على العديد من DMLs المتتالية التي لم يتم نشرها ، فقد يتسبب ذلك في أن يكون الوالسندر غير قادر على التواصل مع متلقي الفالس لفترة طويلة ، لأن والسيندر سيكون مشغولاً بفك تشفير هذه DMLs غير المنشورة. في هذه الحالة ، على الرغم من أن walsender يعمل كما هو متوقع ، نظرًا لأن Walreceiver لم يتلق أي رسائل من walsender خلال المهلة المحددة ، سيؤدي ذلك إلى تلقي المتلقي لخطأ غير متوقع في المهلة.
في PostgreSQL 15 ، لتجنب هذا الخطأ ، يستمر فالسندر في التواصل مع متلقي الفال بشكل دوري. لذلك عندما يعالج Walsender حدًا معينًا من DMLs (سواء تم نشر DMLs أم لا) ، فإنه سيحاول إرسال رسائل مستمرة إلى متلقي walreceiver عند الحاجة للحفاظ على الاتصال. تتوفر تفاصيل حول هذا التطوير في GitHub.
لنفترض أن لدينا معاملة T2 ، وهناك العديد من DMLs في T2 ، ولكن لن يتم نشر أي منها. كما هو مبين في الشكل أدناه ، عند معالجة المعاملة T2 ، يتغير الاتصال بين والسندر و walreceiver.
التواصل بين والسندر والمتلقي - قبل التعديل
التواصل بين والسندر و Walreceiver - معدل
كما يتضح أعلاه ، قمنا بتعيين العتبة إلى 100 في نواة PostgreSQL (بعد اختبار الأداء ، تم التأكيد على أن هذه العتبة يمكنها حل خطأ المهلة هذا دون تقليل الأداء ، راجع 2 في نهاية المقالة). وبهذه الطريقة ، لا يتلقى walreceiver خطأ المهلة غير المتوقع عندما يعمل walsender كما هو متوقع.
أخيرًا ، سأشارك نتائج اختبار الأداء لتحسين المعاملة الفارغة.
كما ذكرنا سابقًا ، بعد إجراء تحسينات على التعامل مع المعاملات الفارغة ، لم يعد الوالسندر يرسل معاملات فارغة تحتوي فقط على رسائل BEGIN و COMMIT إلى walreceiver. هذا يقلل من حركة مرور الشبكة ويحسن الأداء. في اختباراتي ، وجدت أنه بعد التحسين ، عند فك تشفير المعاملات الفارغة ، في النسخ المتماثل المنطقي غير المتزامن ، سيرسل والسندير 97 بايت أقل ؛ في النسخ المتماثل المنطقي المتزامن ، على الرغم من أن والسيندر سينقل رسالة إضافية للبقاء على قيد الحياة ، لكن حجم النقل الإجمالي هو لا يزال ينخفض بمقدار 79 بايت. بعد ذلك ، ننظر إلى تحسين الأداء من حيث استهلاك النطاق الترددي للشبكة من خلال نتائج الاختبار.
من الواضح أن نسبة المعاملات الفارغة في المعاملات المرسلة من قبل والسندر تؤثر على نتائج الاختبار ، لذلك قمنا باختبار خمس نسب مختلفة من المعاملات الفارغة. بالإضافة إلى ذلك ، بعد التحسين ، في النسخ المتماثل المنطقي المتزامن ، إذا تخطى والسندير معاملة فارغة ، فسيتم إرسال رسالة استمرار إضافية ، بحيث يتم اختبار كل من النسخ المتماثل المنطقي المتزامن والنسخ المنطقي غير المتزامن. كما هو موضح أدناه ، تم تحسين أداء كل من النسخ المنطقي غير المتزامن والنسخ المنطقي المتزامن. (يمثل المحور السيني نسبة المعاملات الفارغة في معاملات التحويل. ويمثل المحور الصادي الحجم الإجمالي للبيانات المنقولة من قبل المرسل إلى المستلم ، بالبايت.)
مقارنة الأداء - النسخ المتماثل غير المتزامن
مقارنة الأداء - النسخ المتماثل المتزامن
يتضح من نتائج الاختبار أنه كلما زادت نسبة المعاملات الفارغة ، زاد التحسن. عندما تكون نسبة المعاملات الفارغة 25٪ و 50٪ و 75٪ و 100٪ ، يتم تقليل نقل الشبكة بحوالي 8٪ و 22٪ و 40٪ و 84٪ على التوالي. لا يوجد أيضًا تدهور في الأداء في حالة عدم وجود معاملات فارغة.
في هذا المنشور ، أشرح التحسينات في أداء ووظائف النسخ المتماثل المنطقي بسبب تخطي المعاملات الفارغة وإصلاح أخطاء المهلة غير المتوقعة. ومع ذلك ، لا تزال آلية تخطي المعاملات الفارغة بها بعض القيود.
على سبيل المثال ، الالتزام على مرحلتين لا يتخطى المعاملات الفارغة. هذا لأنه إذا قام الوكيل بإعادة التشغيل بين معاملة التحضير والالتزام بمعاملة التحضير ، فليس لدينا طريقة لمعرفة ما إذا كان قد تم تخطي معاملة التحضير عند الالتزام. بسبب نفس المشكلة ، لم يتم تحسين تدفق المعاملات الجارية (التي تم تعيينها بواسطة معلمة "الدفق" الخاصة بالمعلمة "subscription_parameter) أيضًا. قريبًا ، قد نحاول تحسين التعامل مع المعاملات الفارغة لكل من المعاملات المذكورة أعلاه بطريقة أفضل.
بالإضافة إلى ذلك ، لتحسين كفاءة تطبيق تدفقات المعاملات الجارية على walreceiver ، شارك فريقنا تصحيحًا لتطبيق المعاملات بالتوازي في walreceiver (المرجع 3 في نهاية المقالة) وكان يناقش بنشاط في المجتمع للتحسين المستمر .
الرجوع إلى هذا المنشور
1. https://www.postgresql.org/docs/15/protocol-logicalrep-message-formats.html
2. https://www.postgresql.org/message-id/OS3PR01MB6275C67F14954E05CE5D04399E139٪40OS3PR01MB6275.jpnprd01 . prod.outlook.com
3. https://www.postgresql.org/message-id/flat/CAA4eK1٪2BwyN6zpaHUkCLorEWNx75MG0xhMwcFhvjqm2KURZEAGw٪40mail.gmail.com
