👈🏾 🆎 🐽 كيف تتم إدارة خدمات قواعد البيانات في ياندكس 👨🏼‍🔬 👩🏽‍💻 👨🏼‍🎓

عندما تثق بشخص ما أثمن ما لديك - بيانات التطبيق أو الخدمة - فأنت تريد أن تتخيل كيف سيتعامل هذا الشخص مع أكبر قيمة لديك.

اسمي فلاديمير بورودين ، أنا رئيس منصة بيانات Yandex.Cloud. اليوم أريد أن أخبركم كيف يتم ترتيب كل شيء ويعمل داخل خدمات قواعد البيانات المدارة في Yandex ، ولماذا يتم كل شيء على هذا النحو وما هي المزايا - من وجهة نظر المستخدمين - للحلول المختلفة. وبالطبع ، ستكتشف بالتأكيد ما نخطط للانتهاء منه في المستقبل القريب حتى تصبح الخدمة أفضل وأكثر ملاءمة لكل من يحتاج إليها.

حسنا ، دعنا نذهب!

قواعد البيانات المدارة (قواعد بيانات ياندكس المدارة) هي واحدة من خدمات ياندكس. كلاود الأكثر شعبية. بتعبير أدق ، هذه مجموعة كاملة من الخدمات ، والتي تأتي الآن في المرتبة الثانية بعد الأجهزة الظاهرية Yandex Compute Cloud التي تتمتع بشعبية.

تتيح قواعد بيانات Yandex المدارة إمكانية الحصول بسرعة على قاعدة بيانات عمل وتولي هذه المهام:

القياس - من القدرة الأولية على إضافة موارد الحوسبة أو مساحة القرص إلى زيادة عدد النسخ المتماثلة والقطع.
تثبيت التحديثات ، طفيفة وكبيرة.
النسخ الاحتياطي واستعادة.
توفير التسامح مع الخطأ.
الرصد.
توفير أدوات التكوين والإدارة مريحة.

كيف يتم ترتيب خدمات قاعدة البيانات المدارة: عرض أعلى

تتكون الخدمة من جزأين رئيسيين: طائرة التحكم وطائرة البيانات. Control Plane هو ، ببساطة ، واجهة برمجة تطبيقات لإدارة قاعدة البيانات تتيح لك إنشاء قواعد بيانات أو تعديلها أو حذفها. طائرة البيانات هي مستوى تخزين البيانات المباشر.

في الواقع ، لدى مستخدمي الخدمة نقطتي دخول:

في طائرة التحكم. في الواقع ، هناك العديد من المدخلات - وحدة تحكم الويب وأداة CLI وواجهة برمجة تطبيقات البوابة التي توفر واجهة برمجة التطبيقات العامة (gRPC و REST). لكنهم جميعًا انتقلوا في النهاية إلى ما نسميه API الداخلي ، وبالتالي سننظر في نقطة الدخول هذه في "لوحة التحكم". في الواقع ، هذه هي النقطة التي تبدأ منها منطقة خدمة قواعد البيانات المدارة (MDB).
في طائرة البيانات. هذا اتصال مباشر بقاعدة بيانات قيد التشغيل من خلال بروتوكولات الوصول إلى DBMS. إذا كان ، على سبيل المثال ، PostgreSQL ، فسيكون واجهة libpq .

فيما يلي وصف تفصيلي لكل ما يحدث في "طائرة البيانات" ، وسنحلل كل مكون من مكونات "طائرة التحكم".

طائرة البيانات

قبل النظر في مكونات طائرة التحكم ، دعونا نلقي نظرة على ما يحدث في طائرة البيانات.

داخل الجهاز الظاهري

يقوم MDB بتشغيل قواعد البيانات في نفس الأجهزة الافتراضية المتوفرة في Yandex Compute Cloud .

بادئ ذي بدء ، يتم نشر محرك قاعدة بيانات ، على سبيل المثال ، PostgreSQL ، هناك. في موازاة ذلك ، يمكن إطلاق العديد من البرامج المساعدة. بالنسبة لـ PostgreSQL ، سيكون هذا هو Odyssey ، ساحب اتصال قاعدة البيانات.

