أقترح أن تتعرف على نص تقرير بداية عام 2019 بواسطة Andrey Borodin "النسخ الاحتياطية مع WAL-G. ماذا يوجد في عام 2019؟"
أهلاً بكم! اسمي أندري بورودين. أنا مطور في Yandex. لقد كنت مهتمًا بـ PostgreSQL منذ عام 2016 ، بعد أن تحدثت إلى المطورين ، وقالوا إن كل شيء بسيط - تأخذ شفرة المصدر وتبنيها ، وسيعمل كل شيء. ومنذ ذلك الحين لا أستطيع التوقف - أكتب كل أنواع الأشياء المختلفة.
أحد الأشياء التي أقوم بها هو نظام النسخ الاحتياطي. . بشكل عام ، في Yandex ، نتعامل مع أنظمة النسخ الاحتياطي في PostgreSQL لفترة طويلة جدًا. ويمكنك أن تجد على الإنترنت سلسلة من ستة تقارير حول كيفية صنع أنظمة النسخ الاحتياطي. وكل عام يتطورون قليلاً ، ويتطورون قليلاً ، ويصبحون أكثر موثوقية.
لكن تقرير اليوم لا يتعلق فقط بما قمنا به ، بل يتعلق أيضًا بمدى بساطة كل شيء وما هو موجود. كم منكم شاهد بالفعل محادثاتي حول WAL-G؟ من الجيد أن قلة قليلة من الناس لم يشاهدوها لأنني سأبدأ بأبسط شيء.
إذا كان لديك فجأة كتلة PostgreSQL ، وأعتقد أن كل شخص لديه اثنين منهم ، وفجأة لا يوجد نظام نسخ احتياطي حتى الآن ، فأنت بحاجة إلى الحصول على أي تخزين S3 أو تخزين متوافق مع Google Cloud.
على سبيل المثال ، يمكنك القدوم إلى الكابينة الخاصة بنا والحصول على رمز ترويجي لـ Yandex Object Storage ، وهو متوافق مع S3.
ثم قم بإنشاء دلو. إنها مجرد حاوية للمعلومات.
أنشئ مستخدم الخدمة.
قم بإنشاء مفتاح وصول مستخدم الخدمة aws-s3-key.
قم بتنزيل أحدث إصدار مستقر من WAL-G.
كيف تختلف إصداراتنا المسبقة عن الإصدارات؟ كثيرًا ما يُطلب مني الإفراج مبكرًا. وإذا لم يكن هناك خطأ في الإصدار لفترة كافية ، على سبيل المثال ، شهر ، فأنا أطلق الإصدار. ها هو إصدار نوفمبر. وهذا يعني أننا وجدنا كل شهر نوعًا من الأخطاء ، عادةً في وظائف غير حرجة ، لكن حتى الآن لم نصدر أي إصدار. الإصدار السابق هو نوفمبر فقط. لايوجد به اي اخطاء معروفه لنا اي انه تم اضافة البق اثناء تطوير المشروع.
بمجرد تنزيل WAL-G ، يمكنك تشغيل أمر "قائمة نسخ احتياطي" بسيط عن طريق تمرير متغيرات البيئة. وسيتصل بـ Object Storage ويخبرك بالنسخ الاحتياطية التي لديك. في البداية ، بالطبع ، لا ينبغي أن يكون لديك نسخ احتياطية. الغرض من هذه الشريحة هو إظهار أن كل شيء بسيط للغاية. هذا هو أمر وحدة تحكم يقبل متغيرات البيئة وينفذ الأوامر الفرعية.
بعد ذلك ، يمكنك عمل النسخة الاحتياطية الأولى. قل "دفع احتياطي" في WAL-G وأشر WAL-G إلى موقع بيانات pgdata الخاصة بالعنقود. وعلى الأرجح ستخبرك PostgreSQL إذا لم يكن لديك بالفعل نظام نسخ احتياطي تحتاجه لتمكين "وضع الأرشفة".
هذا يعني الدخول في الإعدادات وتشغيل "archive_mode = on" وإضافة "archive_command" وهو بالضبط نفس الأمر الفرعي في WAL-G. ولكن في هذا الموضوع ، غالبًا ما يستخدم الأشخاص لسبب ما البرامج النصية الشريطية ويقومون بعمل ارتباط حول WAL-G. من فضلك لا تفعل هذا. استخدم الوظيفة الموجودة في WAL-G. إذا كنت تفتقد شيئًا ما ، فاكتب إلى . يفترض WAL-G أنه البرنامج الوحيد الذي يعمل على archive_command.
نحن نستخدم WAL-G بشكل أساسي لإنشاء مجموعة عالية الإتاحة في إدارة قاعدة بيانات Yandex.
وعادة ما تستخدم في طوبولوجيا ماستر واحد وعدة مكررات. في الوقت نفسه ، يقوم بعمل نسخة احتياطية في Yandex Object Storage.
أكثر السيناريوهات شيوعًا هي إنشاء نسخ عنقودية باستخدام نقطة في استعادة الوقت. لكن في هذه الحالة ، فإن أداء نظام النسخ الاحتياطي ليس مهمًا جدًا بالنسبة لنا. نحتاج فقط إلى صب كتلة جديدة من النسخة الاحتياطية.
عادة ، نحتاج إلى أداء نظام النسخ الاحتياطي عند إضافة عقدة جديدة. لماذا هو مهم؟ عادةً ما يضيف الأشخاص عقدة جديدة إلى مجموعة لأن الكتلة الحالية لا يمكنها التعامل مع حمل القراءة. يحتاجون إلى إضافة نسخة متماثلة جديدة. إذا أضفنا حمولة من pg_basebackup إلى Master ، فيمكن للسيد أن يضيف ما يصل. لذلك ، كان من المهم جدًا بالنسبة لنا أن نتمكن من صب عقدة جديدة بسرعة من الأرشيف ، مما يخلق حدًا أدنى من الحمل على Master.
وحالة أخرى مماثلة. هذه هي الحاجة إلى إعادة تحميل Master القديم بعد تبديل Master الكتلة من مركز البيانات الذي فقد الاتصال به.
- نتيجة لذلك ، عند صياغة متطلبات نظام النسخ الاحتياطي ، أدركنا أن pg_basebackup غير مناسب لنا عند العمل في السحابة.
- أردنا أن نكون قادرين على ضغط بياناتنا. لكن أي نظام نسخ احتياطي تقريبًا سيوفر ضغط البيانات ، باستثناء ما هو موجود في الصندوق.
- أردنا موازنة كل شيء ، لأن المستخدم في السحابة يشتري عددًا كبيرًا من نوى المعالج. ولكن إذا لم يكن لدينا توازي في عملية ما ، فإن عددًا كبيرًا من النوى يصبح عديم الفائدة.
- نحتاج إلى التشفير لأنه غالبًا لا تكون هذه بياناتنا ولا يمكن تخزينها بشكل واضح. بالمناسبة ، بدأت مساهمتنا في WAL-G بالتشفير. أكملنا التشفير في WAL-G ، وبعد ذلك سئلنا: "ربما سيقوم أحدنا بتطوير المشروع؟". ومنذ ذلك الحين أعمل مع WAL-G منذ أكثر من عام.
- لقد احتجنا أيضًا إلى تقييد الموارد ، لأنه بمرور وقت التشغيل السحابي ، اكتشفنا أنه في بعض الأحيان يكون لدى الأشخاص حمولة كبيرة من البقالة في الليل ولا ينبغي التدخل في هذا الحمل. لذلك ، أضفنا تقييد الموارد.
- وكذلك الإدراج والإدارة.
- والتحقق.
لقد قمنا بتغطية العديد من الأدوات المختلفة. لحسن الحظ ، لدينا مجموعة كبيرة من الخيارات في PostgreSQL. وفي كل مكان كنا نفتقد شيئًا ما ، ميزة واحدة صغيرة ، وميزة واحدة صغيرة.
وبعد النظر في الأنظمة الحالية ، توصلنا إلى حقيقة أننا سنطور WAL-G. ثم كان مشروعًا جديدًا. كان من السهل جدًا التأثير على التطوير نحو البنية التحتية السحابية لنظام النسخ الاحتياطي.
الأيديولوجية الرئيسية التي نلتزم بها هي أن WAL-G يجب أن يكون بسيطًا مثل balalaika.
توجد 4 أوامر في WAL-G. هذا:
WAL-PUSH - أرشفة العمود.
WAL-FETCH - احصل على عمود.
BACKUP-PUSH - قم بعمل نسخة احتياطية.
إحضار النسخ الاحتياطي - احصل على نسخة احتياطية من نظام النسخ الاحتياطي.
في الواقع ، يمتلك WAL-G أيضًا إدارة هذه النسخ الاحتياطية ، أي سرد وحذف الأعمدة والنسخ الاحتياطية في السجل ، والتي لم تعد مطلوبة في الوقت الحالي.
إحدى الوظائف المهمة بالنسبة لنا هي وظيفة إنشاء نسخ دلتا.
تعني نسخ دلتا أننا لا نقوم بإنشاء نسخة احتياطية كاملة للمجموعة بأكملها ، ولكن يتم إجراء الصفحات المعدلة فقط من الملفات المعدلة في المجموعة. يبدو أن هذا من الناحية الوظيفية مشابه جدًا للقدرة على التعافي باستخدام WAL. لكن WAL- أحادي الخيط ، دلتا النسخ الاحتياطي ، يمكننا أن نتدحرج بالتوازي. وفقًا لذلك ، عندما يكون لدينا نسخة احتياطية أساسية يتم إجراؤها يوم السبت ، تكون نُسخ دلتا الاحتياطية يوميًا ، ويوم الخميس نفشل ، ثم نحتاج إلى تجميع 4 نسخ احتياطية دلتا و 10 ساعات من WAL. سيستغرق الأمر نفس الوقت تقريبًا ، لأن النسخ الاحتياطية للدلتا تدور بالتوازي.
دلتا المستندة إلى LSN - وهذا يعني أنه عند إنشاء نسخة احتياطية ، سنحتاج إلى دمج كل صفحة والتحقق من LSN الخاص بها مع LSN للنسخة الاحتياطية السابقة لفهم أنه قد تغير. يجب أن تكون أي صفحة قد تحتوي على بيانات معدلة موجودة في النسخة الاحتياطية لدلتا.
كما قلت ، تم إيلاء الكثير من الاهتمام للتوازي.
لكن واجهة برمجة تطبيقات الأرشيف في PostgreSQL متسقة. تقوم PostgreSQL بأرشفة ملف WAL واحد وتطلب ملف WAL واحدًا عند الاستعادة. ولكن عندما تطلب قاعدة البيانات ملف WAL واحدًا باستخدام الأمر WAL-FETCH ، فإننا نستدعي الأمر WAL-PREFETCH ، والذي يعد 8 أعمدة أخرى لجلب البيانات من مخزن العناصر بالتوازي.
وعندما تطلب منا قاعدة البيانات أرشفة عمود واحد ، فإننا نبحث في archive_status ونرى ما إذا كان هناك أي ملفات WAL أخرى. ونحاول تحميل WAL بالتوازي أيضًا. يؤدي هذا إلى زيادة كبيرة في الأداء ، مما يقلل بشكل كبير من المسافة في عدد WALs غير المؤرشفة. يشعر العديد من مطوري أنظمة النسخ الاحتياطي أن هذا نظام محفوف بالمخاطر لأننا نعتمد على معرفتنا بالجزء الداخلي من الكود الذي لا يمثل PostgreSQL API. لا تضمن PostgreSQL وجود مجلد archive_status ولا تضمن الدلالات ووجود إشارات جاهزة لملفات WAL هناك. ومع ذلك ، فإننا ندرس الكود المصدري ، ونرى أن الأمر كذلك ونحاول استغلاله. ونحن نتحكم في الاتجاه الذي تتطور فيه PostgreSQL ، إذا تعطلت هذه الآلية فجأة ، فسنتوقف عن استخدامها.
في أنقى صورها ، تتطلب دلتا WAL المستندة إلى LSN قراءة أي ملف مجموعة تم تغيير وقت الوضع في نظام الملفات منذ النسخ الاحتياطي السابق. لقد عشنا معها لفترة طويلة ، تقريبًا عام. وفي النهاية ، توصلنا إلى استنتاج مفاده أن لدينا دلتا WAL.
هذا يعني أنه في كل مرة نقوم فيها بأرشفة WAL على Master ، لا نقوم فقط بضغطه وتشفيره وإرساله إلى الشبكة ، بل نقرأه أيضًا في نفس الوقت. نحن نحلل ونقرأ السجلات فيه. نحن نفهم الكتل التي تغيرت ونجمع ملفات دلتا.
يصف ملف دلتا نطاقًا من ملفات WAL ، ويصف معلومات حول الكتل التي تم تغييرها في نطاق WAL هذا. ثم يتم أرشفة ملفات دلتا هذه أيضًا.
نحن هنا نواجه حقيقة أننا قمنا بموازاة كل شيء بسرعة كبيرة ، لكن لا يمكننا قراءة التاريخ المتسلسل بالتوازي ، لأنه في جزء معين ، قد نلتقي بنهاية سجل WAL السابق ، والذي ليس لدينا حتى الآن ما نطابقه ، لأن القراءة المتوازية أدت إلى ذلك ، فإننا نحلل أولاً المستقبل ، الذي ليس له ماضٍ بعد.
نتيجة لذلك ، كان علينا وضع أجزاء غير مفهومة في ملفات جزئية. نتيجة لذلك ، عندما نعود إلى الماضي ، سنلصق قطع سجل WAL في واحد ، وبعد ذلك سنحلله ونفهم ما تغير فيه.
إذا تم تشكيل نقطة واحدة على الأقل في تاريخ تحليل العمود حيث لا نفهم ما حدث ، فحينئذٍ ، في النسخة الاحتياطية التالية ، سيتعين علينا قراءة المجموعة بأكملها مرة أخرى ، تمامًا كما فعلنا مع LSN المعتاد على أساس دلتا.
نتيجة لذلك ، أدت كل معاناتنا إلى حقيقة أننا أفرطنا في فتح مكتبة الإعراب WAL-G. على حد علمي ، لا أحد يستخدمه بعد ، ولكن إذا أراد أي شخص أن يكتبه ويستخدمه ، فهو في المجال العام. (رابط محدث )
نتيجة لذلك ، تبدو جميع تدفقات المعلومات معقدة نوعًا ما. يقوم سيدنا بأرشفة العمود وأرشفة ملفات دلتا. والنسخة المتماثلة التي تقوم بعمل نسخة احتياطية يجب أن تتلقى ملفات دلتا للوقت المنقضي بين النسخ الاحتياطية. في الوقت نفسه ، يجب استلام أجزاء من القصة بكميات كبيرة وتحليلها ، لأنه لا تتناسب القصة بأكملها مع أجزاء كبيرة. وفقط بعد ذلك ، يمكن للنسخة المتماثلة أرشفة نسخة احتياطية كاملة من دلتا.
على المخططات ، كل شيء يبدو أبسط بكثير. هذا التمهيد من إحدى مجموعاتنا الحقيقية. لدينا أساس LSN ، صنع في يوم واحد. ونلاحظ أن نسخة دلتا الاحتياطية القائمة على شبكة LSN انتقلت من الثالثة صباحًا إلى الخامسة صباحًا. هذا هو الحمل في عدد نوى المعالج. استغرقنا هنا WAL-delta حوالي 20 دقيقة ، أي أنه أصبح أسرع بكثير ، ولكن في نفس الوقت كان هناك تبادل مكثف عبر الشبكة.
نظرًا لأن لدينا معلومات حول الكتل التي تم تغييرها وفي أي وقت في تاريخ قاعدة البيانات ، فقد تقدمنا وقررنا دمج الوظيفة - امتداد PostgreSQL يسمى "pg_prefaulter"
هذا يعني أنه عندما تصدر قاعدة الاستعداد أمر استعادة ، فإنها تخبر WAL-G بإحضار ملف WAL التالي. نحن نتفهم تقريبًا البيانات التي تحظر عملية استرداد WAL التي ستصل إليها في المستقبل القريب وبدء عملية قراءة على هذه الكتل. يتم ذلك من أجل تحسين أداء وحدات تحكم SSD. لأن تمرير WAL سيصل إلى الصفحة التي تحتاج إلى تغيير. هذه الصفحة موجودة على القرص وليست في ذاكرة التخزين المؤقت للصفحة. وسوف ينتظر بشكل متزامن وصول هذه الصفحة. ولكن بجانبه يوجد WAL-G ، الذي يعرف أنه في بضع مئات من الميجابايت القادمة من WAL سنحتاج إلى صفحات معينة وفي نفس الوقت نبدأ في تسخينها. يبدأ العديد من عمليات الوصول إلى القرص بحيث يتم إجراؤها بالتوازي. يعمل هذا بشكل جيد على محركات أقراص SSD ، ولكن ، لسوء الحظ ، لا ينطبق هذا مطلقًا على محرك الأقراص الثابتة ، لأننا نتدخل فيه فقط من خلال تلميحاتنا.
هذا ما هو موجود في الكود الآن.
هناك ميزات نود أن نضيفها.
في هذه الصورة ، يمكنك أن ترى أن دلتا WAL تستغرق وقتًا قصيرًا نسبيًا. وهذه قراءة للتغييرات التي حدثت في قاعدة البيانات خلال النهار. يمكننا عمل WAL-delta ليس فقط في الليل ، لأنه لم يعد مصدرًا مهمًا للحمل. يمكننا قراءة WAL-delta كل دقيقة لأنها رخيصة. في دقيقة واحدة ، يمكننا مسح جميع التغييرات التي حدثت للكتلة. ويمكن أن يسمى هذا "دلتا WAL الفوري".
خلاصة القول هي أنه عندما نستعيد الكتلة ، قلل عدد القصص التي يجب أن نلفها بالتتابع. وهذا يعني أنه يجب تقليل مقدار WAL الذي تقدمه PostgreSQL ، لأنه يستغرق وقتًا طويلاً.
لكن هذا ليس كل شيء. إذا علمنا أنه سيتم تغيير بعض الكتلة قبل نقطة الاتساق الاحتياطية ، فلا يمكننا تغييرها في الماضي. هذا هو ، لدينا الآن تحسين WAL-delta لفة إلى الأمام ملفًا تلو الآخر. هذا يعني أنه إذا تم ، على سبيل المثال ، يوم الثلاثاء ، حذف بعض الجداول تمامًا أو تم حذف بعض الملفات تمامًا من الجدول ، فعند طرح دلتا يوم الاثنين واستعادة pg_basebackup يوم السبت ، فلن نقوم بإنشاء هذه البيانات.
نريد توسيع هذه التقنية إلى مستوى الصفحة. أي ، إذا تغير جزء من الملف يوم الاثنين ، ولكن سيتم الكتابة فوقه يوم الأربعاء ، فعند استعادة نقطة ما يوم الخميس ، لا نحتاج إلى كتابة الإصدارات القليلة الأولى من الصفحات على القرص.
لكن لا تزال هذه فكرة تتم مناقشتها بنشاط داخلنا ، لكن الكود لم يتم الوصول إليه بعد.
نريد أن نجعل ميزة أخرى في WAL-G. نريد أن نجعله قابلاً للتوسعة لأننا نحتاج إلى دعم قواعد بيانات مختلفة ونود أن نكون قادرين على التعامل مع إدارة النسخ الاحتياطي بنفس الطريقة. لكن المشكلة تكمن في اختلاف واجهات برمجة تطبيقات MySQL اختلافًا جذريًا. لا يعتمد PITR الخاص بـ MySQL على سجل WAL المادي ، ولكن على binlog. وليس لدينا نظام أرشفة في MySQL يخبر بعض الأنظمة الخارجية أن هذا binlog قد انتهى وأنه بحاجة إلى أرشفة. نحن بحاجة للوقوف في مكان ما في كرون مع القاعدة ومعرفة ما إذا كان هناك شيء جاهز؟
وبنفس الطريقة ، أثناء استعادة MySQL ، لا يوجد أمر استعادة يمكن أن يخبر النظام أنني بحاجة إلى ملفات كذا وكذا. قبل أن تبدأ في استعادة مجموعة ، تحتاج إلى معرفة الملفات التي تحتاجها. أنت نفسك بحاجة إلى تخمين الملفات التي تحتاجها. لكن هذه المشاكل ، ربما ، يمكن التحايل عليها بطريقة ما. (توضيح: MySQL مدعومة بالفعل)
في التقرير ، أردت أيضًا التحدث عن تلك الحالات التي لا يكون فيها WAL-G مناسبًا لك.
إذا لم يكن لديك نسخة متماثلة متزامنة ، لا يضمن WAL-G حفظ الخطوة الأخيرة. وإذا تأخرت عملية الأرشفة عن الأجزاء القليلة الماضية من التاريخ ، فهذه مخاطرة. في حالة عدم وجود نسخة متماثلة متزامنة ، لا أوصي باستخدام WAL-G. ومع ذلك ، فهو مصمم بشكل أساسي للتثبيت السحابي ، مما يعني وجود حل عالي التوفر مع نسخة متماثلة متزامنة ، وهي المسؤولة عن سلامة البايتات الأخيرة الملتزم بها.
غالبًا ما أرى أشخاصًا يحاولون استغلال كل من WAL-G و WAL-E في نفس الوقت. نحن ندعم التوافق مع الإصدارات السابقة بمعنى أن WAL-G يمكنه استعادة عمود من WAL-E ويمكنه استعادة نسخة احتياطية تم إجراؤها في WAL-E. ولكن نظرًا لأن كلا النظامين يستخدم نظام wal-push المتوازي ، فإنهما يبدأان في سرقة الملفات من بعضهما البعض. إذا قمنا بإصلاحه في WAL-G ، فسيظل في WAL-E. في WAL-E ، يبحث في حالة الأرشيف ، ويرى الملفات النهائية ، ويؤرشفها ، بينما الأنظمة الأخرى ببساطة لا تعرف أن ملف WAL هذا موجود ، لأن PostgreSQL لن تحاول أرشفته مرة أخرى.
ما الذي نصلحه هنا على جانب WAL-G؟ لن نخبر PostgreSQL أن هذا الملف قد تم إزالته بالتوازي ، وعندما تطلب منا PostgreSQL أرشفته ، سنعرف بالفعل أن مثل هذا الملف الذي يحتوي على وقت الوضع هذا ومع مثل هذا md5 قد تمت أرشفته بالفعل ونقول فقط لـ PostgreSQL - حسنًا ، كل شيء جاهز ، في الواقع ، دون فعل أي شيء.
ولكن من جانب WAL-E ، من غير المرجح أن يتم إصلاح هذه المشكلة ، لذلك من المستحيل عمل أمر أرشيف يقوم بأرشفة الملف في كل من WAL-G و WAL-E.
بالإضافة إلى ذلك ، هناك حالات لا يكون فيها WAL-G مناسبًا لك الآن ، لكننا سنصلحها بالتأكيد.
أولاً ، ليس لدينا حاليًا التحقق من النسخ الاحتياطي المضمّن. ليس لدينا التحقق سواء أثناء النسخ الاحتياطي أو أثناء الاسترداد. بالطبع ، يتم تنفيذ ذلك في السحابة. ولكن يتم تنفيذ ذلك ببساطة عن طريق الفحص المسبق ، ببساطة عن طريق استعادة الكتلة. سيكون من المستحسن إعطاء هذه الوظيفة للمستخدمين. ولكن عند التحقق ، أعتقد أن WAL-G سيكون قادرًا على استعادة المجموعة وبدء تشغيلها وتشغيل اختبارات الدخان: pg_dumpall to / dev / null و amcheck للتحقق من الفهارس.
لا توجد طريقة حاليًا في WAL-G لتأجيل نسخة احتياطية واحدة من WAL. وهذا يعني أننا ندعم بعض النوافذ. على سبيل المثال ، الاحتفاظ بآخر سبعة أيام ، الاحتفاظ بآخر عشر نسخ احتياطية ، الاحتفاظ بآخر ثلاث نسخ احتياطية كاملة. في كثير من الأحيان ، يأتي الناس ويقولون: "نحتاج إلى نسخة احتياطية مما حدث في يوم رأس السنة الجديدة ونريد الاحتفاظ به إلى الأبد". لا يعرف WAL-G بعد كيفية القيام بذلك. (ملاحظة - تم إصلاح هذا بالفعل. مزيد من التفاصيل - خيار علامة النسخ الاحتياطي في )
وليس لدينا فحوصات المجموع الاختباري للصفحة وفحوصات سلامة جميع مقاطع العمود أثناء التحقق من صحة PITR.
من كل هذا ، قمت بعمل مشروع لـ Google Summer of Code. إذا كنت تعرف الطلاب الأذكياء الذين يرغبون في كتابة شيء ما في Go والحصول على عدة آلاف من الدولارات من شركة واحدة بالحرف "G" ، فقم بتوصية مشروعنا لهم. سأوجه هذا المشروع ، يمكنهم القيام به. إذا لم يكن هناك طلاب ، فسوف آخذها وأفعلها بنفسي في الصيف.
ولدينا العديد من المشاكل الصغيرة الأخرى التي نعمل على حلها تدريجياً. وتحدث بعض الأشياء الغريبة.
على سبيل المثال ، إذا أعطيت نسخة احتياطية فارغة في WAL-G ، فسوف تسقط ببساطة. على سبيل المثال ، إذا أخبرته أنك بحاجة إلى عمل نسخة احتياطية من مجلد فارغ. لن يكون هناك ملف pg_control. وسيعتقد أنه لا يفهم شيئًا. نظريًا ، في هذه الحالة ، تحتاج إلى كتابة رسالة عادية للمستخدم لتشرح له كيفية استخدام الأداة. لكن هذه ليست حتى سمة من سمات البرمجة ، ولكنها ميزة للغة واضحة جيدة.
لا نعرف كيفية عمل نسخة احتياطية في وضع عدم الاتصال. إذا كانت القاعدة تكمن ، فلا يمكننا دعمها. ولكن هنا كل شيء بسيط للغاية. نقوم بتسمية النسخ الاحتياطية بواسطة LSN عندما بدأت. يجب قراءة LSN للقاعدة الأساسية من ملف التحكم. وهذه ميزة غير محققة. العديد من أنظمة النسخ الاحتياطي قادرة على عمل نسخة احتياطية من قاعدة بيانات كاذبة. وهي مريحة.
لا نقوم حاليًا بمعالجة نقص مساحة النسخ الاحتياطي بشكل طبيعي. لأننا نعمل عادة بنسخ احتياطية كبيرة في المنزل. ولم تصل الأيدي إلى هذه النقطة. ولكن إذا أراد شخص ما البرمجة في Go الآن ، فأضف معالجة خطأ خارج المجموعة. سأقوم بالتأكيد بفحص طلب السحب.
والشيء الأكثر أهمية الذي يقلقنا هو أننا نريد أكبر عدد ممكن من اختبارات تكامل عمال الرصيف التي تختبر سيناريوهات مختلفة. الآن نحن نختبر السيناريوهات الأساسية فقط. في كل التزام ، لكننا نريد التحقق من جميع الوظائف التي ندعمها لكل التزام. على وجه الخصوص ، على سبيل المثال ، سيكون لدينا دعم كافٍ لـ PostgreSQL 9.4-9.5. نحن ندعمهم لأن المجتمع يدعم PostgreSQL ، لكننا لا نتحقق من كل التزام للتأكد من عدم تعطله. وأعتقد أنها مخاطرة جدية.
يعمل WAL-G لصالحنا على أكثر من ألف مجموعة في إدارة قاعدة بيانات Yandex. وتقوم كل يوم بعمل نسخة احتياطية من عدة مئات من التيرابايت من البيانات.
لدينا الكثير من المهام في التعليمات البرمجية الخاصة بنا. إذا كنت ترغب في البرمجة ، تعال ، نحن في انتظار طلب سحب ، نحن في انتظار الأسئلة.
الأسئلة
مساء الخير! شكرًا لك! تخميني هو أنك إذا كنت تستخدم WAL-delta ، فمن المحتمل أنك تعتمد بشكل كبير على كتابة صفحة كاملة. وإذا كان الأمر كذلك ، فهل اختبرت؟ لقد أظهرت رسم بياني جميل. إلى أي مدى يصبح أجمل إذا تم إيقاف تشغيل FPW؟
لقد تم تمكين عمليات الكتابة بملء الصفحة ، ولم نحاول إيقاف تشغيلها. وهذا يعني أنني ، بصفتي مطورًا ، لم أحاول إيقاف تشغيله. من المحتمل أن يكون مسؤولو النظام الذين قاموا بالبحث قد بحثوا في هذه المشكلة. لكننا نحتاج FPW. لا أحد تقريبًا يقوم بإيقاف تشغيله ، وإلا فإنه من المستحيل أخذ نسخة احتياطية من النسخة المتماثلة.
شكرا على التقرير! لدي سؤالان. السؤال الأول هو ماذا سيحدث للطاولات؟
نحن في انتظار طلب سحب. تعيش قواعد بياناتنا على أقراص SSD و NMVE ولا نحتاج حقًا إلى هذه الميزة. الآن لست مستعدًا لقضاء وقت جاد في القيام بذلك بشكل جيد. أنا أؤيد هذا كله. هناك أشخاص أيدوها ، لكنهم دعموها بالطريقة التي تناسبهم. لقد تفرعوا ، لكن لا تقدموا طلب سحب. (أضيف في الإصدار 0.2.13)
والسؤال الثاني. لقد قلت في البداية أن WAL-G تفترض أنه يعمل بمفرده وأن الأغلفة ليست ضرورية. أنا أستخدم الأغلفة بنفسي. لماذا لا يتم استخدامها؟
نريدها أن تكون بسيطة مثل بالاليكا. هذا يعني أنك لست بحاجة إلى أي شيء على الإطلاق ، باستثناء البلاليكا. نريد أن يكون النظام بسيطًا. إذا كانت لديك وظيفة تحتاج إلى إنشائها في نص برمجي ، فتعال وأخبرنا - سنفعل ذلك في Go.
مساء الخير! شكرا على التقرير! لم نتمكن من جعل WAL-G يعمل مع فك تشفير GPG. يشفر بشكل طبيعي ، لا يريد فك التشفير. هل هناك شيء لم ينجح بالنسبة لنا؟ الوضع محبط.
قم بإنشاء مشكلة على GitHub ، فلنكتشفها.
هذا هو ، هل واجهت هذا؟
هناك ميزة للإبلاغ عن الخطأ أنه عندما لا يفهم WAL-G ماهية الملف ، فإنه يسأل ، "ربما يكون مشفرًا؟". ربما لا تكمن المشكلة في التشفير على الإطلاق. أريد أن أصلح التسجيل في هذا الموضوع. يجب أن يفك. نحن نعمل حاليًا على هذا الموضوع بمعنى أننا لا نحب حقًا كيفية تنظيم نظام الحصول على المفاتيح العامة والخاصة. لأننا نسمي GPG خارجي بحيث يعطينا مفاتيحه. ثم نأخذ هذه المفاتيح ونمررها إلى GPG الداخلي ، وهو PGP المفتوح ، والذي يتم تجميعه لنا داخل WAL-G ، ونطلق عليه التشفير هناك. في هذا الصدد ، نريد تحسين النظام ونريد دعم تشفير Libsodium (مضاف في الإصدار 0.2.15). بالطبع ، يجب أن يعمل فك التشفير ، فلنكتشف ذلك - هناك حاجة إلى المزيد من الأعراض أكثر من كلمتين. يمكنك التجمع بطريقة ما في غرفة المتحدث وإلقاء نظرة على النظام. (تشفير PGP بدون GPG خارجي - v0.2.9)
مرحبًا! شكرا على التقرير! لدي سؤالان. لدي رغبة غريبة في القيام بتسجيل pg_basebackup و WAL في مزودين اثنين ، أي أريد أن أستخدم سحابة وأخرى. هل هناك طريقة للقيام بذلك؟
إنها غير موجودة الآن ، لكنها فكرة مثيرة للاهتمام.
أنا فقط لا أثق في أحد مقدمي الخدمات ، أريد أن يكون لدي مقدم آخر فقط تحسبا لذلك.
الفكرة مثيرة للاهتمام. من الناحية الفنية ، هذا ليس من الصعب تنفيذه. حتى لا تضيع الفكرة ، هل يمكنني طلب إصدار مشكلة على GitHub؟
نعم، بالطبع.
وبعد ذلك ، عندما يأتي الطلاب إلى Google Summer of Code ، سنضيفهم إلى المشروع بحيث يكون هناك المزيد من العمل ، من أجل الحصول على المزيد منهم.
والسؤال الثاني. توجد مشكلة على GitHub. أعتقد أنه مغلق بالفعل. هناك حالة من الذعر في الاستعادة. ولإلحاق الهزيمة به ، قمت بعمل مجلس منفصل. انها تكمن في الحق في القضايا. هناك أيضًا متغير يمكن أن تقوم به بيئة متغيرة في تدفق واحد. ولذا فهو يعمل ببطء شديد. ولدينا هذه المشكلة ، وحتى الآن لم يتم حلها.
تكمن المشكلة في أن التخزين (CEPH) لسبب ما يعيد تعيين الاتصال عندما نصل إليه مع الكثير من التوازي. ما الذي يمكن عمله حيال ذلك؟ يبدو منطق إعادة المحاولة هكذا. نحن نحاول تحميل الملف مرة أخرى. في مسار واحد ، لم يتم تحميل بعض الملفات لنا ، سنقوم بعمل ملف ثانٍ لجميع أولئك الذين لم يدخلوا. وطالما يتم تحميل ملف واحد على الأقل لكل عملية تكرار ، فإننا نكررها ونكررها ونكررها. انتهينا من منطق إعادة المحاولة - التراجع الأسي. لكن ليس من الواضح تمامًا ما يجب فعله بحقيقة أن الاتصال ينقطع ببساطة من جانب نظام التخزين. أي عندما نقوم بالتحميل على دفق واحد ، فإنه لا يقطع هذه الاتصالات. ما الذي يمكننا تحسينه هنا؟ لدينا اختناق في الشبكة ، يمكننا تقييد كل اتصال بعدد البايتات التي يرسلها. أما بالنسبة للباقي ، فأنا لا أعرف كيف أتعامل مع حقيقة أن تخزين الكائن لا يسمح لنا بالتنزيل أو التنزيل منه بالتوازي.
لا يوجد جيش تحرير السودان؟ ولم يكتب فيهم كيف يسمحون لأنفسهم بالتعذيب؟
خلاصة القول هي أن الأشخاص الذين يطرحون هذا السؤال عادة ما يكون لديهم مستودع خاص بهم. أي ، لا أحد يأتي من Amazon أو Google Cloud أو Yandex Object Storage.
ربما السؤال ليس لك؟
السؤال هنا في هذه الحالة ليس مهمًا لمن. إذا كانت هناك أية أفكار حول كيفية التعامل مع هذا ، فلنقم بذلك في WAL-G. لكن حتى الآن ليس لدي أفكار جيدة حول كيفية التعامل معها. هناك بعض وحدات تخزين الكائنات التي تدعم إدراج النسخ الاحتياطية بشكل مختلف. تطلب منهم سرد الكائنات ، ويضيفون مجلدًا آخر هناك. يشعر WAL-G بالخوف في نفس الوقت - هناك شيء ما هنا ليس ملفًا ، ولا يمكنني استعادته ، مما يعني أنه لم تتم استعادة النسخة الاحتياطية. هذا ، في الواقع ، لديك مجموعة مستعادة بالكامل ، لكنها تعيد لك حالة خاطئة ، لأن تخزين الكائنات أعاد بعض المعلومات الغريبة التي لم يفهمها تمامًا.
يظهر مثل هذا الشيء في سحابة البريد.
إذا كان من الممكن بناء نسخة ...
إنه قابل للتكرار باستمرار ...
إذا كان هناك إعادة إنتاج ، فأعتقد أننا سنجرب استراتيجيات إعادة المحاولة ونكتشف كيفية إعادة المحاولة وفهم ما تتطلبه السحابة منا. ربما سيكون مستقرًا بالنسبة لنا على ثلاثة اتصالات ولن يقطع الاتصال ، ثم سنصل إلى ثلاثة اتصالات بعناية. لأننا الآن نسقط الاتصال بسرعة كبيرة ، أي إذا بدأنا الاسترداد في 16 مؤشر ترابط ، فبعد إعادة المحاولة الأولى سيكون هناك 8 خيوط و 4 خيوط و 2 خيوط وواحد. وبعد ذلك سيتم سحب الملف في دفق واحد. إذا كانت هناك بعض القيم السحرية مثل 7,5 تيارات هي الأفضل للضخ ، فسنبقى عليها ونحاول عمل 7,5 تيارات أخرى. هناك فكرة من هذا القبيل.
شكرا على التقرير! كيف يبدو سير عمل WAL-G الكامل؟ على سبيل المثال ، في حالة غبية عندما لا توجد دلتا على الصفحات. ونأخذ النسخة الاحتياطية الأولية ونزيلها ، ثم نقوم بأرشفة العمود حتى نتحول إلى اللون الأزرق. هنا ، كما أفهمها ، هناك انهيار. في مرحلة ما ، تحتاج إلى عمل نسخة احتياطية دلتا للصفحات ، أي هل هناك عملية خارجية تقودها أم كيف تحدث؟
واجهة برمجة تطبيقات دلتا للنسخ الاحتياطي بسيطة للغاية. هناك رقم هناك - خطوات دلتا القصوى ، يبدو أنه يسمى ذلك. الافتراضي هو الصفر. هذا يعني أنه في كل مرة تقوم فيها بالدفع الاحتياطي ، ستدفع نسخة احتياطية كاملة. إذا قمت بتغييره إلى أي رقم موجب ، على سبيل المثال ، إلى 3 ، ثم في المرة التالية التي تقوم فيها بالدفع الاحتياطي ، فإنه يبحث في محفوظات النسخ الاحتياطية السابقة. يرى أنك لا تتعدى سلسلة دلتا 3 وتقوم بعمل دلتا.
لذلك في كل مرة نقوم فيها بتشغيل WAL-G ، هل نحاول عمل نسخة احتياطية كاملة؟
لا ، نحن نشغل WAL-G ونحاول دلتا إذا سمحت سياساتك بذلك.
بشكل تقريبي ، إذا قمت بتشغيله من الصفر في كل مرة ، فهل سيتصرف مثل pg_basebackup؟
لا ، سيستمر العمل بشكل أسرع لأنه يستخدم الضغط والتوازي. سيضع Pg_basebackup عمودًا بجانبك. يعتمد WAL-G على حقيقة أنك قمت بتهيئة الأرشفة. وسيصدر تحذيرًا إذا لم يتم تكوينه.
يمكن تشغيل pg_basebackup بدون أعمدة.
نعم ، سوف يتصرفون بنفس الطريقة تقريبًا. نسخ pg_basebackup إلى نظام الملفات. بالمناسبة ، لدينا ميزة جديدة نسيت أن أذكرها. يمكننا الآن النسخ الاحتياطي من pg_basebackup إلى نظام الملفات. لا أعرف لماذا هو ضروري ، لكنه موجود.
على سبيل المثال ، في CephFS. لا يريد الجميع تكوين تخزين الكائنات.
نعم ، ربما هذا هو سبب طرحهم سؤالاً حول هذه الميزة حتى نتمكن من القيام بذلك. وقد صنعناها.
شكرا على التقرير! هناك سؤال فقط حول النسخ إلى نظام الملفات. من خارج الصندوق ، هل تدعم الآن النسخ إلى التخزين البعيد ، على سبيل المثال ، إذا كان هناك نوع من الرف في مركز البيانات أو أي شيء آخر؟
في هذه الصيغة ، إنه سؤال صعب. نعم ، نحن ندعمها ، ولكن لم يتم تضمين هذه الوظيفة في أي إصدار حتى الآن. أي أن جميع الإصدارات المسبقة تدعم هذا ، لكن إصدارات الإصدار لا تدعم ذلك. تمت إضافة هذه الوظيفة في الإصدار 0.2. سيكون بالتأكيد في الإصدار قريبًا ، بمجرد إصلاح جميع الأخطاء المعروفة. لكن في الوقت الحالي ، لا يمكن القيام بذلك إلا في مرحلة ما قبل الإصدار. هناك نوعان من الخلل في الإصدار التجريبي. مشكلة في استرداد WAL-E ، لم نصلح ذلك. وفي الإصدار التجريبي الأخير ، تمت إضافة خطأ حول دلتا النسخ الاحتياطي. لذلك ، نوصي الجميع باستخدام إصدارات الإصدار. بمجرد عدم وجود المزيد من الأخطاء في الإصدار التجريبي ، سيكون من الممكن القول إننا ندعم Google Cloud والأشياء المتوافقة مع S3 وتخزين الملفات.
مرحبا ، شكرا على التقرير. كما أفهمها ، WAL-G ليس نوعًا من النظام المركزي مثل barmen؟ هل تخطط للتحرك في هذا الاتجاه؟
المشكلة هي أننا ابتعدنا عن هذا الاتجاه. يعيش WAL-G على مضيف القاعدة وعلى مضيف الكتلة وعلى جميع مضيفي الكتلة. عندما انتقلنا إلى عدة آلاف من المجموعات ، كان لدينا العديد من منشآت نادل. وفي كل مرة ينهار فيها شيء ما ، إنها مشكلة كبيرة. نظرًا لأنهم بحاجة إلى الإصلاح ، فأنت بحاجة إلى فهم المجموعات التي لا تحتوي على نسخ احتياطية الآن. في اتجاه الأجهزة المادية لأنظمة النسخ الاحتياطي ، لا أخطط لتطوير WAL-G. إذا كان المجتمع يريد بعض الوظائف هنا ، فلا مانع على الإطلاق.
لدينا فرق مسؤولة عن التخزين. ونشعر بالرضا لأننا لسنا نحن ، وأن هناك أشخاصًا مميزين يضعون ملفاتنا حيث تكون الملفات آمنة. يفعلون كل أنواع الترميز الصعب هناك من أجل تحمل فقدان عدد معين من الملفات. هم مسؤولون عن عرض النطاق الترددي للشبكة. عندما يكون لديك نادل ، قد تكتشف فجأة أن قواعد البيانات الصغيرة ذات حركة المرور العالية قد تم تجميعها في نفس الخادم. يبدو أن لديك مساحة كبيرة عليه ، ولكن لسبب ما لا يتناسب كل شيء مع الشبكة. قد يتحول العكس. يوجد الكثير من الشبكات هناك ، وهناك نوى للمعالج ، لكن الأقراص قد نفدت هنا. وقد سئمنا من هذه الحاجة إلى التوفيق بين شيء ما ، وانتقلنا إلى حقيقة أن تخزين البيانات هو خدمة منفصلة ، يتحمل مسؤوليتها أشخاص خاصون منفصلون.
ملاحظة: تم إصدار نسخة جديدة ، والذي يمكنه استخدام ملف التكوين .walg.json الموجود في الدليل الرئيسي postgres افتراضيًا. يمكنك الانسحاب من البرامج النصية bash. مثال على .walg.json في هذه المشكلة
فيديو:
المصدر: www.habr.com