PostgreSQL ليس لديه توافر عالٍ خارج الصندوق. لتحقيق HA ، تحتاج إلى وضع شيء ما ، وإعداد - بذل جهد. هناك العديد من الأدوات التي يمكن أن تساعد في زيادة توافر PostgreSQL ، وأحدها هو Patroni.للوهلة الأولى ، بوضع Patroni في بيئة اختبار ، يمكنك أن ترى ما هي الأداة الرائعة وكيف تتعامل بسهولة مع محاولاتنا لتفكيك الكتلة. ولكن في الممارسة العملية ، في بيئة الإنتاج ، لا يحدث كل شيء دائمًا بشكل جميل وأنيق. بدأت Data Egret في استخدام Patroni في نهاية عام 2018 واكتسبت بعض الخبرة: كيفية تشخيصها وتكوينها ومتى لا تعتمد على برنامج التسجيل التلقائي على الإطلاق.في HighLoad ++ ، وصف أليكسي ليسوفسكي بالتفصيل ، باستخدام الأمثلة وتحليل السجلات ، والمشكلات النموذجية التي تنشأ عند العمل مع Patroni ، وأفضل الممارسات للتغلب عليها.سوف المقالة لا: تعليمات التثبيت باتريوني وأمثلة التكوين ؛ مشاكل خارج Patroni و PostgreSQL ؛ قصص تستند إلى تجارب الآخرين ، ولكن فقط تلك المشاكل التي اكتشفتها Data Egret لأنفسهم.حول المتحدث: أليكسي ليسوفسكي (ليسوفسكي) كمدير نظام (مسؤول نظام Linux) ، وعمل في تطوير الويب (مسؤول قاعدة بيانات PostgreSQL). تعمل منذ عام 2014 في Data Egret. تعمل Data Egret في مجال الاستشارات في مجال PostgreSQL ، وتساعد العديد والعديد من الشركات على استخدام PostgreSQL بشكل صحيح ، وبالطبع ، اكتسبت خبرة واسعة في تشغيل قاعدة البيانات.التقرير الذي تستند إليه هذه المقالة يسمى "قصص فشل Patroni أو كيفية تعطل مجموعة PostgreSQL" ، هنا رابط للعرض التقديمي .قبل ان تبدا
دعني أذكرك ما هو Patroni ، وما هو المقصود به وما يمكن أن يفعله.Patroni هو قالب لبناء HA خارج الصندوق. لذا فهو مكتوب في الوثائق ومن وجهة نظري - هذا توضيح صحيح للغاية. أي أن Patroni ليس رصاصة فضية حددها وسيحل جميع المشاكل. من الضروري بذل الجهود حتى تبدأ في العمل وجلب الفوائد.Patroni - خدمة الوكيل. يتم تثبيته على كل خادم بقاعدة بيانات وهو نوع من نظام التهيئة لـ PostgreSQL: فهو يبدأ ، ويوقف ، ويعيد التشغيل ، ويغير التكوين والطبولوجيا للكتلة.يخزن Patroni "حالة الكتلة" في DCS.لتخزين حالة الكتلة ، طريقة العرض الحالية ، تحتاج إلى التخزين. يخزن Patroni الدولة في نظام خارجي - مستودع التكوين الموزع. يمكن أن يكون هذا أحد الخيارات: Etcd أو Consul أو ZooKeeper أو Etcd Kubernetes.يتم تمكين ملف Patroni AutoFile بشكل افتراضي. تحصل على برنامج تسجيل تلقائي من العلبة ، فور تثبيت Patroni.بالإضافة إلى ذلك ، هناك العديد من الأشياء الأخرى ، مثل: خدمة التكوينات وإنشاء نسخ متماثلة جديدة والنسخ الاحتياطي وما إلى ذلك. ولكن هذه المرة ستبقى خارج نطاق التقرير.الهدف الرئيسي من Patroni هو توفير ملف تلقائي موثوق به.
لا يتعين على Patroni مراقبة المعدات ، وإرسال الإشعارات ، والقيام بأشياء معقدة حول الوقاية من الحوادث المحتملة ، إلخ. مطلوب أن تظل المجموعة قيد التشغيل ويمكن أن يستمر التطبيق في العمل مع قاعدة البيانات ، بغض النظر عن أي تغييرات في طوبولوجيا الكتلة.ولكن عندما نبدأ في استخدام Patroni مع PostgreSQL ، يصبح نظامنا أكثر تعقيدًا. الآن ، بالإضافة إلى قاعدة البيانات نفسها ، عندما يفشل الرئيسي أو النسخة المتماثلة ، قد ينهار Patroni نفسه ، التخزين الموزع لحالات الكتلة ، أو الشبكة. ضع في اعتبارك جميع الخيارات لأنها تصبح أكثر تعقيدًا من حيث مدى صعوبة فهم أسبابها.المشكلة 1. DBMS و DCS على نفس الكتلة
النظر في أبسط الحالات: أخذنا مجموعة قاعدة بيانات ونشرنا DCS على نفس المجموعة. هذا الخطأ الشائع لا يرتبط فقط بأخطاء نشر PostgreSQL و Patroni. هذا خطأ في البناء العام للمعماريات - يجمع بين العديد من المكونات المختلفة في مكان واحد.لذا ، كان هناك فشل. نبدأ في فهم ما حدث. هنا نحن مهتمون بوقت حدوث العاشق ، أي النقطة الزمنية التي تغيرت فيها حالة العنقود.متى حدث الفشل؟
لا يحدث faylover دائمًا على الفور ؛ فقد يستغرق وقتًا طويلاً. لذلك ، لديه وقت البدء ووقت الانتهاء. تنقسم جميع الأحداث إلى "قبل" و "أثناء" و "بعد" العاشق.بادئ ذي بدء ، عندما حدث العاشق ، نحن نبحث عن السبب.pgdb-2 patroni: INFO: promoted self to leader by acquiring session lock
pgdb-2 patroni: WARNING: Loop time exceeded, rescheduling immediately.
pgdb-2 patroni: INFO: Lock owner: pgdb-2; I am pgdb-2
pgdb-2 patroni: INFO: updated leader lock during promote
pgdb-2 patroni: server promoting
pgdb-2 patroni: INFO: cleared rewind state after becoming the leader
pgdb-2 patroni: INFO: Lock owner: pgdb-2; I am pgdb-2
أعلاه هي سجلات Patroni القياسية ، حيث أبلغ عن تغير دور الخادم وانتقل دور المعالج من آخر إلى هذه العقدة.لماذا حدث الفشل؟
بعد ذلك ، تحتاج إلى فهم الأحداث التي جعلت دور المعلم ينتقل من عقدة إلى أخرى ، وما حدث للسيد القديم.pgdb-2 patroni: patroni.utils.RetryFailedError: 'Exceeded retry deadline'
pgdb-2 patroni: ERROR: Error communicating with DCS
pgdb-2 patroni: INFO: demoted self because DCS is not accessible and i was a leader
pgdb-2 patroni: WARNING: Loop time exceeded, rescheduling immediately.
في هذه الحالة ، كل شيء بسيط: Error communicating with DCS- خطأ في التفاعل مع نظام تخزين التكوين. أدرك السيد أنه لا يستطيع العمل مع DCS ، وقال إنه لم يعد بإمكانه أن يكون سيدًا واستقال. demoted selfيتحدث عن هذا.ما سبق العاشق؟
إذا نظرت إلى الأحداث التي سبقت feylover ، يمكنك رؤية الأسباب التي أصبحت مشكلة في استمرار المعالج:pgdb-2 patroni: ERROR: touch_member
... python trace
pgdb-2 patroni: socket.timeout: timed out
pgdb-2 patroni: During handling of the above exception, another exception occurred:
... python trace
pgdb-2 patroni: raise ReadTimeoutError(self, url, "Read timed out. (read timeout=%s)" % timeout_value)
pgdb-2 patroni: urllib3.exceptions.ReadTimeoutError: HTTPConnectionPool(host='127.0.0.1', port=8500): Read timed out. (read timeout=3.3333333333333335)
pgdb-2 patroni: During handling of the above exception, another exception occurred:
... python trace
pgdb-2 patroni: raise MaxRetryError(_pool, url, error or ResponseError(cause))
pgdb-2 patroni: urllib3.exceptions.MaxRetryError: HTTPConnectionPool(host='127.0.0.1', port=8500): Max retries exceeded with url: /v1/kv/service/pgdb/members/pgdb-2?acquire=19598b72-c0d5-f066-5d24-09c1a9ad61ee&dc=maindb (Caused by ReadTimeoutError("HTTPConnectionPool(host='127.0.0.1', port=8500): Read timed out. (read timeout=3.3333333333333335)",))
pgdb-2 patroni: INFO: no action. i am the leader with the lock
pgdb-2 patroni: WARNING: Loop time exceeded, rescheduling immediately.
تظهر سجلات Patroni الكثير من أخطاء المهلة المختلفة. تعذر على وكيل Patroni العمل مع DCS (في هذه الحالة ، يكون القنصل ، المنفذ = 8500). تم تشغيل Patroni وقاعدة البيانات على نفس المضيف ، وكانت خوادم القنصل تعمل على نفس المضيف. بعد إنشاء الحمل على الخادم ، أنشأنا أيضًا مشاكل لخادم القنصل ، حيث لم يتمكنوا من التواصل بشكل طبيعي.كل شيء عاد كما كان
بعد فترة ، عندما خف الحمل ، تمكن Patroni من التواصل مرة أخرى مع الوكلاء ، واستأنف كل شيء:pgdb-2 patroni: INFO: promoted self to leader by acquiring session lock
pgdb-2 patroni: WARNING: Loop time exceeded, rescheduling immediately.
pgdb-2 patroni: INFO: Lock owner: pgdb-2; I am pgdb-2
pgdb-2 patroni: INFO: updated leader lock during promote
pgdb-2 patroni: server promoting
pgdb-2 patroni: INFO: cleared rewind state after becoming the leader
pgdb-2 patroni: INFO: Lock owner: pgdb-2; I am pgdb-2
أصبح خادم pgdb-2 مرة أخرى سيدًا. كان هناك "قلب" صغير - في وقت قصير نسبيًا استقال من نفسه باعتباره سيدًا ، ثم أخذها مرة أخرى على نفسه.يمكن اعتبار هذا إما إيجابيًا كاذبًا ، أو حقيقة أن Patroni فعل كل شيء بشكل صحيح.القرار
قررنا لأنفسنا أن المشكلة تكمن في أن خوادم القنصل على نفس الأجهزة مثل قواعد البيانات. وفقًا لذلك ، فإن أي حمل على وحدة المعالجة المركزية والأقراص (طلب إدخال / إخراج كثيف ، ملفات مؤقتة ، الفراغات التلقائية ، الترحيل ، النسخ الاحتياطية ، إلخ) يؤثر أيضًا على التفاعل مع مجموعة القنصل. قررنا أن هذا لا ينبغي أن يعيش على نفس المعدات مع قاعدة البيانات ، وخصصنا مجموعة منفصلة للقنصل.بدلاً من ذلك ، يمكنك تدوير المعلمات ttl، loop_wait، retry_timeout، حاول بسبب زيادتها من أجل تحمل أحمال الذروة قصيرة المدى. ولكن إذا كان الحمل طويلًا ، فسوف نتجاوز هذه المعلمات ، ولن تعمل الطريقة.مشكلة 2. انقطاع
المشكلة الثانية تشبه المشكلة الأولى حيث لدينا مرة أخرى مشاكل في التفاعل مع نظام DCS:maindb-1 patroni: ERROR: get_cluster
maindb-1 patroni: Traceback (most recent call last):
... python trace
maindb-1 patroni: RetryFailedError: 'Exceeded retry deadline'
maindb-1 patroni: ERROR: Error communicating with DCS
maindb-1 patroni: INFO: closed patroni connection to the postgresql cluster
maindb-1 patroni: INFO: postmaster pid=214121
...
...
maindb-1 patroni: INFO: demoted self because DCS is not accessible and i was a leader
maindb-1 patroni: WARNING: Loop time exceeded, rescheduling immediately.
يقول Patroni مرة أخرى أنه لا يمكنه التفاعل مع DCS ، لذلك يتوقف المعلم الحالي عن كونه سيدًا ويدخل في وضع النسخ المتماثلة. يصبح السيد القديم نسخة طبق الأصل:maindb-1 patroni: INFO: Lock owner: maindb-2; I am maindb-1
maindb-1 patroni: INFO: does not have lock
maindb-1 patroni: INFO: running pg_rewind from maindb-2
maindb-1 patroni: INFO: running pg_rewind from user=postgres host=192.168.11.18 port=5432 ...
maindb-1 patroni: servers diverged at WAL location 1FA/A38FF4F8 on timeline 6
maindb-1 patroni: rewinding from last common checkpoint at 1FA/A38FF450 on timeline 6
maindb-1 patroni: INFO: Lock owner: maindb-2; I am maindb-1
maindb-1 patroni: INFO: running pg_rewind from maindb-2 in progress
maindb-1 patroni: Done!
هنا يعمل Patroni كما ينبغي - يتم إطلاقه pg_rewindلترجيع سجل المعاملات ، ثم الاتصال بالسيد الجديد واللحاق بالفعل بالسيد الجديد.ما سبق العاشق؟
دعونا نجد أول شيء يسبق feylover - الأخطاء التي تسببت فيه. تعتبر سجلات Patroni ملائمة في هذا الصدد: يكتب نفس الرسائل بفاصل زمني معين. يمكنك تمريرها بسرعة ومعرفة متى تغيرت السجلات. عند هذه النقطة ، بدأت بعض المشاكل.في الوضع العادي ، تبدو سجلات Patroni على النحو التالي:maindb-1 patroni: INFO: Lock owner: maindb-1; I am maindb-1
maindb-1 patroni: INFO: no action. i am the leader with the lock
maindb-1 patroni: INFO: Lock owner: maindb-1; I am maindb-1
maindb-1 patroni: INFO: no action. i am the leader with the lock
يتم فحص مالك القفل ، إذا تغير ، فقد تحدث أحداث يجب على Patroni الاستجابة لها. في هذه الحالة ، كل شيء في محله.بعد التمرير إلى المكان الذي بدأت فيه الأخطاء في الظهور ، نرى حدوث ملف تسجيل تلقائي. نظرًا لأن الأخطاء كانت مرتبطة بالتفاعل مع DCS ، فإننا ننظر أيضًا إلى سجلات القنصل - ما حدث هناك. عند مقارنة وقت faylover تقريبًا والوقت في سجلات القنصل ، نرى أن الجيران في مجموعة القنصل بدأوا يشكون في وجود مشاركين آخرين:maindb-2 consul[11581]: serf: EventMemberFailed: maindb-1 192.168.11.19
maindb-2 consul[11581]: [INFO] serf: EventMemberFailed: maindb-1 192.168.11.19
maindb-2 consul[11581]: memberlist: Suspect maindb-1 has failed, no acks received
maindb-2 consul[11581]: [INFO] memberlist: Suspect maindb-1 has failed, no acks received
إذا نظرت إلى سجلات وكلاء القنصل الآخرين ، فإنه يوضح أيضًا أن هناك انهيارًا في الشبكة: يشك جميع أعضاء مجموعة القنصل في بعضهم البعض. كان هذا هو الدافع ل feylover.إذا نظرنا إلى الإدخالات السابقة ، فسوف نرى أن نظام القنصل الخاص بوكيل PostgreSQL يواجه صعوبات في الاتصال ( deadline reached، RPC failed):maindb-1 consul: memberlist: Suspect lbs-4 has failed, no acks received
maindb-1 consul: [ERR] yamux: keepalive failed: i/o deadline reached
maindb-1 consul: yamux: keepalive failed: i/o deadline reached
maindb-1 consul: [ERR] consul: "KVS.List" RPC failed to server 192.168.11.115:8300: rpc error making call: EOF
maindb-1 consul: [ERR] http: Request GET /v1/kv/service/sam_prod/?recurse=1, error: rpc error making call: EOF from=192.168.11.19
maindb-1 consul: [ERR] consul: "KVS.List" RPC failed to server 192.168.11.115:8300: rpc error making call: EOF
maindb-1 consul: [ERR] agent: Coordinate update error: rpc error making call: EOF
maindb-1 consul: [ERR] http: Request GET /v1/kv/service/sam_prod/?recurse=1, error: rpc error making call: EOF from=192.168.11.19
القرار
أبسط إجابة هي إصلاح الشبكة . من السهل تقديم المشورة ، لكن الظروف يمكن أن تكون مختلفة ، وهذا ليس ممكنًا دائمًا. يمكن أن يعيش النظام في مركز بيانات ، حيث لا يمكننا التأثير على المعدات. تحتاج إلى خيارات أخرى.هناك خيارات حل دون العمل مع شبكة:- Consul- —
checks: [].
, . , Consul- . . raft_multiplier.
Consul-, 5 ( staging-). Consul-. - .renice -n -10 consul.
. renice . Consul-, .- consul?
Consul- . Patroni Consul- , : - , Patroni . etcd, , etcd . Patroni etcd-. - , , , Consul. ttl, loop_wait, retry_timeout.
, . Patroni .
المشكلة 3. فقدان العقدة
إذا كنت تستخدم Patroni ، فأنت على دراية بأمر قائمة patronictl ، والذي يوضح الحالة الحالية للكتلة:$ patronictl list
+-----------------+-------------------------+--------------+--------+---------+-----------+
| Cluster | Member | Host | Role | State | Lag in MB |
+-----------------+-------------------------+--------------+--------+---------+-----------+
| patroni_cluster | pg01.dev.zirconus.local | 10.202.1.101 | | running | 0.0 |
| patroni_cluster | pg03.dev.zirconus.local | 10.202.1.103 | Leader | running | 0.0 |
+-----------------+-------------------------+--------------+--------+---------+-----------+
للوهلة الأولى ، قد يبدو هذا الاستنتاج طبيعيًا - هناك نسخة طبق الأصل ، ولكن لا يوجد تأخر في النسخ المتماثل. لكن هذه الصورة طبيعية تمامًا حتى نعرف أنه في هذه المجموعة يجب أن يكون هناك 3 عقد ، وليس 2.لماذا حدث الفشل؟
نحن نتفهم أنه حدث برنامج تسجيل تلقائي وبعد ذلك اختفت نسخة طبق الأصل. نحتاج إلى معرفة سبب اختفائها وإعادتها.ندرس السجلات مرة أخرى لفهم سبب حدوث برنامج التسجيل التلقائي:pg02 patroni[1425]: ERROR: failed to update leader lock
pg02 patroni[1425]: INFO: demoted self because failed to update leader lock in DCS
pg02 patroni[1425]: WARNING: Loop time exceeded, rescheduling immediately.
pg02 patroni[1425]: INFO: Lock owner: None; I am pg02.dev.zirconus.local
pg02 patroni[1425]: INFO: not healthy enough for leader race
pg02 patroni[1425]: INFO: starting after demotion in progress
تعذر على الصفحة الرئيسية pg02 تحديث المفتاح الرئيسي ERROR: failed to update leader lock.ثم أصبحت النسخة المتماثلة الثانية من db03 الرئيسية ، كل شيء هنا بالترتيب:pg03 patroni[9648]: INFO: promoted self to leader by acquiring session lock
pg03 patroni[9648]: server promoting
pg03 patroni[9648]: INFO: cleared rewind state after becoming the leader
ماذا عن السيد القديم؟
بدأ pg02 ، الذي قرر أن يصبح نسخة طبق الأصل ، بإعادة لف سجل المعاملات. هنا نحتاج إلى إلقاء نظرة على سجلات النسخ المتماثلة ، التي ليست في الكتلة. افتح سجلات Patroni وشاهد أنه أثناء عملية الاتصال بالمجموعة ، ظهرت مشكلة في المرحلة pg_rewind.pg02 patroni[1425]: INFO: running pg_rewind from pg03
pg02 patroni[1425]: INFO: running pg_rewind from user=postgres host=10.202.1.103 port=5432 ...
pg02 patroni[1425]: servers diverged at WAL location 33F/68E6AD10 on timeline 28
pg02 patroni[1425]: could not open file "/data/pgdb/11/pg_wal/0000001C0000033F00000059": No such file or directory
pg02 patroni[1425]: could not find previous WAL record at 33F/59FFE368 pg02 patroni[1425]: Failure, exiting
pg02 patroni[1425]: ERROR: Failed to rewind from healty master: pg03
pg02 patroni[1425]: WARNING: Postgresql is not running.
للاتصال بالمجموعة ، يجب أن تطلب العقدة سجل المعاملات من المعالج والتقاط المعالج منه. في هذه الحالة ، لا يوجد سجل المعاملات ( No such file or directory) ، ولا يمكن بدء النسخة المتماثلة. وفقًا لذلك ، يتوقف PostgreSQL مع وجود خطأ. عليك أن تفهم سبب عدم وجود سجل المعاملات.دعونا نرى ما لدى السيد الجديد في WAL:LOG: checkpoint complete:
wrote 62928 buffers (16.0%); 0 WAL file(s) added, 0 removed, 23 recycled;
write=12.872 s, sync=0.020 s, total=13.001 s;
sync files=16, longest=0.009 s, average=0.001 s;
distance=520220 kB, estimate=520220 kB
اتضح أنه أثناء تشغيله pg_rewind، حدثت نقطة تفتيش ، وتمت إعادة تسمية بعض سجلات المعاملات القديمة . عندما حاول السيد القديم الاتصال بالسيد الجديد وطلب هذه السجلات ، تمت إعادة تسميتها بالفعل ، ولم تكن موجودة ببساطة.وفقًا للطابع الزمني ، يبلغ الوقت بين هذه الأحداث حرفًا 150 مللي ثانية.2019-08-26 00:06:11,369 LOG: checkpoint complete
2019-08-26 00:06:11,517 INFO: running pg_rewind
ولكن هذا كان كافيًا لجعل النسخة المتماثلة غير قادرة على الاتصال والكسب.القرار
في البداية ، استخدمنا فتحات النسخ المتماثل. بدا هذا الحل جيدًا بالنسبة لنا ، على الرغم من أننا قمنا في المرحلة الأولى من التشغيل بإغلاق الفتحات. كنا نظن أنه إذا كانت الفتحات ستراكم العديد من شرائح المشي ، يمكن للسيد أن يسقط. بعد أن عانيت لبعض الوقت دون فتحات ، أدركنا أننا بحاجة إليها وأعادناها.تكمن المشكلة في أنه عندما يدخل المعالج في حالة النسخة المتماثلة ، يقوم المعالج بحذف الفتحات وأجزاء wal معهم. لتسوية هذه المشكلة ، قمنا بزيادة المعلمة wal_keep_segments. بشكل افتراضي ، يساوي 8 أجزاء ، قمنا برفعها wal_keep_segmentsإلى 1000 . لقد خصصنا 16 غيغابايت wal_keep_segments، والآن عند التبديل ، لدينا دائمًا 16 غيغابايت من سجلات المعاملات على جميع العقد.وينطبق هذا أيضًا على مهام الصيانة طويلة المدى. لنفترض أننا بحاجة إلى تحديث إحدى النسخ المتماثلة (البرامج ، ونظام التشغيل ، وشيء آخر) ، ونريد إيقاف تشغيله. عند إيقاف تشغيل النسخة المتماثلة ، يتم حذف الفتحة أيضًا. إذا كنت تستخدم قيمة معلمة صغيرة wal_keep_segments، فبالنسبة لغياب النسخة المتماثلة لفترة طويلة ، فستطلب سجلات المعاملات التي قد لا تظهر حتى في المعالج - فلن تتمكن النسخة المتماثلة من الاتصال. لذلك ، نحافظ على كمية كبيرة من المجلات.المشكلة 4. فقدان البيانات
كان هناك فشل في قاعدة الإنتاج. لقد راجعنا المجموعة: كل شيء على ما يرام ، وجميع النسخ المتماثلة في مكانها الصحيح ، ولا يوجد تأخر في النسخ المتماثل ، ولا توجد أخطاء في السجلات أيضًا. لكن فريق المنتج يشير إلى عدم وجود بيانات كافية في قاعدة البيانات - فهي موجودة في مصدر واحد ، ولكن ليس في قاعدة البيانات. تحتاج إلى فهم ما حدث لهم.أدركنا على الفور أن هذا هو pg_rewindمربىهم ، لكننا بحاجة إلى معرفة السبب.متى حدث الفشل؟
يمكننا دائمًا أن نجد في السجلات وقت حدوث العاشق ، الذي أصبح السيد الجديد ، الذي كان السيد من قبل وعندما أراد أن يصبح نسخة طبق الأصل.pgdb-1 patroni[17836]: INFO: promoted self to leader by acquiring session lock
pgdb-1 patroni[17836]: server promoting
pgdb-1 patroni[17836]: INFO: cleared rewind state after becoming the leader
pgdb-1 patroni[17836]: INFO: Lock owner: pgdb-1; I am pgdb-1
من السجلات ، يمكننا تحديد مقدار سجلات المعاملات التي تم فقدها.كان الأمر على هذا النحو: تم إعادة تشغيل المعالج القديم ، بعد إعادة تشغيله بواسطة التشغيل التلقائي ، تم إطلاق Patroni ، والذي أطلق بعد ذلك PostgreSQL. قررت PostgreSQL أن تصبح عضوًا في مجموعة Patroni وأطلقت عملية pg_rewind، بدورها ، قامت بمسح جزء من سجلات المعاملات ، وتنزيل سجلات جديدة وربطها.عمل Patroni تمامًا كما هو مقصود. تعافى الكتلة: كان هناك 3 عقد ، بعد 3 عقد feylover واليسار. ولكن جزءًا من البيانات يتم فقده ، وتحتاج إلى فهم أي جزء منه.ابحث في سجلات المعلم القديم عن اللحظة التي حدث فيها pg_rewind:pgdb-2 patroni[4149]: INFO: running pg_rewind from pgdb-1
pgdb-2 patroni[4149]: Lock owner: pgdb-1; I am pgdb-2
pgdb-2 patroni[4149]: Deregister service pgdb/pgdb-2
pgdb-2 patroni[4149]: running pg_rewind from pgdb-1 in progress
pgdb-2 patroni[4149]: running pg_rewind from user=replica host=10.10.1.31 port=5432 ...
pgdb-2 patroni[4149]: servers diverged at WAL location 0/5AD1BFD8 on timeline 66
pgdb-2 patroni[4149]: rewinding from last common checkpoint at 0/59DD1070 on timeline 66
pgdb-2 patroni[4149]: Done!
تحتاج إلى العثور على المركز في سجل المعاملات ، الذي أوقف الرئيسي القديم.pgdb-2 patroni[4149]: INFO: Local timeline=66 lsn=0/5BDA8EB8
pgdb-2 patroni[4149]: INFO: master_timeline=67
...
pgdb-2 patroni[4149]: servers diverged at WAL location 0/5AD1BFD8 on timeline 66
postgres=# select pg_wal_lsn_diff('0/5BDA8EB8','0/5AD1BFD8');
pg_wal_lsn_diff
----------------
17354464
في هذه الحالة ، تكون العلامة 0 / 5BDA8EB8. العلامة الثانية - 0 / 5AD1BFD8 - مطلوبة لإيجاد المسافة التي يختلف بها المعلم القديم عن المعلم الجديد. باستخدام الوظيفة pg_wal_lsn_diff ، نقارن بين هاتين العلامتين ، نحصل على 17 ميغابايت.يقرر ما إذا كان هناك فقدان كبير للبيانات بمقدار 17 ميغابايت. بالنسبة للبعض ، هذا غير مهم ، ولكن بالنسبة لشخص ما فهو أمر غير مقبول كثيرًا. كل لنفسه يحدد بشكل فردي وفقا لاحتياجات العمل.القرار
بادئ ذي بدء ، تحتاج إلى تحديد ما إذا كانت هناك حاجة دائمًا إلى تشغيل Patroni التلقائي بعد إعادة تشغيل النظام . في معظم الأحيان ، يجب أن نذهب إلى المعلم القديم ، ونرى مدى اختلافه عن الحالة الحالية ، وربما فحص أجزاء سجل المعاملات. تحتاج إلى فهم ما إذا كان يمكن فقدان هذه البيانات ، أو تحتاج إلى تشغيل المعالج القديم في الوضع المستقل لسحب البيانات. فقط بعد ذلك اتخذ قرارًا بشأن ما يجب فعله بالبيانات وربط هذه العقدة كنسخة طبق الأصل إلى مجموعتنا.بالإضافة إلى ذلك ، هناك معلمةmaximum_lag_on_failover، قيمته بشكل افتراضي 1 ميغا بايت. يعمل مثل هذا: إذا كانت النسخة المتماثلة 1 ميجابايت خلف تأخر النسخ المتماثل ، فإن هذه النسخة المتماثلة لا تشارك في الانتخابات. إذا حدث فجأة فشل ، يبحث Patroni عن النسخ المتماثلة التي تتخلف عن الركب ، وتلك التي تتخلف عن عدد كبير من سجلات المعاملات لا يمكن أن تصبح رئيسية. هذه ميزة أمان جيدة تمنعك من فقدان الكثير من البيانات.ولكن هناك مشكلة: يتم تحديث تأخر النسخ المتماثل على فاصل زمني معين ، والقيمة ttlالافتراضية هي 30 ثانية. من الممكن أن تكون قيمة تأخر النسخ المتماثل للنسخ المتماثلة في DCS واحدة ، ولكنها في الواقع مختلفة تمامًا أو لا يوجد تأخير على الإطلاق. هذه ليست قيمة في الوقت الحقيقي ؛ فهي لا تعكس دائمًا الصورة الحقيقية ولا تستحق ربط المنطق المعقد بها.يبقى خطر "الخسائر" دائمًا:- في أسوأ الحالات:
maximum_lag_on_failover + ttl. - في متوسط القضية:
maximum_lag_on_failover + (loop_wait / 2).
عندما تخطط لتطبيق Patroni وتقييم مقدار البيانات التي يمكن أن تفقدها ، فكر في هذه الصيغ لتمثيل الخسائر المحتملة تقريبًا.الخبر السار هو أنه قد يكون هناك WAL من العمليات الخلفية في "الخسائر". يمكن تجاهل هذه البيانات وفقدانها بسهولة ، ولا توجد مشكلة.هذا هو شكل السجلات إذا تم تعيينها maximum_lag_on_failover، حدث feylover وتحتاج إلى تحديد معالج جديد:pgdb-1 patroni[6202]: INFO: Lock owner: None; I am pgdb-1
pgdb-1 patroni[6202]: INFO: not healthy enough for leader race
pgdb-1 patroni[6202]: INFO: changing primary_conninfo and restarting in progress
...
pgdb-1 patroni[6202]: INFO: following a different leader because i am not the healthiest node
pgdb-1 patroni[6202]: INFO: following a different leader because i am not the healthiest node
ترى النسخة المتماثلة ببساطة أنها not healthy enough for leader raceوترفض المشاركة في سباق القيادة. لذلك ، ينتظر ببساطة تحديد معالج جديد للاتصال به. هذا إجراء إضافي ضد فقدان البيانات.المشكلة 5. محركات الأقراص
كتب فريق المنتج أن التطبيق يواجه مشاكل في العمل مع PostgreSQL. في الوقت نفسه ، لا يمكنك إدخال الصفحة الرئيسية ، لأنها غير متاحة عبر SSH ، ولكن لا يحدث المصور التلقائي أيضًا. ثم تم إعادة تشغيل المضيف بالقوة وبالتالي أطلق المصور التلقائي. على الرغم من أنه كان من الممكن عمل feylover يدوي.بعد إعادة التشغيل ، نذهب لنرى ما حدث للسيد.
عرفنا مقدما عن مشاكل الأقراص ؛ من خلال المراقبة عرفنا أين نحفر.في سجلات PostgreSQL ، نرى ما يلي:[COMMIT] LOG: duration: 1138.868 ms statement: COMMIT
...
[] WARNING: autovacuum worker started without a worker entry
...
[SELECT] LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp11247.983", size 532996096
...
على الوجه جميع مؤشرات مشاكل الأقراص: عمليات تستمر لثانية واحدة ، يعمل الفراغ التلقائي طويلًا وغريبًا ، وملفات مؤقتة على القرص.نظرنا في نظام dmesg - سجل رسائل kernel ، وشاهدنا مشكلة في أحد الأقراص:md/raid10:md2: sde3: rescheduling sector 351273392
blk_update_request: I/O error, dev sde, sector 64404728
md/raid10:md2: sde3: rescheduling sector 63161592
blk_update_request: I/O error, dev sde, sector 64404760
...
md2 : active raid10 sda3[0] sdc3[2] sdd3[3] sdb3[1] sdh3[7] sdf3[5] sdg3[6]
15623340032 blocks super 1.2 512K chunks 2 near-copies [8/7] [UUUUUUU_]
bitmap: 58/59 pages [232KB], 131072KB chunk
كان النظام الفرعي للقرص الموجود على الخادم عبارة عن برنامج رائد لـ 8 أقراص ، ولكن أحد الأقراص مفقود. الخط sda3[0] sdc3[2] sdd3[3] sdb3[1] sdh3[7] sdf3[5] sdg3[6]مفقود sde[4]. نسبيًا ، سقط قرص واحد ، تسبب هذا في مشاكل في القرص ، وكان للتطبيق مشاكل في العمل مع مجموعة PostgreSQL.القرار
في هذه الحالة ، لن يتمكن Patroni من المساعدة ، لأن Patroni ليس لديه مهمة لمراقبة حالة الخادم والأقراص. خلال المشاكل ، استمر Patroni في التفاعل مع مجموعة DCS ولم ير أي صعوبات. في مثل هذه الحالات ، هناك حاجة للرصد الخارجي.مشكلة 6. محاكاة الكتلة
هذه واحدة من أغرب المشاكل. لقد درستها لفترة طويلة جدًا ، وأعدت قراءة الكثير من السجلات وأطلق عليها "محاكي الكتلة".كانت المشكلة أن السيد القديم لا يمكن أن يصبح جديلة عادية. قامت Patroni بتشغيلها ، وأظهرت أن هذه العقدة موجودة كنسخة متماثلة ، ولكن في نفس الوقت لم تكن نسخة متماثلة عادية ، والآن سترى السبب.بدأ كل شيء ، كما في الحالة السابقة ، بمشاكل القرص:14:48:55.601 [COMMIT] LOG: duration: 1478.118 ms statement: COMMIT
14:48:56.287 [COMMIT] LOG: duration: 1290.203 ms statement: COMMIT
14:48:56.287 [COMMIT] LOG: duration: 1778.465 ms statement: COMMIT
14:48:56.287 [COMMIT] LOG: duration: 1778.449 ms statement: COMMIT
كانت هناك اتصالات مقطوعة:14:48:58.078 [idle in transaction] LOG: could not send data to client: Broken pipe
14:48:58.078 [idle] LOG: could not send data to client: Broken pipe
14:48:58.078 [idle] FATAL: connection to client lost
14:48:58.107 [idle in transaction] FATAL: connection to client lost
كانت هناك توقعات طويلة للاستجابة وحجب شدة متفاوتة:14:49:26.929 [UPDATE waiting] LOG: process 4298 acquired ExclusiveLock on tuple (2,10) of relation 52082 of database 50587 after 52487.463 ms
14:49:26.929 [UPDATE waiting] STATEMENT: UPDATE sessions SET lastaccess='1565005714' WHERE sessionid=...
14:49:27.929 [UPDATE waiting] LOG: process 4298 still waiting for ShareLock on transaction 364118337 after 1000.088 ms
14:49:27.929 [UPDATE waiting] DETAIL: Process holding the lock: 4294. Wait queue: 4298.
بشكل عام ، هناك مشاكل واضحة مع الأقراص ، بما في ذلك الملفات المؤقتة مرة أخرى.ولكن الأكثر غموضا بالنسبة لي - طار في immediate shutdown request:14:49:34.102 MSK 5335 @ from [] LOG: received immediate shutdown request
14:49:34.689 [authentication] WARNING: terminating connection because of crash of another server process
14:49:34.689 [authentication] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory
يحتوي PostgreSQL على ثلاثة أوضاع لإيقاف التشغيل:- رشيقة عندما ننتظر قطع اتصال جميع العملاء بأنفسهم.
- سريع ، عندما نطلب من العملاء قطع الاتصال ، لأننا سنغلق.
- فوري ، والذي لا يخبر العملاء أنه من الضروري قطع الاتصال ، ولكنه ببساطة يقوم بإيقاف تشغيله ويرسل رسالة RST إلى كافة العملاء (إشارة TCP إلى انقطاع الاتصال).
لا ترسل عمليات الخلفية في PostgreSQL إشارات طلب إيقاف التشغيل الفوري إلى بعضها البعض ، ولكنها تستجيب لها فقط. هذه إعادة تشغيل طارئة ، ومن الذي أرسلها غير واضح. إذا كان الأمر كذلك kill -9، فسأراه في السجلات ، ولكنه لم يكن موجودًا.مزيد من الفهم ، رأيت أن Patroni لم يكتب إلى السجل لبعض الوقت - ببساطة لم تكن هناك رسائل لمدة 54 ثانية. خلال هذا الوقت ، قامت إحدى النسخ المتماثلة بعمل "ترويج" وحدث ملف تلقائي:pgsql03 patroni: 14:48:25,000 INFO: Lock owner: pgsql03; I am pgsql03
pgsql03 patroni: 14:48:25,013 INFO: no action. i am the leader with the lock
pgsql03 patroni: 14:48:37,159 INFO: Lock owner: pgsql03; I am pgsql03
pgsql03 patroni: 14:49:31,155 WARNING: Exception hened during processing of request from 10.1.0.12
pgsql03 patroni: 14:49:31,297 WARNING: Exception hened during processing of request from 10.1.0.11
pgsql03 patroni: 14:49:31,298 WARNING: Exception hened during processing of request from 10.1.0.11
عمل Patroni تمامًا مرة أخرى هنا ، ولم يكن السيد القديم متاحًا ، لذلك بدأ انتخاب سيد جديد.pgsql01 patroni: 14:48:57,136 INFO: promoted self to leader by acquiring session lock
pgsql01 patroni: server promoting
pgsql01 patroni: 14:48:57,214 INFO: cleared rewind state after becoming the leader
pgsql01 patroni: 14:49:05,013 INFO: Lock owner: pgsql01; I am pgsql01
pgsql01 patroni: 14:49:05,023 INFO: updated leader lock during promote
أصبح pgsql01 الزعيم الجديد ، وكانت هناك مشاكل فقط مع النسخة المتماثلة الثانية. حاولت بصدق إعادة تكوين:pgsql02 patroni: 14:48:57,124 INFO: Could not take out TTL lock
pgsql02 patroni: 14:48:57,137 INFO: following new leader after trying and failing to obtain lock
pgsql02 patroni: 14:49:05,014 INFO: Lock owner: pgsql01; I am pgsql02
pgsql02 patroni: 14:49:05,025 INFO: changing primary_conninfo and restarting in progress
pgsql02 patroni: 14:49:15,011 INFO: Lock owner: pgsql01; I am pgsql02
pgsql02 patroni: 14:49:15,014 INFO: changing primary_conninfo and restarting in progress
pgsql02 patroni: 14:49:25,011 INFO: Lock owner: pgsql01; I am pgsql02
pgsql02 patroni: 14:49:25,014 INFO: changing primary_conninfo and restarting in progress
pgsql02 patroni: 14:49:35,011 INFO: Lock owner: pgsql01; I am pgsql02
pgsql02 patroni: 14:49:35,014 INFO: changing primary_conninfo and restarting in progress
حاولت تغيير recovery.conf ، وأعد تشغيل PostgreSQL ، واتصل بالمعالج الجديد. كل 10 ثوان توجد رسائل تحاول تجربتها ، لكنها لا تستطيع ذلك.وفي الوقت نفسه ، طارت نفس إشارة الإغلاق الفوري إلى المعلم القديم. بدأ المعالج في إعادة تشغيل الطوارئ ، كما يتوقف الاسترداد. لا يمكن الاتصال بالنسخة المتماثلة لأنها في وضع إيقاف التشغيل.14:49:34.293 [idle] LOG: received replication command: IDENTIFY_SYSTEM
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
14:49:35.232 FATAL: could not receive data from WAL stream: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
14:49:35.232 LOG: record with incorrect prev-link 142D46/315602C at 14CF/CF38C160
14:49:35.305 FATAL: could not connect to the primary server: FATAL: the database system is shutting down
14:49:40.241 FATAL: could not connect to the primary server: FATAL: the database system is shutting down
في مرحلة ما ، عملت النسخة المتماثلة ، ولكن لم يبدأ النسخ المتماثل.14:50:14.024 [] LOG: record with incorrect prev-link 142D46/315602C at 14CF/CF38C160
14:50:14.028 [] LOG: fetching timeline history file for timeline 72 from primary server
14:50:14.104 [] FATAL: could not start WAL streaming: ERROR: requested starting point 14CF/CF000000 on timeline 71 is not in this server's history
DETAIL: This server's history forked from timeline 71 at 14CF/CEC32E40.
14:50:14.104 [] LOG: new timeline 72 forked off current database system timeline 71 before current recovery point 14CF/CF38C160
لدي فرضية واحدة: في Recovery.conf كان عنوان السيد القديم. عندما ظهر سيد جديد بالفعل ، حاولت النسخة المتماثلة الثانية الاتصال بالسيد القديم. عندما بدأت Patroni في النسخة المتماثلة الثانية ، بدأت العقدة ، لكنها لم تتمكن من الاتصال عبر النسخ المتماثل. تم تشكيل تأخر في التكرار يشبه شيئًا كهذا:+-----------------+----------+--------------+--------+---------+-----------+
| Cluster | Member | Host | Role | State | Lag in MB |
+-----------------+----------+--------------+--------+---------+-----------+
| patroni_cluster | pgsql01 | 10.2.200.151 | Leader | running | 0.0 |
| patroni_cluster | pgsql02 | 10.2.200.152 | | running | 9153.0 |
| patroni_cluster | pgsql03 | 10.2.200.153 | | running | 0.0 |
+-----------------+----------+--------------+--------+---------+-----------+
أي أن العقد الثلاث كانت في مكانها ، ولكن العقدة الثانية كانت في الخلف. تعذر بدء النسخ المتماثل لأن سجلات المعاملات كانت مختلفة. سجلات المعاملات التي يقدمها المعالج ، المشار إليها في recovery.conf ، ببساطة لا تتناسب مع العقدة الحالية. أبلغت PostgreSQL عن خطأ كل 5 ثوانٍ14:50:44.143 FATAL: could not start WAL streaming: ERROR: requested starting point 14CF/CF000000 on timeline 71 is not in this server's history
DETAIL: This server's history forked from timeline 71 at 14CF/CEC32E40.
14:50:44.143 LOG: new timeline 72 forked off current database system timeline 71 before current recovery point 14CF/ CF38C160
لقد ارتكبت هنا خطأ ولم أختبر فرضيتي بأننا نتصل بالسيد الخطأ. لقد قمت بإعادة تشغيل Patroni على النسخة المتماثلة. بصراحة ، لقد قمت بالفعل بوضع حد لها واعتقدت أنني سأضطر إلى إعادة ذلك ، لكنني ما زلت قررت إعادة تشغيله.15:14:13.511 LOG: consistent recovery state reached at 14CF/A3F657B0
15:14:13.511 LOG: database system is ready to accept read only connections
بدأ الاسترداد ، وحتى فتح قاعدة البيانات ، كانت جاهزة لقبول الاتصال ، وبدأ النسخ المتماثل:15:14:17.072 LOG: record with incorrect prev-link 142D46/315602C at 14CF/CF38C160
15:14:17.077 LOG: started streaming WAL from primary at 14CF/CF000000 on timeline 72
15:14:17.536 LOG: invalid record length at 14CF/CF38C160: wanted 24, got 1
ولكن بعد دقيقة واحدة ، وقعت في خطأ terminating walreceiver process due to administrator command- قالت النسخة المتماثلة أن سجلات المعاملات لم تكن مناسبة لها.15:15:27.823 FATAL: terminating walreceiver process due to administrator command
15:15:27.895 LOG: invalid record length at 14CF/CF38C160: wanted 24, got 1
15:15:27.895 LOG: invalid record length at 14CF/CF38C160: wanted 24, got 1
ولم أعد تشغيل PostgreSQL ، ولكن تم إعادة تشغيل Patroni على أمل أن يتم تشغيل قاعدة البيانات بطريقة سحرية. بدأ النسخ المتماثل مرة أخرى ، ولكن تم فتح قاعدة البيانات في نفس المكان:15:17:33.553 LOG: consistent recovery state reached at 14CF/A3F657B0
15:17:33.554 LOG: database system is ready to accept read only connections
كانت العلامات في سجل المعاملات مختلفة ، وكانت مختلفة عما كانت عليه في محاولة الإطلاق السابقة - وكان موضع سجل المعاملات سابقًا:15:17:37.299 LOG: invalid contrecord length 5913 at 14CF/CEFFF7B0
15:17:37.304 LOG: started streaming WAL from primary at 14CF/CE000000 on timeline 72
توقف النسخ المتماثل مرة أخرى ، وكانت رسالة الخطأ مختلفة ومرة أخرى ليست مفيدة للغاية:15:18:12.208 FATAL: terminating walreceiver process due to administrator command
15:18:12.240 LOG: record with incorrect prev-link 60995000/589DF000 at 14CF/CEFFF7B0
15:18:12.240 LOG: record with incorrect prev-link 60995000/589DF000 at 14CF/CEFFF7B0
للتجربة ، أعيد تشغيلها مرة أخرى ، تم فتح القاعدة في نفس المكان:15:21:25.135 LOG: consistent recovery state reached at 14CF/A3F657B0
15:21:25.135 LOG: database system is ready to accept read only connections
ثم جاءتني الفكرة: إذا قمت بإعادة تشغيل PostgreSQL ، في هذه المرحلة على المعالج الحالي ، سأقوم بنقطة تفتيش لنقل النقطة في سجل المعاملات إلى الأمام قليلاً وبدأ الاسترداد من لحظة أخرى.أطلقت Patroni ، جعلت بضع نقاط تفتيش على الرئيسي ، بضع نقاط إعادة تشغيل على النسخة المتماثلة عند فتحها:15:22:43.727 LOG: invalid record length at 14D1/BCF3610: wanted 24, got 0
15:22:43.731 LOG: started streaming WAL from primary at 14D1/B000000 on timeline 72
نجحت - بدأ النسخ المتماثل من مكان مختلف ولم يعد ينكسر. لكن بالنسبة لي ، هذه واحدة من أكثر المشاكل الغامضة التي ما زلت أعاني منها. خصوصا أن طلب إغلاق فوري غريب.من هذا يمكننا أن نستنتج: يمكن لـ Patroni أن يعمل كما هو مخطط وبدون أخطاء ، ولكن هذا ليس ضمانًا مطلقًا بأن كل شيء في الواقع منظم. بعد faylover ، يجب عليك دائمًا التحقق جيدًا من أن كل شيء على ما يرام مع المجموعة: العدد الصحيح من النسخ المتماثلة ، ولا يوجد تأخر في النسخ المتماثل.ملخص
بناءً على هذه المشاكل وغيرها من المشكلات المماثلة ، قمت بصياغة توصيات عامة أنصحك بأن تضعها في الاعتبار عند تشغيل Patroni.- عند استخدامك Patroni ، يجب أن يكون لديك مراقبة. تحتاج دائمًا إلى معرفة وقت حدوث ملف تلقائي ، لأنه إذا كنت لا تعرف أن لديك ملفًا تلقائيًا ، فلا يمكنك التحكم في الكتلة.
- بعد كل feylover تحقق دائمًا من الكتلة. يجب التأكد من أن: النسخ المتماثلة هي دائمًا الرقم الحالي ؛ لا تأخر النسخ المتماثل ؛ لا توجد أخطاء في السجلات المتعلقة بتكرار الدفق ، مع Patroni ، مع نظام DCS.
Patroni هي أداة جيدة للغاية ، ولكن بغض النظر عن كيفية قولك أنها ليست رصاصة فضية. يمكن أن تعمل الأتمتة بنجاح ، ولكن في نفس الوقت ، يمكن أن تكون كائنات الأتمتة في حالة نصف العمل. على أي حال ، أنت بحاجة إلى فكرة عن كيفية عمل PostgreSQL والنسخ المتماثل ، وكيف يدير Patroni PostgreSQL ، وكيف يتم ضمان التفاعل بين العقد. يعد ذلك ضروريًا حتى تتمكن من إصلاح المشاكل التي تنشأ بيديك.خطوات التشخيص
حدث ذلك أننا نعمل مع عملاء مختلفين ، ومعظمهم ليس لديهم مكدس ELK ، وعليك فرز السجلات عن طريق فتح علامتي تبويب و 6 وحدات تحكم: في علامة تبويب Patroni لكل عقدة ، في الأخرى - سجلات القنصل أو PostgreSQL. من الصعب تشخيص كل هذا.لقد طورت النهج التالي. أنا دائما أشاهد وقت حدوث الفشل. بالنسبة لي إنه نوع من مستجمعات المياه. أنظر إلى ما حدث قبل وأثناء وبعد العاشق. الفشل له طابعتان زمنيتان - البداية والنهاية. في السجلات ، أنظر إلى ما سبق العاشق ، أي أنني أبحث عن أسباب. وهذا يعطي فهمًا لما حدث وما يمكن القيام به في المستقبل حتى لا يحدث العاشق في نفس الظروف.لهذا ، أنظر:- بادئ ذي بدء ، سجلات Patroni.
- PostgreSQL DCS , Patroni.
- — , .
هناك العديد من المنتجات الأخرى للملف التلقائي: stolon ، repmgr ، pg_auto_failover ، PAF. لقد جربت جميع الأدوات الأربعة وفي رأيي أن Patroni هو الأفضل في السوق اليوم.هل أوصي باترونى؟ بالتأكيد ، نعم ، لأنني أحب Patroni ، أعتقد أنني تعلمت كيفية طهيها.إذا كنت مهتمًا بالنظر في المشكلات الأخرى التي تواجه Patroni ، بالإضافة إلى تلك الموضحة في المقالة ، فيمكنك دائمًا الانتقال إلى الصفحة https://github.com/zalando/patroni/issues . هناك العديد من القصص المختلفة. على الرغم من حقيقة أن نصفهم من المستخدمين الأميين الذين يطرحون أسئلة غبية دون أن يكلفوا أنفسهم عناء البحث البسيط ، إلا أنه يتم أيضًا مناقشة المشكلات المثيرة للاهتمام هناك ، ونتيجة للمناقشات ، يتم فتح مهام إصلاح الأخطاء إذا لزم الأمر.بفضل Zalando لتطوير هذا المشروع ، وكذلك إلى الشخصين الذين بدأوا العمل على هذا المنتج: Alexander Kukushkin و Alexey Klyukin. شكرا جزيلا لجميع المساهمين في Patroni.بعد هذا التقرير ، سجلنا مقابلة قصيرة حاول فيها أليكس تضمين تقريره في مجلس واحد وأخبرنا عن سبب المشاركة والتحدث في المؤتمرات. احمل السلاح وتعال للتحقق من نهج Saint HighLoad ++.HighLoad++ 6-7 . , . , ( , ). - , , , .
Saint HighLoad++! , , PostgreSQL: , PostgreSQL JSON ; PostgreSQL 13, ; .