أيضًا داخل الجهاز الظاهري ، يتم إطلاق مجموعة معيارية معينة من الخدمات ، خاصة بكل DBMS:

خدمة لإنشاء نسخ احتياطية. بالنسبة لـ PostgreSQL ، يعد أداة WAL-G مفتوحة المصدر . يقوم بإنشاء نسخ احتياطية ويخزنها في Yandex Object Storage .
Salt Minion هو أحد مكونات نظام SaltStack للعمليات وإدارة التكوين. ويرد المزيد من المعلومات حول هذا الموضوع أدناه في وصف البنية التحتية للنشر.
مقاييس MDB ، المسؤولة عن نقل مقاييس قاعدة البيانات إلى Yandex Monitoring وإلى خدماتنا المصغرة لمراقبة حالة مجموعات ومضيفي MDB Health.
يعد تطبيق Push client ، الذي يرسل سجلات DBMS وسجلات الفواتير إلى خدمة Logbroker ، حلاً خاصًا لجمع البيانات وتسليمها.
MDB cron - دراجتنا ، والتي تختلف عن المعتاد في القدرة على أداء المهام الدورية بدقة ثانية.

طوبولوجيا الشبكة

يحتوي كل مضيف Data Plane على واجهات شبكة:

واحد منهم العصي في شبكة المستخدم. بشكل عام ، هناك حاجة لخدمة تحميل المنتج. من خلال ذلك ، التكرار هو مطاردة.
تتمسك الثانية بأحد شبكاتنا المُدارة التي من خلالها تذهب الأجهزة المضيفة إلى Control Plane.

نعم ، يتم تعليق مضيفي العملاء المختلفين في إحدى هذه الشبكات المدارة ، لكن هذا ليس مخيفًا ، لأنه على الواجهة المدارة (تقريبًا) لا يوجد شيء يصغي ، لا يتم فتح اتصالات الشبكة الصادرة في Control Plane إلا منها. لا أحد تقريبًا ، نظرًا لوجود منافذ مفتوحة (على سبيل المثال ، SSH) ، لكن يتم إغلاقها بواسطة جدار حماية محلي يسمح فقط بالاتصال من مضيفين محددين. وفقًا لذلك ، إذا تمكن المهاجم من الوصول إلى جهاز افتراضي باستخدام قاعدة بيانات ، فلن يتمكن من الوصول إلى قواعد بيانات الآخرين.

أمن طائرة البيانات

نظرًا لأننا نتحدث عن الأمان ، فيجب أن يقال إننا صممنا في البداية الخدمة استنادًا إلى الحصول على الجذر للمهاجم على الجهاز الظاهري لنظام المجموعة.

في النهاية ، بذلنا الكثير من الجهد للقيام بما يلي:

جدار الحماية المحلية والكبيرة.
تشفير جميع الاتصالات والنسخ الاحتياطي ؛
كل ذلك مع المصادقة والترخيص ؛
AppArmor.
معرفات مكتوبة ذاتيا.

الآن النظر في مكونات طائرة التحكم.

طائرة التحكم

API الداخلية

واجهة برمجة التطبيقات الداخلية هي نقطة الدخول الأولى في طائرة التحكم. دعونا نرى كيف يعمل كل شيء هنا.

افترض أن API الداخلي يتلقى طلبًا لإنشاء كتلة قاعدة بيانات.

أولاً وقبل كل شيء ، تقوم واجهة برمجة التطبيقات (API) الداخلية بالوصول إلى خدمة الوصول إلى الخدمة السحابية ، المسؤولة عن التحقق من مصادقة المستخدم وترخيصه. إذا نجح المستخدم في التحقق ، يتحقق واجهة برمجة التطبيقات الداخلية من صحة الطلب نفسه. على سبيل المثال ، سوف يفشل الاختبار في إنشاء طلب لإنشاء كتلة دون تحديد اسمه أو باسم مأخوذ بالفعل.

