ستعتمد العديد من المحاضرات القادمة على أول Y. Subbotnik على قواعد البيانات التي عقدت
في الربيع . أولاً ، تحدث المطور Andrei Borodin في Y. Subbotnik. تحدث عن WAL-G ، وهي أداة بسيطة وفعالة لعمل نسخة احتياطية من PostgreSQL إلى السحابة ، بالإضافة إلى الخوارزميات والتقنيات التي تسمح لـ WAL-G بإنشاء نسخ احتياطية بشكل أسرع. الميزة الرئيسية لـ WAL-G هي النسخ الاحتياطية للدلتا. ستتعلم في المحاضرة كيفية تطبيقها وكيفية تطوير الدعم لهذه التقنية في PostgreSQL.
- مرحبا! أنا مطور ياندكس من يكاترينبورغ. لتقنية النسخ الاحتياطي السريع. لقد قمنا بعمل نسخ احتياطي لبعض الوقت ؛ كانت هناك تقارير من
فلاديمير بورودين وإيفجيني ديوكوف حول كيفية البحث وما نقوم
بتطويره لتخزين البيانات بأمان وموثوقية وراحة وكفاءة. هذه السلسلة مخصصة لأحدث التطورات في هذا المجال.
دعونا نتحدث عن النسخ الاحتياطية في PostgreSQL من حيث المبدأ. يتم تعريف الأداة المساعدة القياسية لنقل البيانات -
pg_dump - على أنها أداة وحدة تحكم تقوم بإنشاء ملف بتمثيل منطقي لبياناتك.
أنها نسخة منطقية مريحة للغاية. يمكنك دائمًا نقل البيانات بين الإصدارات المختلفة ، ويمكنك قطع قاعدة البيانات الخاصة بك إلى أجزاء ، وهذه أداة قياسية ، على سبيل المثال ، تأتي في صندوق مع أداة إدارة PgAdmin.
بادئ ذي بدء ، حول pg_dump تحتاج إلى معرفة أن هذه أداة مطور.
هذه ليست أداة صيانة لقاعدة البيانات. pg_dump غير مصمم للعمل مع قاعدة بيانات عالية التحميل.
افترض أن كل شيء جاد وتريد استخدام تقنية "الاستعادة في الوقت المناسب" ، والتي تستخدم PostgreSQL API للعمل مع النسخ الاحتياطية عبر الإنترنت. يمكنك استدعاء الدالة pg_start_backup وعمل نسخة من قاعدة البيانات. في الواقع ، يفرض pg_start_backup قاعدة البيانات للقيام بالفحص ؛ وتمكين كتابة الصفحة الكاملة في سجل الكتابة للأمام. نسخة قاعدة البيانات التي تقوم بها عند استدعاء API ليست نسخة متسقة من البيانات. تحتاج أيضًا إلى سجل مسبق للكتابة لتتمكن من استعادة قاعدة البيانات الخاصة بك طوال مدة استدعاء pg_stop_backup ، أي في نهاية النسخة الاحتياطية.
بعد انتهاء وقت إزالة النسخة الاحتياطية وبوجود سجل رائد ، يمكنك الاسترداد إلى النقطة المطلوبة في عمر قاعدة البيانات الخاصة بك.
يتم توفير أداة pg_basebackup في الصندوق ، الذي ينفذ كل هذه التكنولوجيا في شكل أساسي ويسمح لك بالنسخ الاحتياطي مع الحد الأدنى من الوظائف الضرورية.
إذا كنت لا تزال أكثر جدية من ذي قبل ، فأنت تستخدم نوعًا من برامج إدارة النسخ الاحتياطي ، وعادة ما يكون Barman.
لديه العديد من المزايا. الميزة الرئيسية هي أداة شائعة جدًا ، ولديها مجتمع ضخم ، وعدد كبير من الأسئلة على Stack Overflow.
ما عليك سوى اختيار خادم نسخ احتياطي واحد ، وإجراء نسخ احتياطي لكل PostgreSQL هناك. هذا أمر مريح للغاية - طالما أن خادم النسخ الاحتياطي يكفيك.
بمجرد أن يكون لديك الكثير من خوادم النسخ الاحتياطي ، تحتاج إلى مراقبة ما إذا كان أي منها ممتلئًا. في حالة فشل بعض خادم النسخ الاحتياطي ، تحتاج إلى فهم أي من قواعد البيانات الخاصة بك هي الآن في خطر. عليك أن تفهم من حيث المبدأ مكان نسخ كتلة قاعدة بيانات جديدة عند إنشائها.
هناك أداة إزالة نسخ احتياطي أبسط بكثير تسمى WAL-E.
تنفيذ WAL-E أربعة أوامر رئيسية. يرسل الأمر WAL-PUSH ملف WAL واحد إلى السحابة ، ويأخذ WAL-FETCH ملف WAL واحد إذا احتجت استعادة Rest_command.
هناك أيضًا BACKUP-PUSH (ينفذ إزالة واجهة برمجة التطبيقات الاحتياطية) و BACKUP-FETCH (يأخذ جميع البيانات من السحابة). يتم تخزين البيانات في السحابة ، لذلك لا تحتاج إلى مراقبة أي شيء ، فهذه بالفعل مشكلة خدمة سحابية ، وكيفية ضمان توفر بياناتك عندما تحتاج إليها. ربما تكون هذه هي الميزة الرئيسية لـ WAL-E.
هناك الكثير من الوظائف. هناك قائمة بالنسخ الاحتياطية ، وهناك سياسة احتفاظ ، أي أننا نريد تخزين النسخ الاحتياطية للأيام السبعة الماضية ، على سبيل المثال ، أو النسخ الاحتياطية الخمسة الأخيرة ، شيء من هذا القبيل. ويمكن لـ WAL-E النسخ الاحتياطي لمجموعة كبيرة ومتنوعة من الخدمات السحابية: S3 و Azure و Google ، ويمكنها استدعاء نظام الملفات المحلي السحابة.
لديها العديد من الخصائص. أولاً ، هو مكتوب بلغة Python ويستخدم بنشاط خط أنابيب Unix ، ويرجع ذلك جزئيًا إلى ذلك ، ولديه تبعيات وليس منتجًا للغاية. هذا أمر طبيعي لأن WAL-E يركز على سهولة الاستخدام وسهولة الإعداد بحيث لا يمكنك ارتكاب خطأ عند عمل خطة احتياطية. وهذه فكرة جيدة للغاية.
هناك الكثير من الميزات المكتوبة في WAL-E ، وحيثما طورها المؤلفون لم يكن واضحًا جدًا للمؤلفين. جاءت الفكرة أنني بحاجة إلى أداة جديدة.
ميزته الرئيسية هي أنه تمت إعادة كتابتها في Go ، ولا يوجد بها تبعيات خارجية تقريبًا ، إذا كنت لا تستخدم التشفير الخارجي ، وهي أكثر إنتاجية.
تم إنشاء WAL-G في الأصل من قبل مؤلفين من Citus Data ، وتظهر الميزة الرئيسية في هذا الرسم البياني - سرعة إرسال "الأعمدة". نرى أن WAL-E سريع ، يمكن أن يكون أي شيء ، يمكن أن يكون عمودًا كبيرًا بالقرب من الصفر.
WAL-G لديه عرض نطاق ثابت إلى حد ما. في الاختبارات في Citus Data ، أظهر أنه يرسل بثبات حوالي 800 ميجا بايت / ثانية من "المهاوي".
بالإضافة إلى ذلك ، في WAL-G ، على سبيل المثال ، كتبت ميزة تنفذ النسخ الاحتياطي من نسخة متماثلة. لا تحتاج إلى تحميل قاعدة البيانات الرئيسية الخاصة بك مع تحميل القراءة ، يمكنك إزالة النسخة الاحتياطية من النسخة المتماثلة.
ولكن هناك مشكلة صغيرة واحدة. في اللحظة التي تبدأ فيها عمل النسخة الاحتياطية ، يجب عليك تسمية النسخة الاحتياطية بطريقة أو بأخرى. يتضمن الاسم مخططًا زمنيًا ، والذي سيتم تغييره إذا تم الترويج للنسخة المتماثلة. في حالة حدوث فشل في سلسلة النسخ المتماثلة قبل النسخة المتماثلة التي تقوم بالنسخ الاحتياطي بها ، ستلاحظ بعض النسخ المتماثلة ، سيتم تغيير المخطط الزمني. تدرك WAL-G أن هذا الموقف غير متناسق ، لأن وجود اسم على المخطط الزمني القديم ، يعدك الاسم بأنه يمكنك مواصلة تطوير سجل قاعدة البيانات في أي اتجاه موجود. لكن الأمر ليس كذلك. لقد انتقلت بالفعل إلى أحد الاتجاهات ؛ لا يمكنك التخطي إلى جدول زمني آخر باستخدام السيارة الخلفية. لذلك ، يتفهم WAL-G هذا الموقف ولا يقوم بتحميل ملف JSON مالي إلى السحابة. قمت بإنشاء نسخة مادية. لكن تدخل المسؤول مطلوب حتى يمكن استخدام هذه النسخة.
لقد قمنا بتنفيذ نسخ دلتا في WAL-G ، وعملت أيضًا على هذا التطوير. يسمح لك هذا بأخذ بيانات أقل في النسخة الاحتياطية الأساسية التالية ، ولا تقم بعمل نسخة من صفحات البيانات تلك التي لم تتغير عن النسخة الاحتياطية السابقة.
عند إعداد WAL-G ، فإنك تحدد عدد الخطوات الأبعد عن النسخة الاحتياطية الأساسية ، و دلتا الاحتياطية ، وتحدد سياسة نسخ دلتا. إما أن تقوم بعمل نسخة من آخر دلتا موجودة ، أو تقوم بعمل دلتا من النسخة الاحتياطية الكاملة الأصلية. يعد ذلك ضروريًا في حالة تغيير مكون قاعدة البيانات نفسه دائمًا في قاعدة البيانات ، تتغير نفس البيانات باستمرار.
لماذا نحتاج من حيث المبدأ إلى نسخ دلتا لقاعدة البيانات؟ من الناحية النظرية ، لديك WAL ، وبالتالي يمكنك التدحرج في أي مكان.
على خادم مزدحم ، قد يستغرق تشغيل WAL لمدة خمس ثوانٍ فعلية من الماضي أربع ثوانٍ فعلية من الحاضر. إذا طُلب منك تقديم WAL في أربعة أيام ، فهذا يعني أنه من الممكن أن ينتظر الشخص الذي يطلب القيام بذلك ثلاثة أيام أخرى. ليس دائما حالة مقبولة.
أنت بحاجة إلى نسخ احتياطية أساسية كل يوم ، ولكن مع ذلك ، لا يمكنك تخزين 7 أو 14 نسخة كاملة من قاعدة بياناتك هناك ، على الرغم من أن WAL-G ستقوم بأرشفتها ، إلا أنها ستظل كبيرة جدًا. وفي هذه الحالة ، تساعد نسخ دلتا.
عند تطوير نسخ دلتا ، تمت مناقشة العديد من تنسيقات ملفات البيانات الممكنة. بادئ ذي بدء ، تم اقتراح التنسيق ، عندما لا نقوم بإزعاج الصفحة ، فإننا ببساطة نقوم بإبطالها. ولكننا توصلنا إلى استنتاج مفاده أن هذه ليست طريقة فعالة للغاية ، ثم يتم ضغط الأصفار بشكل فعال ، ولكن بعد ذلك رفضنا طريقة التخزين هذه ، لأنه من الصعب تصحيحها في حالات الطوارئ.
التقنية التالية التي تم أخذها في الاعتبار هي أولاً تخزين رقم الكتلة ثم الكتلة المتغيرة. لكننا نواجه هنا خصوصية التخزين في ملفات TAR ، التي نحتاجها أولاً للإشارة إلى حجم ملفات TAR التي نخزن فيها نسخة دلتا الخاصة بنا ، ثم نبدأ في تسجيلها. كنت أرغب في تنفيذ التكنولوجيا بحد أدنى من ذاكرة الوصول العشوائي المستهلكة ، لذلك كان علينا استخدام التنسيق الثالث الذي نقرأ فيه أولاً كل ملف بيانات بالكامل ، والبحث عن صفحات البيانات التي تم تغييرها ، أولاً تخزين أرقام الكتل التي تم تغييرها في ملف TAR ، وبعد ذلك فقط الكتل المتغيرة نفسها.
لم يتم تنفيذ هذه الميزة حتى الآن. أنا أنظر إليها أو أبحث عن شخص يريد تقديم طلب سحب في WAL-G. عند التعافي من نسخة دلتا ، تنجو قاعدة البيانات من كل تناسخ لقاعدة البيانات في كل خطوة من نسخة دلتا الاحتياطية. في بعض الأحيان يتم حذف بعض الملفات في منتصف العمر. في الوقت نفسه ، لا داعي للقلق بشأن حالتهم إذا تم حذفهم على أي حال ، ثم إعادة إنشائهم من نسخة دلتا. لا يبدو أن هذه ميزة معقدة للغاية ، لذلك إذا كنت مهتمًا بكتابة شيء ما على Go ، فألق نظرة على هذه الميزة.
جدولة حول استخدام الشبكة ووحدة المعالجة المركزية والقرص. في WAL-E ، كما نرى ، لم ينته النسخ الاحتياطي هنا بعد ، فقد بدأ في الواحدة صباحًا في موسكو ، ولم ينته في التقرير الأخير الذي نراه. انتهى جدول WAL-G ، وهو يعمل بشكل أسرع وأكثر من ذلك بكثير من حيث استهلاك الموارد.
الشيء الأكثر إثارة للاهتمام هو الرسم البياني لاستهلاك الموارد خلال نسخة دلتا. نرى أن جميع الموارد أصبحت صفر تقريبًا. الحمل على وحدة المعالجة المركزية هو تقريبًا الحمل القياسي في قاعدة البيانات ؛ في الليل ، يتم تنفيذ بعض الاستعلامات. نرى درجة كبيرة من القراءة. أتعامل معها أيضًا ، وأود أيضًا أن أسحب الطلب أو سأفعل ذلك بنفسي في الصيف. خلاصة القول هي أنه لا يزال يتعين علينا قراءة بياناتنا لمعرفة ما تغير فيها. كان من الممكن تجنب هذه القراءة.
هناك حذف في WAL-G عندما نشير إلى عدد النسخ الاحتياطية أو التاريخ الذي نحتاج فيه إلى تخزين جميع WALs وجميع النسخ الاحتياطية الأساسية. ويتعامل WAL-G بالفعل مع مسألة ما هي WALs والنسخ الاحتياطية الأساسية المطلوبة. حتى الآن ليس لدينا ميزات تحذف كل شيء. في WAL-E ، إنها أيضًا مناسبة لطلب السحب. لم يتم تنفيذ أمر DELETE EVERYTHING المثير للاهتمام حتى الآن.
هناك قائمة بالنسخ الاحتياطية.
قمنا بتعيين متغير البيئة اللازم لتشغيل WAL-G واستدعاء أداة وحدة التحكم WAL-G. يتم عرض النسخ الاحتياطية التي نحتاج إلى عرضها.
تقوم WAL-G بتطبيق الكثير من التقنيات لموازنة النسخ الاحتياطية والعمليات المختلفة بشكل عام. على سبيل المثال ، يتم استخدام هذه التقنية لإرسال "مهاوي" إلى الأرشيف. بمجرد استدعاء PostgreSQL لـ archive_command لإرسال ملف واحد ، يتطلع WAL-G لمعرفة ما إذا كان هناك المزيد من الملفات القريبة جاهزة.
بشكل عام ، هذه ليست ميزة موثقة للغاية ، فهي مستقرة جدًا في أحدث إصدارات PostgreSQL ، حيث تستخدمها العديد من التقنيات. نحن ننظر في ما إذا كانت هناك ملفات WAL جاهزة في حالة الأرشيف ، كما نرسلها مع الملف الذي طلب إرسال قاعدة البيانات إلى الأرشيف. وعندما تطلب منهم PostgreSQL إرسالها ، فقد أرسلناها بالفعل ، فنحن جاهزون. هذا يسرع بشكل كبير من إرسال WALs على القواعد المحملة ويسمح لك بجعلها غير مترابطة. عادة ، يعد PostgreSQL ملفًا واحدًا ، ثم ينتظره ليقوم بتحضير الملف التالي. تمكنا من تجنب هذا العمل المتسق.
أثناء WAL-FETCH ، عندما تتم استعادة الكتلة ، نحاول أيضًا تنزيل ملفات N التالية التي ستكون مطلوبة ، ومحاولة موازنة فترات التوقف المؤقت بين بداية التهيئة المسبقة لملفات WAL الجديدة حتى نتمكن من استخدام جميع الموارد التي لدينا قدر الإمكان: إما تشغيلها في الشبكة أو اصطدم بالقرص في حالات نادرة.
يتم ضبط كل ذلك من خلال متغيرات البيئة.
هناك أيضا التزامن لعمل نسخة. على الرغم من أن هذه الميزة غير موجودة في الإصدارات المختلفة - تم إصدار A. B. في الإصدار 0.1.10 في يونيو 2018 - نظرًا لأن التوازي في القراءة من القرص يسمح لك بضمان التشغيل في شبكة أو قرص. هذا ليس جيدًا جدًا مع قاعدة بيانات محملة. WAL-E لديها ميزة تسمح بالاختناق. حتى الآن ، ليس لدينا هذا. من الضروري الحد من سرعة إزالة النسخ الاحتياطي حتى يمكن للقاعدة أن تعيش حياتها وتخدم الحمل.
ميزتنا الرئيسية لا تتعلق حقًا بالتكنولوجيا.
قبل عامين ، نفذت Zhenya Dyukov تقنية
دلتا الاحتياطية لـ Barman ، ولم يتم عقدها بعد ، ولا يزال المجتمع يناقشها.
منذ ما يقرب من عام ، قامت Zhenya بإصلاح خطأ WAL-E ، وأرسلناها لمدة ستة أشهر (
رابط إلى GitHub - Ed. تقريبًا). في كثير من الأحيان في الحلول مفتوحة المصدر ، هناك مشكلة في حقيقة أنها ليست جيدة الصيانة.
مع WAL-G ، كل شيء بسيط للغاية: نستخدمه وأحتفظ به. إذا احتجنا أو احتجنا إلى شيء ما ، فأنت تبلغ أن لديك مشكلة. سنحاول حلها.
الطلب القياسي من المجتمع بسيط - "فلنقم بذلك أكثر".
المزيد من التشفير ، والمزيد من المنصات. ربما ليس فقط PostgreSQL ، ولكن MySQL لا يزال يحتفظ بنسخة احتياطية أو أي شيء آخر؟ أرى بعض الأشياء الأخرى.
بادئ ذي بدء ، الآن عند إرسال "رمح" يمكننا أن نفهم كتل قاعدة البيانات التي تغيرت ، ومسح ملفات WAL هذه وحفظ المعلومات حول ما تغير.
وعندما يصل cron مع نسخة احتياطية أخرى من دلتا ، لم نتمكن من مسح قاعدة البيانات بالكامل ، وتسجيل هذا القرص من قراءة القرص ومعرفة الصفحات التي نحتاج إلى سحبها إلى السحابة.
حاولنا استخدام تقنية تتبع الصفحة. ينفذ تتبع تغييرات الصفحة على مستوى نواة قاعدة البيانات. تتم إزالة النسخ الاحتياطي بسرعة كبيرة. تكمن المشكلة الرئيسية في PTRACK في أنها شديدة الغزو. يحتوي على الكثير من التغييرات في جوهر PostgreSQL في أماكن حساسة للغاية ، لذلك من غير المحتمل اعتماده قريبًا.
بالإضافة إلى ذلك ، فإن الدلتا تختلف قليلاً عن الدلتا التي لدينا الآن. عند إزالة دلتا المستندة إلى LSN ، نقوم بإزالة جميع التغييرات في ملف دلتا التي حدثت من البداية السابقة إلى الوقت الحالي.
في حالة PTRACK ، نحصل على تغييرات في ملف دلتا ، بدءًا من دلتا السابقة التي تم تلقيها. ليس لدينا وقت دلتا بالضبط قبل بدء النسخ الاحتياطي ، قبل بدء التغييرات. هذه ليست المشكلة الرئيسية لـ PTRACK بشكل عام ، فهي تعمل بشكل جيد ، ولكن حتى الآن من الصعب قبولها.
لا يسمح PTRACK بإزالة دلتا في الوضع LATEST_FULL ، لأنه يخزن خريطة للكتل التي تم تغييرها من الإزالة السابقة لهذه الخريطة. تمتلك أوراكل تقنية مثيرة للاهتمام ، فهناك 8 بطاقات سابقة يتم حفظها في حالة الحاجة. ربما يمكننا القيام بشيء مماثل ، ولكن حتى الآن لا نعمل في هذا الاتجاه.
في سبتمبر الماضي ، حاولت أن أقدم للمجتمع تقنية تعتمد على حقيقة أننا نضيف فقط السنانير التي نحتاجها إلى النواة ، ونقوم بتتبع الصفحات التي تم تغييرها في الامتداد بحيث لا يكون تصحيح تتبع الصفحة غازيًا للغاية. بعد مناقشة هذه التكنولوجيا ، توصلنا إلى استنتاج مفاده أننا بحاجة إلى العديد من النماذج الأولية ، وسنضيف خطافات عند وجود نماذج أولية. ربما سنرى كيف تعمل. أنا أعمل حاليًا على نماذج أولية لهذه الملحقات التي يمكن أن تستخدم خطافات kernel لتتبع تغييرات قاعدة البيانات.
هناك تعبير في المجتمع أن كل postgresista يجب أن يكون لديه أداة النسخ الاحتياطي الخاصة به. هذا سيء. كل شخص يقوم بعمله الخاص ، والذي يقوم بمهمة حرجة. يجب أن يكون هناك شيء واحد سيكون فيه كل شيء في الصندوق ، كل شيء سيكون مثاليًا في عالم مثالي.
ما الذي أرغب في رؤيته في صندوق في لعبة basebackup؟ نود أن نرى ، على الأرجح ، الأرشفة إلى السحابة. ونسخ الدلتا.
أرغب أيضًا في الضغط ، والتزامن ، والتشفير ، والاختناق ، وقائمة النسخ الاحتياطية ، والتحقق ، والتحقق من صحة النسخ الاحتياطية ... الكثير من الأشياء. نحن نتفهم أنه إذا تم تقديم كل هذا الآن إلى المجتمع ، فسيؤدي إلى عشرات التصحيحات ، التي يصعب مناقشتها وتنفيذها من خلال الالتزام. لذلك ، ما زلنا نستخدم أداة منفصلة ، ولكن هناك رغبة في تكريس الوقت والتكنولوجيا للمجتمع لجعل PostgreSQL أفضل.