أثبتت PostgreSQL بالفعل قيمتها - فهي تعمل بشكل رائع وتستخدمها الشركات الرقمية العصرية مثل Alibaba و TripAdvisor ، كما أن الافتقار إلى الإتاوات يجعلها بديلاً مغريًا للوحوش مثل MS SQL أو Oracle DB. ولكن بمجرد أن نبدأ في التفكير في PostgreSQL في مشهد المؤسسة ، فإننا نواجه على الفور متطلبات صارمة: "ولكن ماذا عن التسامح مع أخطاء التكوين؟ مقاومة الكوارث؟ أين هي المراقبة الشاملة؟ ماذا عن النسخ الاحتياطية الآلية؟ ماذا عن استخدام مكتبات الأشرطة ، التخزين المباشر والثانوي؟ "
من ناحية أخرى ، لا تحتوي PostgreSQL على مرافق نسخ احتياطي مضمنة ، مثل DBMS "للبالغين" مثل RMAN أو Oracle DB أو SAP Database Backup. من ناحية أخرى ، فإن موردي أنظمة النسخ الاحتياطي للشركات (Veeam ، Veritas ، Commvault) ، على الرغم من أنهم يدعمون PostgreSQL ، إلا أنهم في الواقع يعملون فقط مع تكوين معين (مستقل عادةً) ومع مجموعة من القيود المختلفة.
تحظى أنظمة النسخ الاحتياطي المصممة خصيصًا لـ PostgreSQL ، مثل Barman و Wal-g و pg_probackup ، بشعبية كبيرة في التركيبات الصغيرة لنظام PostgreSQL DBMS أو حيث لا تكون هناك حاجة إلى نسخ احتياطية كبيرة من عناصر أخرى من مشهد تكنولوجيا المعلومات. على سبيل المثال ، بالإضافة إلى PostgreSQL ، يمكن أن تحتوي البنية التحتية على خوادم فعلية وافتراضية ، OpenShift ، Oracle ، MariaDB ، Cassandra ، إلخ. كل هذا يجب أن يتم دعمه بأداة مشتركة. إن وضع حل منفصل لـ PostgreSQL حصريًا فكرة سيئة: سيتم نسخ البيانات في مكان ما على القرص ، ومن ثم يجب إزالتها إلى شريط. يزيد هذا النسخ الاحتياطي من وقت النسخ الاحتياطي ، وأيضًا ، بشكل أكثر أهمية ، الاسترداد.
في أحد حلول المؤسسات ، يتم إجراء نسخ احتياطي لعملية التثبيت بعدد معين من العقد في مجموعة مخصصة. في الوقت نفسه ، على سبيل المثال ، لا يمكن أن يعمل Commvault إلا مع مجموعة مكونة من عقدين ، حيث يتم تعيين أساسي وثانوي بشكل صارم لعقد معينة. ومن المنطقي إجراء نسخ احتياطي باستخدام Primary فقط ، لأن النسخ الاحتياطي باستخدام Secondary له حدوده. نظرًا لخصائص نظام إدارة قواعد البيانات (DBMS) ، لا يتم إنشاء تفريغ على الثانوية ، وبالتالي تبقى فقط إمكانية النسخ الاحتياطي للملف.
للتخفيف من مخاطر وقت التوقف عن العمل ، يؤدي إنشاء نظام متسامح مع الأخطاء إلى إنشاء تكوين تجميع مباشر ، ويمكن لـ Primary الترحيل تدريجيًا بين الخوادم المختلفة. على سبيل المثال ، يقوم برنامج Patroni نفسه بتشغيل Primary على عقدة عنقودية يتم اختيارها عشوائيًا. شاروخان ليس لديه طريقة لتعقب هذا خارج الصندوق ، وإذا تغير التكوين ، تنقطع العمليات. أي أن إدخال التحكم الخارجي يمنع شاروخان من العمل بفعالية ، لأن خادم التحكم ببساطة لا يفهم أين وما هي البيانات التي يجب نسخها منها.
مشكلة أخرى هي تنفيذ النسخ الاحتياطي في Postgres. يمكن ذلك عن طريق التفريغ ، ويعمل على قواعد صغيرة. ولكن في قواعد البيانات الكبيرة ، يستغرق التفريغ وقتًا طويلاً ، ويتطلب الكثير من الموارد ويمكن أن يؤدي إلى فشل مثيل قاعدة البيانات.
يعمل النسخ الاحتياطي للملفات على تصحيح الموقف ، ولكنه بطيء في قواعد البيانات الكبيرة لأنه يعمل في وضع ترابط واحد. بالإضافة إلى ذلك ، فإن البائعين لديهم عدد من القيود الإضافية. إما أنه لا يمكنك استخدام النسخ الاحتياطية للملفات والتفريغ في نفس الوقت ، أو أن إلغاء البيانات المكررة غير مدعوم. هناك العديد من المشاكل ، وغالبًا ما يكون من الأسهل اختيار نظام DBMS باهظ الثمن ولكنه مثبت بدلاً من Postgres.
لا مكان للتراجع! خلف مطوري موسكو !
ومع ذلك ، واجه فريقنا مؤخرًا تحديًا صعبًا: في مشروع إنشاء AIS OSAGO 2.0 ، حيث أنشأنا البنية التحتية لتكنولوجيا المعلومات ، اختار مطورو النظام الجديد PostgreSQL.
من الأسهل بكثير لمطوري البرامج الكبار استخدام حلول مفتوحة المصدر "عصرية". لدى Facebook عدد كافٍ من المتخصصين لدعم عمل DBMS. وفي حالة PCA ، وقعت جميع مهام "اليوم الثاني" على عاتقنا. لقد طُلب منا توفير التسامح مع الخطأ ، وتجميع مجموعة ، وبالطبع إنشاء نسخة احتياطية. كان منطق الأفعال كما يلي:
- تعليم شاروخان لعمل نسخة احتياطية من العقدة الأساسية للكتلة. للقيام بذلك ، يجب على SRK العثور عليه ، مما يعني أنه يحتاج إلى التكامل مع حل أو آخر لإدارة مجموعة PostgreSQL. في حالة PCA ، تم استخدام برنامج Patroni لهذا الغرض.
- حدد نوع النسخة الاحتياطية بناءً على كمية البيانات ومتطلبات الاسترداد. على سبيل المثال ، عندما يكون من الضروري استعادة الصفحات بدقة ، استخدم ملف تفريغ ، وإذا كانت قواعد البيانات كبيرة ولا يلزم الاستعادة الدقيقة ، فاعمل على مستوى الملف.
- قم بإرفاق ميزة النسخ الاحتياطي للكتلة بالحل لإنشاء نسخة احتياطية متعددة الخيوط.
في الوقت نفسه ، شرعنا في البداية في إنشاء نظام فعال وبسيط بدون ربط هائل من مكونات إضافية. كلما قل عدد العكازات ، قل عبء العمل على الموظفين وانخفاض مخاطر فشل القولون العصبي. لقد استبعدنا على الفور الطرق التي استخدمت Veeam و RMAN ، لأن مجموعة من حلين تلمح بالفعل إلى عدم موثوقية النظام.
القليل من السحر للمؤسسة
لذلك ، احتجنا إلى ضمان نسخة احتياطية موثوقة لـ 10 مجموعات من 3 عقد لكل منها ، بينما تنعكس البنية التحتية نفسها في مركز بيانات النسخ الاحتياطي. تعمل مراكز البيانات في خطة PostgreSQL على مبدأ المبني للمجهول. كان المبلغ الإجمالي لقواعد البيانات 50 تيرابايت. يمكن لأي SRC على مستوى الشركة التعامل مع هذا بسهولة. لكن الفارق البسيط هو أن Postgres في البداية لم يكن لديه خطاف للتوافق الكامل والعميق مع أنظمة النسخ الاحتياطي. لذلك ، كان علينا البحث عن حل يحتوي في البداية على الحد الأقصى من الوظائف بالتزامن مع PostgreSQL ، وتعديل النظام.
أجرينا 3 "هاكاثونات" داخلية - نظرنا إلى أكثر من خمسين تطورًا واختبرناها وأجرينا تغييرات تتعلق بفرضياتنا واختبرناها مرة أخرى. بعد تحليل الخيارات المتاحة ، اخترنا Commvault. من خارج الصندوق ، يمكن أن يعمل هذا المنتج مع أبسط تثبيت PostgreSQL متفاوت ، وقد أدت هندسته المفتوحة إلى ظهور الأمل (وهو ما تحقق) في تحسين وتكامل ناجحين. يمكن لتطبيق Commvault أيضًا الاحتفاظ بنسخة احتياطية من سجلات PostgreSQL. على سبيل المثال ، يمكن لـ Veritas NetBackup في جزء PostgreSQL عمل نسخ احتياطية كاملة فقط.
تعرف على المزيد حول الهندسة المعمارية. تم تركيب وحدات خدمة إدارة Commvault في كل مركز من مركزي البيانات في تكوين CommServ HA. يتم عكس النظام وإدارته من خلال وحدة تحكم واحدة ، ومن وجهة نظر HA فإنه يلبي جميع متطلبات المؤسسة.
أطلقنا أيضًا خادمين للوسائط المادية في كل مركز بيانات ، وقمنا بتوصيل مصفوفات الأقراص ومكتبات الأشرطة المخصصة خصيصًا للنسخ الاحتياطية عبر القناة الليفية عبر SAN. ضمنت قواعد إلغاء البيانات المكررة الممتدة مرونة خوادم الوسائط ، ويضمن توصيل كل خادم بكل ملف CSV التشغيل المستمر في حالة فشل أي مكون. تسمح بنية النظام للنسخ الاحتياطي بالاستمرار حتى في حالة تعطل أحد مراكز البيانات.
يحدد Patroni عقدة أساسية لكل مجموعة. يمكن أن تكون أي عقدة مجانية في مركز البيانات - ولكن في الأساس فقط. في النسخ الاحتياطي ، تكون جميع العقد ثانوية.
لكي يفهم Commvault أي عقدة عنقودية أساسية ، قمنا بدمج النظام (بفضل البنية المفتوحة للحل) مع Postgres. للقيام بذلك ، تم إنشاء برنامج نصي يُبلغ عن الموقع الحالي للعقدة الأساسية إلى خادم إدارة Commvault.
بشكل عام ، تبدو العملية على
النحو التالي : يختار Patroni Primary → Keepalived يقوم بإحضار مجموعة IP ويقوم بتشغيل البرنامج النصي ← يتلقى وكيل Commvault على العقدة المحددة من الكتلة إشعارًا بأنه أساسي ← يقوم Commvault تلقائيًا بإعادة تكوين النسخة الاحتياطية داخل العميل الزائف.
تتمثل ميزة هذا الأسلوب في أن الحل لا يؤثر على تناسق السجلات أو صحتها أو استعادة مثيل Postgres. كما أنه قابل للتطوير بسهولة ، لأنه ليس من الضروري الآن إصلاح العقد الأساسية والثانوية لـ Commvault. يكفي أن يفهم النظام مكان وجود الأساسي ، ويمكن زيادة عدد العقد إلى أي قيمة تقريبًا.
الحل لا يدعي أنه مثالي وله الفروق الدقيقة الخاصة به. يمكن لتطبيق Commvault فقط إجراء نسخ احتياطي لمثيل كامل ، وليس قواعد البيانات الفردية. لذلك ، تم إنشاء مثيل منفصل لكل قاعدة بيانات. يتم دمج العملاء الحقيقيين في عملاء زائفين افتراضيين. كل عميل زائف Commvault عبارة عن مجموعة UNIX. يقوم بإضافة عقد المجموعة التي تم تثبيت وكيل Commvault لـ Postgres عليها. نتيجة لذلك ، يتم نسخ جميع العقد الافتراضية للعميل الزائف احتياطيًا كمثال واحد.
داخل كل عميل زائف ، يشار إلى العقدة النشطة للمجموعة. هذا ما يحدده حل التكامل الخاص بنا لـ Commvault. مبدأ تشغيله بسيط للغاية: إذا ارتفع عنوان IP للكتلة على عقدة ، يقوم البرنامج النصي بتعيين معلمة "العقدة النشطة" في ثنائي وكيل Commvault - في الواقع ، يقوم البرنامج النصي بتعيين "1" في الجزء المطلوب من الذاكرة. يرسل الوكيل هذه البيانات إلى CommServe ، ويقوم Commvault بعمل نسخة احتياطية من العقدة المطلوبة. بالإضافة إلى ذلك ، يتم التحقق من صحة التكوين على مستوى البرنامج النصي ، مما يساعد على تجنب الأخطاء عند بدء النسخ الاحتياطي.
في الوقت نفسه ، يتم نسخ قواعد البيانات الكبيرة احتياطيًا في كتلة في عدة خيوط ، مما يلبي متطلبات RPO ونوافذ النسخ الاحتياطي. العبء على النظام ضئيل: النسخ الكاملة لا تحدث كثيرًا ، في الأيام الأخرى يتم جمع السجلات فقط ، علاوة على ذلك ، خلال فترات التحميل المنخفض.
بالمناسبة ، قمنا بتطبيق سياسات منفصلة لنسخ سجلات PostgreSQL المؤرشفة احتياطيًا - يتم تخزينها وفقًا لقواعد مختلفة ، ويتم نسخها وفقًا لجدول زمني مختلف ولا يتم تمكين ميزة إلغاء البيانات المكررة لها ، نظرًا لأن هذه السجلات تحتوي على بيانات فريدة.
لضمان تناسق البنية التحتية لتكنولوجيا المعلومات بالكامل ، يتم تثبيت عملاء ملف Commvault منفصلين على كل عقد من عقد المجموعة. تستثني ملفات Postgres من النسخ الاحتياطية وهي مخصصة فقط للنسخ الاحتياطية لنظام التشغيل والتطبيقات. هذا الجزء من البيانات له أيضًا سياسته الخاصة وفترة التخزين الخاصة به.
الآن لا يؤثر SRK على الخدمات الإنتاجية ، ولكن إذا تغير الوضع ، فسيكون من الممكن تمكين نظام تحديد الحمل في Commvault.
هل هذا جيد؟ حسن!
لذلك ، لم نحصل على نسخة احتياطية قابلة للتطبيق فحسب ، بل حصلنا أيضًا على نسخة احتياطية مؤتمتة بالكامل لتثبيت PostgreSQL المجمع ، والذي يلبي جميع متطلبات مكالمات المؤسسة.
تتداخل معلمات RPO و RTO في ساعة واحدة وساعتين مع هامش ، مما يعني أن النظام سوف يطابقها حتى مع زيادة كبيرة في حجم البيانات المخزنة. على الرغم من العديد من الشكوك ، فإن PostgreSQL وبيئة المؤسسة متوافقة تمامًا. والآن نحن نعلم من تجربتنا الخاصة أن النسخ الاحتياطي لنظام إدارة قواعد البيانات هذا ممكن في مجموعة متنوعة من التكوينات.
بالطبع ، على طول الطريق ، كان علينا أن نرتدي سبعة أزواج من الأحذية الحديدية ، ونتغلب على عدد من الصعوبات ، ونقفز على بعض المكابس ونصحح عددًا من الأخطاء. ولكن الآن تم اختبار النهج بالفعل ويمكن استخدامه لتنفيذ المصدر المفتوح بدلاً من نظام إدارة قواعد البيانات (DBMS) في بيئة المؤسسة القاسية.
هل جربت PostgreSQL في بيئة مؤسسية؟
المؤلفون:
أوليج لافرينوف ، مهندس تصميم أنظمة تخزين بيانات Jet Infosystems ،
ديمتري إريكين ، مهندس تصميم أنظمة حوسبة أنظمة المعلومات النفاثة