و API الداخلية يمكن أن ترسل طلبات إلى API من الخدمات الأخرى. إذا كنت ترغب في إنشاء كتلة في شبكة معينة A ، ومضيف معين في شبكة فرعية محددة B ، يجب أن تتأكد واجهة برمجة التطبيقات الداخلية من أن لديك حقوق في كل من الشبكة A والشبكة الفرعية المحددة B. في نفس الوقت ، سوف تتحقق من أن الشبكة الفرعية B تنتمي إلى الشبكة A يتطلب ذلك الوصول إلى واجهة برمجة تطبيقات البنية التحتية.

إذا كان الطلب صالحًا ، فسيتم حفظ المعلومات حول الكتلة التي تم إنشاؤها في قاعدة التعريف. نحن نسميها MetaDB ، يتم نشرها على PostgreSQL. يحتوي MetaDB على جدول مع قائمة انتظار العمليات. تقوم واجهة برمجة التطبيقات الداخلية بحفظ المعلومات حول العملية وتعيين المهمة المعاملات. بعد ذلك ، يتم إرجاع المعلومات حول العملية إلى المستخدم.

بشكل عام ، لمعالجة معظم طلبات واجهة برمجة التطبيقات الداخلية ، يكفي استخدام MetaDB و API للخدمات ذات الصلة. ولكن هناك مكونان آخران يذهبون إلى واجهة برمجة التطبيقات الداخلية للإجابة على بعض الاستعلامات - LogsDB ، حيث توجد سجلات نظام المجموعة للمستخدم ، و MDB Health. سيتم وصف كل منها بمزيد من التفاصيل أدناه.

عامل

العمال هم ببساطة مجموعة من العمليات التي تستعلم قائمة انتظار العمليات في MetaDB ، والاستيلاء عليها وتنفيذها.

ما الذي يفعله العامل بالضبط عند إنشاء كتلة؟ أولاً ، ينتقل إلى واجهة برمجة تطبيقات البنية التحتية لإنشاء أجهزة افتراضية من صورنا (لديهم بالفعل جميع الحزم اللازمة مثبتة ويتم تكوين معظم الأشياء ، ويتم تحديث الصور مرة واحدة يوميًا) عندما يتم إنشاء الأجهزة الافتراضية وتنطلق الشبكة فيها ، ينتقل العامل إلى البنية الأساسية لـ Deploy (سنخبرك المزيد عنها لاحقًا) لنشر ما يحتاجه المستخدم إلى الأجهزة الافتراضية.

بالإضافة إلى ذلك ، يصل العامل إلى الخدمات السحابية الأخرى. على سبيل المثال ، إلى Yandex Object Storage لإنشاء دلو يتم فيه حفظ النسخ الاحتياطية للكتلة. إلى خدمة مراقبة Yandex ، والتي ستجمع وتصور مقاييس قاعدة البيانات. يجب على العامل إنشاء معلومات تعريف نظام المجموعة. إلى DNS API ، إذا أراد المستخدم تعيين عناوين IP العامة إلى مضيفي الكتلة.

بشكل عام ، العامل يعمل ببساطة شديدة. يتلقى المهمة من قائمة انتظار قاعدة التعريف والوصول إلى الخدمة المطلوبة. بعد الانتهاء من كل خطوة ، يخزن العامل معلومات حول تقدم العملية في قاعدة التعريف. في حالة حدوث فشل ، تتم إعادة تشغيل المهمة ببساطة وتشغيلها من حيث توقفت. لكن حتى إعادة تشغيله من البداية لا يمثل مشكلة ، لأن جميع أنواع المهام للعمال تقريبًا مكتوبة بطريقة عشوائية. هذا لأنه يمكن للعامل تنفيذ خطوة أو أخرى من العملية ، ولكن لا توجد معلومات حول ذلك في MetaDB.

نشر البنية التحتية

في الجزء السفلي للغاية ، SaltStack ، نظام إدارة تكوين مفتوح المصدر شائع إلى حد ما مكتوب في بيثون. النظام قابل للتوسيع للغاية ، ونحن نحبه.

المكونات الرئيسية للملح هي ملح الملح ، الذي يخزن معلومات حول ما يجب تطبيقه وأين يتفاعل ملح العميل ، وهو عامل مثبت على كل مضيف ، مع المعلم ويمكنه أن يطبق الملح مباشرة من معلم الملح على المضيف. لأغراض هذه المقالة ، لدينا ما يكفي من هذه المعرفة ، ويمكنك قراءة المزيد في وثائق SaltStack .

سيد الملح واحد ليس خطأ التسامح ولا مقياس لآلاف التوابع ، وهناك حاجة إلى العديد من الماجستير. التفاعل مع هذا مباشرة من العامل غير مريح ، وكتبنا الارتباطات الخاصة بنا على Salt ، والتي نسميها إطار Deploy.

بالنسبة للعامل ، نقطة الدخول الوحيدة هي واجهة برمجة التطبيقات Deploy ، التي تنفذ طرقًا مثل "تطبيق الحالة بأكملها أو القطع الفردية على مثل هذه التوابع" و "أخبر حالة مثل هذا التطبيق المتكرر". يقوم Deploy API بتخزين معلومات حول جميع النشرات والخطوات المحددة في DeployDB ، حيث نستخدم أيضًا PostgreSQL. يتم أيضًا تخزين المعلومات حول جميع التوابع والماجستير وعن الانتماء من الأول إلى الثاني.

يتم تثبيت عنصرين إضافيين على سادة الملح:

Salt REST API ، والتي تتفاعل Deploy API معها لبدء النشرات التجريبية. يذهب REST API إلى الملح المحلي ، ويتواصل بالفعل مع التوابع باستخدام ZeroMQ.
الجوهر هو أنه يذهب إلى Deploy API ويتلقى المفاتيح العامة لجميع التوابع التي يجب أن تكون متصلاً بمعلم الملح هذا. بدون مفتاح عمومي على الرئيسي ، لا يمكن للعميل ببساطة الاتصال بالسيد.

بالإضافة إلى العميل المملح ، يتم أيضًا تثبيت مكونين في طائرة البيانات:

Returner - وحدة نمطية (واحدة من الأجزاء القابلة للمد في الملح) ، والتي لا تأتي بنتيجة طرحها ليس فقط على الملح الرئيسي ، ولكن أيضًا في Deploy API. يبدأ نشر واجهة برمجة التطبيقات النشر عن طريق الانتقال إلى واجهة برمجة تطبيقات REST على المعالج ، ويتلقى النتيجة من خلال العائد من العميل.
الزنجر الرئيسي ، الذي يستطلع بشكل دوري واجهة برمجة تطبيقات النشر التي يجب توصيل التوابع الرئيسية بها. إذا كانت واجهة برمجة التطبيقات Deploy API تُرجع عنوانًا جديدًا للمعالج (على سبيل المثال ، لأن العنوان القديم قد توفي أو تم تحميله بشكل زائد) ، يعيد الزنوج إعادة تشكيل العميل.

هناك مكان آخر نستخدم فيه القابلية للتوسعة SaltStack وهو ext_pillar - القدرة على الحصول على عمود من مكان ما خارج (بعض المعلومات الثابتة ، على سبيل المثال ، تكوين PostgreSQL والمستخدمين وقواعد البيانات والإضافات ، إلخ). نذهب إلى واجهة برمجة التطبيقات الداخلية من وحدتنا للحصول على إعدادات خاصة بالكتلة ، حيث يتم تخزينها في MetaDB.

بشكل منفصل ، نلاحظ أن الدعامة تحتوي أيضًا على معلومات سرية (كلمات مرور المستخدم وشهادات TLS ومفاتيح GPG لتشفير النسخ الاحتياطية) ، وبالتالي ، يتم تشفير كل التفاعل بين جميع المكونات (ليس في أي من قواعد بياناتنا تأتي بدون TLS و HTTPS في كل مكان ، كما يقوم العميل والسيد بتشفير كل حركة المرور). وثانيا ، يتم تشفير كل هذه الأسرار في MetaDB ، ونحن نستخدم فصل الأسرار - على أجهزة API الداخلية هناك مفتاح عمومي يقوم بتشفير جميع الأسرار قبل تخزينها في MetaDB ، والجزء الخاص منه يقع على سادة الملح ويمكن فقط الحصول عليها أسرار مفتوحة للنقل كركيزة إلى العميل (مرة أخرى عبر قناة مشفرة).

MDB الصحة

عند العمل مع قواعد البيانات ، من المفيد معرفة حالتها. لهذا ، لدينا MDB Health microservice. يتلقى معلومات حالة المضيف من المكون الداخلي MDBs الجهاز الظاهري MDB ويخزنها في قاعدة البيانات الخاصة به (في هذه الحالة ، Redis). وعندما يصل طلب حول حالة كتلة معينة إلى واجهة برمجة تطبيقات داخلية ، يستخدم واجهة برمجة التطبيقات الداخلية بيانات من MetaDB و MDB Health.

تتم معالجة المعلومات على جميع المضيفين وتقديمها في شكل مفهوم في API. بالإضافة إلى حالة المضيفين والمجموعات لبعض قواعد إدارة قواعد البيانات ، تُرجع MDB Health بالإضافة إلى ذلك ما إذا كان مضيف معين رئيسي أم نسخة متماثلة.

MDB DNS

خدمة micros DNS MDB ضرورية لإدارة سجلات CNAME. إذا كان برنامج التشغيل للاتصال بقاعدة البيانات لا يسمح بنقل عدة مضيفين في سلسلة الاتصال ، يمكنك الاتصال بـ CNAME خاص ، والذي يشير دائمًا إلى الرئيسي الحالي في الكتلة. في حالة التبديل الرئيسي ، يتغير CNAME.

كيف الحال؟ كما قلنا أعلاه ، يوجد داخل الجهاز الظاهري cron cron ، والذي يرسل بشكل دوري نبضات من المحتويات التالية إلى DNS MDB: "في هذه المجموعة ، يجب أن يشير سجل CNAME إلي." يقبل MDB DNS هذه الرسائل من جميع الأجهزة الظاهرية ويقرر ما إذا كان سيتم تغيير سجلات CNAME. إذا لزم الأمر ، فإنه يغير السجل من خلال API DNS.

لماذا قدمنا خدمة منفصلة لهذا؟ لأن DNS API لديه التحكم في الوصول فقط على مستوى المنطقة. يمكن للمهاجم المحتمل ، الذي يمكنه الوصول إلى جهاز ظاهري منفصل ، تغيير سجلات CNAME للمستخدمين الآخرين. يستبعد MDB DNS هذا السيناريو لأنه يبحث عن إذن.

تسليم وعرض سجلات قاعدة البيانات

عندما تكتب قاعدة البيانات على الجهاز الظاهري إلى السجل ، يقرأ مكون عميل الدفع الخاص هذا السجل ويرسل السطر الذي ظهر للتو إلى Logbroker ( لقد كتبوا بالفعل عن ذلك على Habré). تم بناء تفاعل عميل الدفع مع LogBroker مع دلالات دقيقة تمامًا: سنرسله بالتأكيد ونتأكد من ذلك مرة واحدة بدقة.

تجمع منفصل من الأجهزة - LogConsumers - يأخذ السجلات من قائمة انتظار LogBroker ويخزنها في قاعدة بيانات LogsDB. يتم استخدام ClickHouse DBMS لقاعدة بيانات السجل.

عند إرسال طلب إلى واجهة برمجة التطبيقات الداخلية لعرض السجلات لفترة زمنية محددة لمجموعة معينة ، يتحقق واجهة برمجة التطبيقات الداخلية من التخويل وترسل الطلب إلى LogsDB. وبالتالي ، فإن حلقة تسليم السجل مستقلة تمامًا عن حلقة عرض السجل.

الفواتير

تم تصميم نظام الفوترة بطريقة مماثلة. داخل الجهاز الظاهري ، هناك مكون يتحقق بفترات زمنية محددة من أن كل شيء يتوافق مع قاعدة البيانات. إذا كان كل شيء على ما يرام ، يمكنك تنفيذ الفوترة لهذا الفاصل الزمني من لحظة الإطلاق الأخير. في هذه الحالة ، يتم إنشاء سجل في سجل الفواتير ، ثم يرسل عميل الدفع السجل إلى LogBroker. يتم نقل البيانات من Logbroker إلى نظام الفوترة ويتم إجراء الحسابات هناك. هذا هو مخطط الفواتير لتشغيل المجموعات.

في حالة إيقاف تشغيل الكتلة ، يتوقف استخدام موارد الحوسبة ، ومع ذلك ، يتم فرض مساحة على القرص. في هذه الحالة ، يكون إعداد الفواتير من الجهاز الظاهري أمرًا مستحيلًا ، وتشارك الدائرة الثانية - دائرة إعداد الفواتير في وضع عدم الاتصال. هناك مجموعة منفصلة من الأجهزة التي تشغل قائمة مجموعات الإغلاق من MetaDB وتكتب سجلًا بنفس التنسيق في Logbroker.

يمكن استخدام الفواتير بلا اتصال للفوترة والمجموعات المضمّنة أيضًا ، ولكن بعد ذلك سنقوم باستضافة الفواتير ، حتى لو كانت قيد التشغيل ، لكنها لا تعمل. على سبيل المثال ، عندما تضيف مضيفًا إلى كتلة ، يتم نشره من النسخة الاحتياطية ويتم اكتشافه من خلال النسخ المتماثل. من الخطأ إصدار فاتورة للمستخدم لهذا ، لأن المضيف غير نشط لهذه الفترة الزمنية.

النسخ الاحتياطي

قد يختلف نظام النسخ الاحتياطي قليلاً عن نظم إدارة قواعد البيانات المختلفة ، ولكن المبدأ العام هو نفسه دائمًا.

يستخدم كل مشغل قاعدة بيانات أداة النسخ الاحتياطي الخاصة به. بالنسبة لـ PostgreSQL و MySQL ، هذا هو WAL-G . يقوم بإنشاء نسخ احتياطية وضغطها وتشفيرها ووضعها في Yandex Object Storage . في نفس الوقت ، يتم وضع كل كتلة في دلو منفصل (أولاً ، للعزل ، وثانياً ، لتسهيل توفير مساحة للنسخ الاحتياطية) ويتم تشفيرها باستخدام مفتاح التشفير الخاص بها.

هذه هي الطريقة التي تعمل بها طائرة التحكم وطائرة البيانات. من كل هذا ، يتم تشكيل خدمة قاعدة بيانات Yandex.Cloud المدارة.

لماذا يتم ترتيب كل شيء بهذه الطريقة

بالطبع ، على المستوى العالمي ، يمكن تنفيذ شيء ما وفق مخططات أكثر بساطة. لكن كان لدينا أسبابنا الخاصة لعدم اتباع طريق الأقل مقاومة.

بادئ ذي بدء ، أردنا أن يكون لدينا طائرة تحكم مشتركة لجميع أنواع قواعد البيانات. لا يهم أي واحد تختاره ، في النهاية يأتي طلبك في نفس واجهة برمجة التطبيقات الداخلية وجميع المكونات الموجودة تحته شائعة أيضًا في جميع نظم إدارة قواعد البيانات. هذا يجعل حياتنا أكثر تعقيدًا قليلاً من حيث التكنولوجيا. من ناحية أخرى ، من الأسهل بكثير تقديم ميزات وقدرات جديدة تؤثر على جميع نظم إدارة قواعد البيانات. ويتم ذلك مرة واحدة ، وليس ستة.

اللحظة الهامة الثانية بالنسبة لنا - أردنا ضمان استقلال طائرة البيانات عن طائرة التحكم قدر الإمكان. واليوم ، حتى إذا كانت Control Plane غير متوفرة بالكامل ، فستستمر جميع قواعد البيانات في العمل. ستضمن الخدمة موثوقيتها وتوافرها.

ثالثا ، تطوير أي خدمة تقريبا هو دائما حل وسط. بمعنى عام ، بمعنى تقريبًا ، من المهم في مكان ما سرعة إصدار الإصدارات ، وموثوقية إضافية في مكان ما. في الوقت نفسه ، الآن لا يمكن لأحد أن يتحمل إصدار واحد أو اثنين في السنة ، وهذا واضح. إذا نظرت إلى Control Plane ، فإننا نركز هنا على سرعة التطوير ، وعلى التقديم السريع للميزات الجديدة ، ونشر التحديثات عدة مرات في الأسبوع. و Data Plane هي المسؤولة عن سلامة قواعد البيانات الخاصة بك ، عن تحمل الأخطاء ، لذلك هنا هي دورة إصدار مختلفة تمامًا ، يتم قياسها في أسابيع. وهذه المرونة من حيث التنمية توفر لنا أيضًا استقلالهم المتبادل.

مثال آخر: عادةً ما تزود خدمات قاعدة البيانات المدارة المستخدمين بمحركات أقراص الشبكة فقط. Yandex.Cloud كما يقدم محركات الأقراص المحلية. السبب بسيط: سرعتها أعلى بكثير. مع محركات أقراص الشبكة ، على سبيل المثال ، من الأسهل توسيع نطاق الجهاز الظاهري لأعلى ولأسفل. من الأسهل عمل نُسخ احتياطية في شكل لقطات من تخزين الشبكة. لكن العديد من المستخدمين يحتاجون إلى سرعة عالية ، لذلك نجعل أدوات النسخ الاحتياطي أعلى مستوى.

الخطط المستقبلية

وبضع كلمات عن خطط لتحسين الخدمة على المدى المتوسط. هذه خطط تؤثر على قواعد بيانات Yandex المدارة بأكملها ككل ، بدلاً من قواعد بيانات إدارة قواعد البيانات الفردية.

بادئ ذي بدء ، نريد إعطاء المزيد من المرونة في تحديد وتيرة إنشاء النسخ الاحتياطي. هناك سيناريوهات عندما يكون من الضروري إجراء النسخ الاحتياطي خلال اليوم مرة واحدة كل بضع ساعات ، خلال الأسبوع - مرة واحدة في اليوم ، خلال الشهر - مرة واحدة في الأسبوع ، خلال السنة - مرة واحدة في الشهر. للقيام بذلك ، نقوم بتطوير مكون منفصل بين واجهة برمجة تطبيقات داخلية و Yandex Object Storage .

نقطة أخرى مهمة ، مهمة لكل من المستخدمين ولنا ، هي سرعة العمليات. لقد قمنا مؤخرًا بإجراء تغييرات كبيرة على البنية التحتية Deploy وتقليل وقت تنفيذ جميع العمليات تقريبًا إلى بضع ثوانٍ. لم يتم تغطيتها فقط عمليات إنشاء كتلة وإضافة مضيف إلى الكتلة. يعتمد وقت تنفيذ العملية الثانية على مقدار البيانات. ولكن أول واحد سوف نسرع في المستقبل القريب ، لأن المستخدمين غالبا ما يريدون إنشاء وحذف مجموعات في خطوط أنابيب CI / CD الخاصة بهم.

تتضمن قائمة الحالات الهامة الخاصة بنا إضافة وظيفة زيادة حجم القرص تلقائيًا. الآن يتم ذلك يدويًا ، وهو ليس مناسبًا جدًا وليس جيدًا جدًا.

أخيرًا ، نقدم للمستخدمين عددًا كبيرًا من الرسوم البيانية التي توضح ما يحدث في قاعدة البيانات. نحن نوفر الوصول إلى السجلات. في الوقت نفسه ، نرى أن البيانات غير كافية في بعض الأحيان. تحتاج الرسومات الأخرى ، وشرائح أخرى. نحن هنا نخطط التحسينات.

تبين أن قصتنا حول خدمة قاعدة البيانات المدارة طويلة وربما تكون مملة للغاية. أفضل من أي كلمات وأوصاف ، فقط الممارسة الحقيقية. لذلك ، إذا كنت تريد ، يمكنك تقييم إمكانات خدماتنا بشكل مستقل:

كيف تتم إدارة خدمات قواعد البيانات في ياندكس