أدخل فريق Tarantool Core وأشارك في تطوير محرك قاعدة بيانات ، والاتصالات الداخلية لمكونات الخادم والنسخ المتماثل. واليوم سوف أخبرك بكيفية عمل النسخ المتماثل.
حول النسخ المتماثل
النسخ المتماثل هو عملية إنشاء نسخ من البيانات من متجر إلى آخر. كل نسخة تسمى نسخة طبق الأصل. يمكن استخدام النسخ المتماثل إذا كنت ترغب في الحصول على نسخة احتياطية أو تنفيذ وضع الاستعداد السريع أو تغيير حجم النظام أفقياً. ولهذا من الضروري أن تكون قادرًا على استخدام نفس البيانات على العقد المختلفة لشبكة الكمبيوتر الخاصة بالكتلة.
نقوم بتصنيف النسخ المتماثل بطريقتين رئيسيتين:
- الاتجاه: السيد ماجستير أو السيد العبد . تكرار السيد والعبد هو الخيار الأسهل. لديك عقدة واحدة تقوم بتغيير البيانات عليها. يمكنك ترجمة هذه التغييرات إلى العقد الأخرى حيث يتم تطبيقها. مع النسخ المتماثل الرئيسي ، يتم إجراء تغييرات على عقد متعددة في وقت واحد. في هذه الحالة ، تقوم كل عقدة بتغيير بياناتها نفسها وتطبيق التغييرات التي تم إجراؤها على العقد الأخرى على نفسها.
- وضع التشغيل: غير متزامن أو متزامن . يتضمن النسخ المتماثل المتزامن أن البيانات لن يتم الالتزام بها ولن يتم تأكيد النسخ المتماثل للمستخدم حتى يتم نشر التغييرات من خلال الحد الأدنى لعدد العقد على الأقل. في النسخ المتماثل غير المتزامن ، يعد تنفيذ معاملة (ارتكابها) والتفاعل مع مستخدم عمليتين مستقلتين. لارتباط البيانات ، من الضروري أن تندرج في السجل المحلي ، وعندها فقط يتم نقل هذه التغييرات بطريقة ما إلى العقد الأخرى. من الواضح أن النسخ المتماثل غير المتزامن له عدد من الآثار الجانبية بسبب هذا.
كيف يعمل النسخ المتماثل في Tarantool؟
يحتوي النسخ المتماثل في Tarantool على العديد من الميزات:
- وهي مبنية من الطوب الأساسي ، والتي يمكنك من خلالها إنشاء مجموعة من أي طوبولوجيا. كل عنصر تكوين أساسي من هذا القبيل أحادي الاتجاه ، أي أن لديك دائمًا السيد والعبد. يقوم Master بتنفيذ بعض الإجراءات ويقوم بإنشاء سجل للعمليات ، يتم استخدامه على النسخة المتماثلة.
- النسخ المتماثل Tarantool غير متزامن. أي أن النظام يؤكد التزامك ، بغض النظر عن عدد النسخ المتماثلة التي شهدتها هذه المعاملة ، ومقدار ما تم تطبيقها على نفسها ، وما إذا كان قد تم تنفيذه على الإطلاق.
- خاصية أخرى للنسخ المتماثل في Tarantool هي أنه قائم على الصف. يحتفظ Tarantool بسجل للعمليات (WAL). تصل العملية إلى هناك سطرا ، أي عندما تتغير بعض اللوحات من المساحة ، تتم كتابة هذه العملية إلى السجل كسطر واحد. بعد ذلك ، تقوم عملية الخلفية بقراءة هذا السطر من السجل وإرساله إلى النسخة المتماثلة. كم عدد النسخ المتماثلة للسيد ، العديد من العمليات الخلفية. أي ، يتم تنفيذ كل عملية النسخ المتماثل إلى عقد مختلفة من الكتلة بشكل غير متزامن من الآخرين.
- كل عقدة كتلة لها معرف فريد خاص بها ، والتي يتم إنشاؤها عند إنشاء العقدة. بالإضافة إلى ذلك ، تحتوي العقدة أيضًا على معرف في الكتلة (رقم العضو). هذا ثابت رقمي يتم تعيينه لنسخة متماثلة عند الاتصال بمجموعة ، ويبقى مع النسخة المتماثلة طوال حياته في الكتلة.
بسبب عدم التزامن ، يتم تسليم البيانات إلى النسخ المتماثلة المتأخرة. أي أنك قمت ببعض التغيير ، وأكد النظام الالتزام ، وقد تم بالفعل تطبيق العملية على الرئيسي ، ولكن على النسخ المتماثلة سيتم تطبيقها مع بعض التأخير ، والتي يتم تحديدها بالسرعة التي تقرأ بها عملية النسخ المتماثل للخلفية العملية ، وترسلها إلى النسخة المتماثلة ، وهذا ينطبق .
لهذا السبب ، هناك فرصة لخروج البيانات من المزامنة. لنفترض أن لدينا العديد من الأساتذة الذين يغيرون البيانات المترابطة. قد يتضح أن العمليات التي تستخدمها غير تبادلية وتشير إلى نفس البيانات ، ثم سيكون لدى عضوين مختلفين في المجموعة إصدارات مختلفة من البيانات.
إذا كان النسخ المتماثل في Tarantool أحادي الاتجاه السيد ، ثم كيفية جعل السيد الماجستير؟ بسيط جدًا: قم بإنشاء قناة نسخ متماثل أخرى ولكن في الاتجاه الآخر. يجب أن تفهم أن النسخ المتماثل الرئيسي في Tarantool هو مجرد مزيج من دفقتي بيانات مستقلتين عن بعضهما البعض.
باستخدام نفس المبدأ ، يمكننا توصيل رئيسية ثالثة ، ونتيجة لذلك ، فإننا نبني شبكة شبكية كاملة تكون فيها كل نسخة متماثلة رئيسية وعبدًا لجميع النسخ المتماثلة الأخرى.
يرجى ملاحظة أنه لا يتم فقط نسخ تلك العمليات التي بدأت محليًا على هذا المعلم الرئيسي ، ولكن أيضًا تلك التي تلقاها خارجيًا عبر بروتوكولات النسخ المتماثل. في هذه الحالة ، ستأتي التغييرات التي تم إنشاؤها على النسخة المتماثلة رقم 1 إلى النسخة المتماثلة رقم 3 مرتين: مباشرة ومن خلال النسخة المتماثلة رقم 2. تتيح لنا هذه الخاصية بناء طبولوجيا أكثر تعقيدًا دون استخدام شبكة كاملة. دعنا نقول هذا واحد.
لدى جميع الأساتذة الثلاثة ، الذين يشكلون معًا شبكة أساسية كاملة من المجموعة ، نسخة متماثلة فردية مرفقة. نظرًا لأنه يتم إجراء بروكسي السجلات على كل من الأساتذة ، فإن العبيد "النظيفين" الثلاثة سيحتويون على جميع العمليات التي تم تنفيذها على أي من العقد العنقودية.
يمكن استخدام هذا التكوين لمجموعة متنوعة من المهام. لا يمكنك إنشاء ارتباطات زائدة بين جميع عقد الكتلة ، وإذا تم وضع النسخ المتماثلة في مكان قريب ، فستحصل على نسخة دقيقة من البرنامج الرئيسي مع أقل تأخير. ويتم كل هذا باستخدام عنصر النسخ المتماثل الأساسي للرقيق.
وسم عمليات الكتلة
السؤال الذي يطرح نفسه:
إذا تم إجراء العمليات بين جميع أعضاء المجموعة وتوصلهم إلى كل نسخة متماثلة عدة مرات ، كيف نفهم العملية التي يجب تنفيذها وأيها لا؟ هذا يتطلب آلية تصفية. يتم تعيين سمتين لكل عملية قراءة من السجل:
- معرف الخادم الذي بدأت عليه هذه العملية.
- رقم تسلسل العملية على الخادم ، lsn ، والذي هو البادئ الخاص به. كل خادم ، عند إجراء عملية ، يعيّن رقمًا متزايدًا لكل سطر سجل مستلم: 1 ، 2 ، 3 ، 4 ، 5 ، 6 ، 7 ، 8 ، 9 ، 10 ... وهكذا ، إذا علمنا أنه بالنسبة لخادم ذي معرف معين ، فقد طبقنا العملية بـ lsn 10 ، ثم العمليات مع lsn 9 و 8 و 7 و 10 التي جاءت عبر قنوات النسخ المتماثل الأخرى ليست ضرورية. بدلاً من ذلك ، نطبق ما يلي: 11 و 12 وما إلى ذلك.
حالة النسخة المتماثلة
وكيف تخزن Tarantool معلومات حول العمليات التي طبقتها بالفعل؟ للقيام بذلك ، هناك ساعة Vclock - هذا هو ناقل lsn الأخير المطبقة على كل عقدة في الكتلة.
[lsn 1 , lsn 2 , lsn n ]حيث
lsn i هو رقم آخر عملية معروفة من الخادم ذات المعرف i.
يمكن أيضًا استدعاء Vclock لقطة معينة لحالة الكتلة بأكملها المعروفة بهذه النسخة المتماثلة. عند معرفة معرف الخادم للعملية التي وصلت ، فإننا نعزل مكون Vclock المحلي الذي نحتاجه ، ونقارن lsn الذي تم الحصول عليه مع عملية lsn ، ونقرر ما إذا كنا سنستخدم هذه العملية. نتيجة لذلك ، سيتم إرسال العمليات التي بدأها رئيسي محدد وتطبيقها بالتتابع. في الوقت نفسه ، يمكن خلط مهام سير العمل التي تم إنشاؤها على شرائح رئيسية مختلفة مع بعضها البعض بسبب النسخ المتماثل غير المتزامن.
إنشاء الكتلة
لنفترض أن لدينا مجموعة تتكون من عنصرين رئيسيين وعبد ، ونريد توصيل مثيل ثالث به. لديها UUID فريدة من نوعها ، ولكن لا يوجد معرف الكتلة حتى الآن. إذا لم تتم التهيئة بعد ، يريد Tarantool الانضمام إلى الكتلة ، يجب أن يرسل عملية JOIN إلى أحد الأساتذة الذين يمكنهم تنفيذها ، أي أنها في وضع القراءة والكتابة. استجابةً لـ JOIN ، يرسل المعلم لقطة سريعة إلى النسخة المتماثلة المتصلة. تقوم النسخة المتماثلة بتطبيقه في المنزل ، بينما لا يزال لا يحتوي على معرّف. الآن يتم مزامنة النسخة المتماثلة مع تأخر طفيف مع الكتلة. بعد ذلك ، يعين الرئيسي الذي تم تشغيل JOIN معرفًا لهذه النسخة المتماثلة ، والذي يتم تسجيله وإرساله إلى النسخة المتماثلة. عندما يتم تعيين معرف إلى نسخة متماثلة ، يصبح عقدة كاملة وبعد ذلك يمكنه بدء النسخ المتماثل للسجل إلى جانبه.
يتم إرسال خطوط من دفتر اليومية بدءاً من حالة هذه النسخة المتماثلة في وقت طلب سجل النسخ المتماثل من الرئيسي - أي من vclock التي تلقاها أثناء عملية JOIN أو من المكان الذي توقفت فيه النسخة المتماثلة سابقًا. إذا كانت النسخة المتماثلة قد سقطت لسبب ما ، فعندما تتصل في الكتلة في المرة التالية ، لم تعد تقوم بتنفيذ JOIN ، لأنها تحتوي بالفعل على لقطة محلية. طلبت فقط جميع العمليات التي حدثت أثناء غيابها في المجموعة.
تسجيل نسخة متماثلة في كتلة
لتخزين الحالة حول بنية الكتلة ، يتم استخدام مساحة خاصة - الكتلة. أنه يحتوي على معرفات الخادم في الكتلة وأرقامها التسلسلية ومعرفاتها الفريدة.
[1, 'c35b285c-c5b1-4bbe-83b1-b825eb594aa4']
[2, '37b12cb7-d324-4d75-b428-cde92c18e708']
[3, 'b72b1aa6-42a0-4d73-a611-900e44cdd465']لا يُطلب من معرّفات التعريف الترتيب ، لأن العقد يمكن إسقاطها وإضافتها.
هنا هو أول مأزق. وكقاعدة عامة ، لا يتم تجميع الكتل عن طريق عقدة واحدة: تقوم بتشغيل تطبيق معين وتقوم بنشر المجموعة بالكامل مرة واحدة. لكن النسخ المتماثل في Tarantool غير متزامن. ماذا لو قام اثنان من الأساتذة في وقت واحد بتوصيل عقد جديدة وتعيين معرّفات متطابقة لها؟ سيكون هناك صراع.
فيما يلي مثال على JOIN خاطئ وصحيح:
لدينا اثنين من الماجستير واثنين من النسخ المتماثلة التي ترغب في الاتصال. أنها تجعل الانضمام إلى أسياد مختلفة. افترض الحصول على النسخ المتماثلة نفس المعرفات. ثم سينهار النسخ المتماثل بين الأساتذة وأولئك الذين يتمكنون من نسخ سجلاتهم ، ستنهار المجموعة.
لمنع حدوث ذلك ، تحتاج إلى بدء النسخ المتماثلة بدقة على رئيسية واحدة في أي وقت. تحقيقًا لهذه الغاية ، قدم Tarantool مفهومًا كقائد تهيئة ، وقام بتنفيذ خوارزمية لاختيار هذا القائد. تنشئ النسخة المتماثلة التي تريد الاتصال بالكتلة أولاً اتصالًا بجميع الشرائح الرئيسية المعروفة لها من التكوين المنقول. ثم تحدد النسخة المتماثلة تلك التي بدأت بالفعل (عند نشر الكتلة ، لا تستطيع كل العقد كسب المال الكامل). ومنهم يتم اختيار السادة المتاحة للتسجيل. في Tarantool ، هناك للقراءة والكتابة فقط ، لا يمكننا التسجيل على عقدة القراءة فقط. بعد ذلك ، من قائمة العقد التي تمت تصفيتها ، نختار تلك التي تحتوي على أقل UUID.
إذا استخدمنا نفس التكوين ونفس قائمة الخوادم على مثيلات غير مهيأة تتصل بالكتلة ، فسيختارون نفس البيانات الرئيسية ، مما يعني أن JOIN سوف ينجح على الأرجح.
من هنا نشتق قاعدة: عند توصيل النسخ المتماثلة إلى كتلة بالتوازي ، يجب أن يكون لكل هذه النسخ المتماثلة نفس تكوين النسخ المتماثل. إذا تجاهلنا شيئًا ما في مكان ما ، فهناك احتمال أن يتم تشغيل المثيلات ذات التكوينات المختلفة على أساتذة مختلفة ولن تتمكن المجموعة من التجميع.
لنفترض أننا كنا مخطئين ، أو أن المسؤول قد نسي إصلاح التهيئة ، أو كسر Ansible ، وأن المجموعة لا تزال متقطعة. ما يمكن أن يشهد على هذا؟ أولاً ، لن تتمكن النسخ المتماثلة القابلة للتوصيل من إنشاء لقطات محلية: لا يتم بدء النسخ المتماثلة والإبلاغ عن الأخطاء. ثانياً ، على الشرائح الرئيسية في السجلات ، سنرى الأخطاء المتعلقة بالتعارضات في الكتلة الفضائية.
كيف يمكننا حل هذا الوضع؟ انها بسيطة:
- بادئ ذي بدء ، نحن بحاجة إلى التحقق من صحة التكوين الذي حددناه للنسخ المتماثلة للربط ، لأنه إذا لم نصلحها ، فسيصبح كل شيء آخر عديم الفائدة.
- بعد ذلك ، نقوم بإزالة الصراعات في المجموعة والتقاط صورة.
الآن يمكنك محاولة تهيئة النسخ المتماثلة مرة أخرى.
حل النزاع
لذلك ، أنشأنا مجموعة ومتصلة. تعمل جميع العقد في وضع الاشتراك ، أي أنها تتلقى التغييرات التي تم إنشاؤها بواسطة أسياد مختلفة. لأن النسخ المتماثل غير متزامن ، تكون التعارضات ممكنة. عندما تقوم في وقت واحد بتغيير البيانات على الشرائح الرئيسية المختلفة ، تحصل النسخ المتماثلة المختلفة على نسخ مختلفة من البيانات ، لأنه يمكن تطبيق العمليات بترتيب مختلف.
هنا كتلة مثال بعد تنفيذ JOIN:
لدينا ثلاثة عبيد سيد ، يتم نقل السجلات بينهم ، والتي يتم توكيلها في اتجاهات مختلفة ويتم تطبيقها على العبيد. تعني البيانات غير المتزامنة أن كل نسخة متماثلة سيكون لها سجل تغيير vclock الخاص بها ، لأنه يمكن خلط التدفقات من مختلف الشرائح مع بعضها البعض. ولكن بعد ذلك يمكن أن يختلف ترتيب العمليات في الحالات. إذا كانت عملياتنا غير تبديلية ، مثل عملية استبدال ، فإن البيانات التي نتلقاها على هذه النسخ المتماثلة ستكون مختلفة.
مثال صغير. لنفترض أن لدينا اثنين من الماجستير مع vclock = {0،0}. وسيقوم كلاهما بإجراء عمليتين ، تم تعيينهما كـ op1 ، 1 ، op1 ، 2 ، op2 ، 1 ، op2 ، 2. هذه هي المرة الثانية التي يقوم فيها كل أستاذ بإجراء عملية محلية واحدة:
يشير اللون الأخضر إلى حدوث تغيير في مكون vclock المقابل. أولاً ، يغيّر كل من رئيسي vclock الخاصين بهما ، ثم يقوم السيد الثاني بإجراء عملية محلية أخرى ويزيد من جديد vclock. يتلقى السيد الأول عملية النسخ المتماثل من الرئيسي الثاني ، ويشار إلى ذلك بالرقم الأحمر 1 في vclock لعقدة الكتلة الأولى.
ثم يتلقى السيد الثاني العملية من الأولى ، والأولى - العملية الثانية من الثانية. وفي النهاية ، يقوم السيد الأول بتنفيذ آخر عملية له ، بينما يتلقى السيد الثاني ذلك.
Vclock في كمية الوقت صفر لدينا نفس - {0،0}. في الكم الأخير من الوقت ، لدينا أيضًا نفس vclock {2،2} ، ويبدو أن البيانات يجب أن تكون هي نفسها. لكن ترتيب العمليات المنفذة على كل سيد مختلف. وإذا كانت هذه عملية استبدال بقيم مختلفة لنفس المفاتيح؟ ثم ، على الرغم من نفس vclock في النهاية ، سوف نحصل على إصدارات مختلفة من البيانات على كلا النسخ المتماثلة.
نحن أيضا قادرون على حل هذا الموقف.
- تبادل السجلات . أولاً ، يمكننا إجراء عمليات كتابة ليس على نسخ متماثلة تم اختيارها عشوائيًا ، ولكن يمكننا شطبها بطريقة أو بأخرى. لقد كسروا عمليات الكتابة عبر أساتذة مختلفين وحصلوا على نظام تناسق نهائي. على سبيل المثال ، تم تغيير المفاتيح من 1 إلى 10 في برنامج رئيسي واحد ومن 11 إلى 20 على جهاز آخر - ستتبادل العقد سجلاتها وستحصل على البيانات نفسها تمامًا.
تعني المشاركة أن لدينا جهاز توجيه معين. ليس من الضروري أن يكون كيانًا منفصلاً على الإطلاق ، يمكن أن يكون جهاز التوجيه جزءًا من التطبيق. يمكن أن يكون عبارة عن قطعة صغيرة تطبق عمليات الكتابة على نفسها أو تنقلها إلى رئيسي آخر بطريقة أو بأخرى. ولكنه يمر بطريقة تنتقل بها التغييرات في القيم المرتبطة إلى عنصر رئيسي معين: كتلة واحدة من القيمة ذهبت إلى رئيسية واحدة ، كتلة أخرى إلى رئيسية أخرى. في هذه الحالة ، يمكن إرسال عمليات القراءة إلى أي عقدة في الكتلة. ولا تنسَ النسخ المتماثل غير المتزامن: إذا قمت بالتسجيل على نفس الصفحة الرئيسية ، فقد تحتاج أيضًا إلى القراءة منه.
- الترتيب المنطقي للعمليات . افترض أنه وفقًا لظروف المشكلة ، يمكنك تحديد أولوية العملية بطريقة أو بأخرى. قل ، أو ضع طابعًا زمنيًا ، أو إصدارًا آخر ، أو تسمية أخرى تسمح لنا بفهم العملية التي حدثت فعليًا في وقت سابق. وهذا هو ، نحن نتحدث عن مصدر خارجي للطلب.
يحتوي before_replace مشغل before_replace الذي يمكن تنفيذه أثناء النسخ المتماثل. في هذه الحالة ، لسنا مقيدين بالحاجة إلى توجيه الطلبات ، يمكننا إرسالها إلى أي مكان نريد. ولكن عند إجراء النسخ المتماثل عند إدخال دفق البيانات ، لدينا محفز. يقرأ الخط المرسل ويقارنه مع الخط الذي تم تخزينه بالفعل ، ويقرر أي من الخطوط له أولوية أعلى. أي أن المشغل إما يتجاهل طلب النسخ المتماثل أو يطبقه ، ربما مع التعديلات المطلوبة. نحن نطبق هذا النهج بالفعل ، على الرغم من أن له عيوبه أيضًا. أولاً ، تحتاج إلى مصدر ساعة خارجي. لنفترض أن المشغل في صالون الهاتف المحمول يقوم بإجراء تغييرات على المشترك. بالنسبة إلى هذه العمليات ، يمكنك استخدام الوقت على جهاز الكمبيوتر الخاص بالمشغل ، لأنه من غير المحتمل أن يقوم العديد من المشغلين بإجراء تغييرات على مشترك واحد في نفس الوقت. يمكن أن تأتي العمليات بطرق مختلفة ، ولكن إذا كان بالإمكان تعيين نسخة معينة لكل منها ، فعند المرور عبر المشغلات ، تبقى فقط تلك ذات الصلة.
العيب الثاني في الطريقة: بما أن المشغل يتم تطبيقه على كل دلتا تأتي بالنسخ المتماثل لكل طلب ، فإن هذا يخلق حمولة حسابية إضافية. ولكن بعد ذلك سيكون لدينا نسخة متسقة من البيانات على نطاق الكتلة.
مزامنة
النسخ المتماثل الخاص بنا غير متزامن ، بمعنى أنه من خلال تنفيذ الالتزام ، لا تعرف ما إذا كانت هذه البيانات موجودة بالفعل على بعض عقدة نظام المجموعة الأخرى. إذا قمت بإجراء التزام رئيسي ، تم تأكيد ذلك لك ، وتوقفت عن العمل لسبب ما على الفور ، فلا يمكنك التأكد من حفظ البيانات في مكان آخر. لحل هذه المشكلة ، يحتوي بروتوكول النسخ المتماثل Tarantool على ACK. كل سيد يحمل المعرفة عن آخر ACK جاء من كل عبد.
ما هو ACK؟ عندما يتلقى العبد الدلتا ، التي تم تمييزها بواسطة lsn الرئيسي ومعرفها ، فإنه استجابة لذلك يرسل حزمة ACK خاصة ، حيث يحزم vclock المحلي بعد تطبيق هذه العملية. دعونا نرى كيف يمكن لهذا العمل.
لدينا سيد الذي أجرى 4 عمليات في نفسه. لنفترض أنه في وقت ما تلقى العبد الرقيق الأسطر الثلاثة الأولى وزاد عدد vclock إلى {3.0}.
ACK لم يحن بعد. بعد تلقي هذه الأسطر الثلاثة ، يرسل العبد حزمة ACK التي قام بتثبيتها في الوقت الذي تم إرسال الحزمة إليه. اسمح للسيد الرقيق بإرسال سطر آخر في نفس الفترة الزمنية ، أي أن vclock الخاص بالعبد قد زاد. بناءً على ذلك ، يعرف السيد رقم 1 بالتأكيد أن العمليات الثلاث الأولى التي قام بها قد تم تطبيقها بالفعل على هذا العبد. يتم تخزين هذه الحالات لجميع العبيد الذين يعملون معهم ؛ فهم مستقلون تمامًا.
وفي النهاية ، يستجيب العبد بحزمة ACK الرابعة. بعد ذلك ، يعلم السيد أن الرقيق متزامن معه.
يمكن استخدام هذه الآلية في رمز التطبيق. عندما تقوم بإجراء عملية ، فأنت لا تتعرف على الفور على المستخدم ، ولكنك تتصل أولاً بوظيفة خاصة. ينتظر أن يكون العبد lsn المعروف للسيد مساوياً لـ lsn سيدك في وقت اكتمال الالتزام. لذلك لا تحتاج إلى الانتظار للتزامن الكامل ، فقط انتظر اللحظة المذكورة.
لنفترض أن مكالمتنا الأولى غيرت ثلاثة أسطر ، وأن المكالمة الثانية غيرت أحدها. بعد المكالمة الأولى ، تريد التأكد من مزامنة البيانات. الحالة الموضحة أعلاه تعني بالفعل أن المكالمة الأولى كانت متزامنة على عبد واحد على الأقل.
أينما تبحث بالضبط عن معلومات حول هذا الموضوع ، سننظر في القسم التالي.
الرصد
عندما يكون النسخ المتماثل متزامنًا ، تكون المراقبة بسيطة جدًا: إذا تفكك ، يتم إصدار الأخطاء لعملياتك. وإذا كان النسخ المتماثل غير متزامن ، يصبح الموقف مربكًا. سيد يجيبك أن كل شيء على ما يرام ، وأنها تعمل ، وقبول ، وكتب. ولكن في الوقت نفسه ، فإن جميع النسخ المتماثلة قد ماتت ، والبيانات لا تحتوي على تكرار ، وإذا فقدت السيد ، فسوف تفقد البيانات. لذلك ، أريد حقًا مراقبة الكتلة ، وفهم ما يحدث مع النسخ المتماثل غير المتزامن ، حيث توجد النسخ المتماثلة ، في الحالة التي تكون فيها.
للمراقبة الأساسية ، يحتوي Tarantool على كيان box.info. يجدر الاتصال به في وحدة التحكم ، حيث سترى بيانات مثيرة للاهتمام.
id: 1 uuid: c35b285c-c5b1-4bbe-83b1-b825eb594aa4 lsn : 5 vclock : {2: 1, 1: 5} replication : 1: id: 1 uuid : c35b285c -c5b1 -4 bbe -83b1 - b825eb594aa4 lsn : 5 2: id: 2 uuid : 37 b12cb7 -d324 -4 d75 -b428 - cde92c18e708 lsn : 1 upstream : status : follow idle : 0.30358312401222 peer : lag: 3.6001205444336 e -05 downstream : vclock : {2: 1, 1: 5}
المتري الأكثر أهمية هو معرف
id . في هذه الحالة ، 1 يعني أنه سيتم تخزين lsn هذا المعلم في الموضع الأول في كل vclock. شيء مفيد جدا. إذا كان لديك تعارض مع JOIN ، فيمكنك التمييز بين معلم رئيسي وآخر من خلال معرفات فريدة. أيضا ، الكميات المحلية تشمل كميات مثل lsn. هذا هو رقم السطر الأخير الذي تم تنفيذه بواسطة هذا الأستاذ وكتابته في سجله. في مثالنا ، أجرى السيد الأول خمس عمليات. Vclock هو حالة العمليات التي يعرف أنه قدم طلبًا لنفسه. وأخيراً ، بالنسبة للسيد رقم 2 ، أجرى إحدى عمليات النسخ المتماثل له.
بعد مؤشرات الحالة المحلية ، يمكنك معرفة ما يعرفه هذا المثيل حول حالة النسخ المتماثل للكتلة ؛ ولهذا ، يوجد قسم
replication . يسرد كافة العقد الكتلة المعروفة للمثيل ، بما في ذلك نفسه. العقدة الأولى لها المعرف 1 ، معرف يتوافق مع المثيل الحالي. العقدة الثانية لها المعرف 2 ، lsn 1 لها يتوافق مع lsn المكتوب إلى vclock. في هذه الحالة ، فإننا نعتبر النسخ المتماثل الرئيسي-الرئيسي ، عندما يكون master رقم 1 هو كلا رئيسي للعقدة الثانية من الكتلة والعبد الخاص به ، أي يتبعه.
- جوهر
upstream . تعني السمة status follow أن master 1 يتبع master 2. Idle هو الوقت الذي انقضى محليًا منذ آخر تفاعل مع هذا المعلم. نحن لا نرسل دفقًا مستمرًا ، يرسل master دلتا فقط عند حدوث تغييرات عليها. عندما نرسل نوعًا من ACK ، فإننا نتواصل أيضًا. من الواضح ، إذا أصبح الخمول كبيرًا (بالثواني والدقائق والساعات) ، فهناك خطأ ما. - سمة
lag . تحدثنا عن تأخر. بالإضافة إلى lsn server id يتم تمييز كل عملية في السجل أيضًا بطابع زمني - بالتوقيت المحلي الذي تم خلاله تسجيل هذه العملية في vclock على الرئيسي الذي قام بتنفيذها. في الوقت نفسه ، يقارن Slave طابعه الزمني المحلي مع الطابع الزمني للدلتا الذي تلقاه. الطوابع الزمنية الحالية الأخيرة التي وردت للخط الأخير ، يعرض الرقيق في المراقبة. - السمة
downstream . إنه يوضح ما يعرفه السيد عن عبده الخاص. هذا هو ACK الذي يرسله العبد إليه. downstream الموضح أعلاه يعني أن آخر مرة أرسل فيها عبده ، الملقب سيدًا في الرقم 2 ، صوته ، الذي كان 5.1. يعلم هذا السيد أن جميع خطوطه الخمسة ، التي أكملها في مكانه ، غادرت إلى عقدة أخرى.
خسارة XLOG
النظر في الوضع مع سقوط السيد.
lsn : 0 id: 3 replication : 1: <...> upstream : status: disconnected peer : lag: 3.9100646972656 e -05 idle: 1602.836148153 message: connect, called on fd 13, aka [::1]:37960 2: <...> upstream : status : follow idle : 0.65611373598222 peer : lag: 1.9550323486328 e -05 3: <...> vclock : {2: 2, 1: 5}
بادئ ذي بدء ، ستتغير الحالة.
Lag لا يتغير لأن الخط الذي طبقناه ظل كما هو ، لم نحصل على أي خطوط جديدة. في نفس الوقت ، ينمو
idle ، في هذه الحالة يكون مساوياً بالفعل 1602 ثانية ، فقد مات الكثير من الوقت. ونحن نرى بعض رسائل الخطأ: لا يوجد اتصال بالشبكة.
ما يجب القيام به في وضع مماثل؟ لقد اكتشفنا ما حدث مع سيدنا ، وجذب المسؤول ، وإعادة تشغيل الخادم ، ورفع العقدة. يتم إجراء النسخ المتماثل المتكرر ، وعندما يدخل master النظام ، فإننا نتصل به ، ونشترك في XLOG ، ونحصل عليه لأنفسنا وتستقر المجموعة.
ولكن هناك مشكلة واحدة صغيرة. تخيل أن لدينا عبدًا ، والذي لسبب ما كان مغلقًا وكان غائبًا لفترة طويلة. خلال هذا الوقت ، قام المعلم ، الذي قام بخدمته ، بحذف XLOG. على سبيل المثال ، القرص ممتلئ ، قام جامع البيانات المهملة بجمع السجلات. كيف يمكن لعبد عائد أن يستمر؟ لا مفر لأن السجلات التي يحتاجها لتطبيق ليتم مزامنته مع الكتلة قد ولت ولا يوجد مكان يأخذ منها. في هذه الحالة ، سنرى خطأً مثيرًا للاهتمام: لم تعد الحالة غير
disconnected ، ولكن تم
stopped . ورسالة محددة: لا يوجد ملف سجل مطابقة مثل LSN.
id: 3 replication : 1: <...> upstream : peer : status: stopped lag : 0.0001683235168457 idle : 9.4331328970147 message: 'Missing .xlog file between LSN 7 1: 5, 2: 2 and 8 1: 6, 2: 2' 2: <...> 3: <...> vclock : {2: 2, 1: 5}
في الواقع ، فإن الوضع ليس قاتلا دائما. لنفترض أن لدينا أكثر من سيدين ، ولا تزال هذه السجلات محفوظة لبعضها. نحن نصبهم على جميع الأسياد في وقت واحد ، ولا نخزنهم على واحد فقط. ثم اتضح أن هذه النسخة المتماثلة ، التي تتصل بجميع الأساتذة الذين تعرفهم ، على بعضها ستجد السجلات التي تحتاجها. ستقوم بتنفيذ جميع هذه العمليات في المنزل ، وستزداد سرعة الفيديو الخاصة بها ، وستصل إلى الوضع الحالي للمجموعة. بعد ذلك ، يمكنك محاولة إعادة الاتصال.
إذا لم تكن هناك سجلات على الإطلاق ، فلا يمكننا متابعة النسخة المتماثلة. يبقى فقط لإعادة تهيئة. تذكر معرفها الفريد ، يمكنك كتابته على قطعة من الورق أو في ملف. ثم نقوم بتنظيف النسخة المتماثلة محليًا: احذف صورها وسجلاتها وما إلى ذلك. بعد ذلك ، أعد توصيل النسخة المتماثلة بنفس UUID الذي كانت به.
تجريد الكتلة أو إعادة استخدام UUID
box.cfg{instance_uuid = uuid} المتماثلة الجديدة:
box.cfg{instance_uuid = uuid} .
, . UUID space cluster, . , . UUID, master, JOIN, , UUID, , .
, UUID , space cluster , . . , , .
, - . , . , , .
Tarantool .
replication_connect_quorum: 2
replication_connect_timeout: 30
replication_sync_lag: 0.1, , , , , , master' 0,1 . 30 . , . 0,1 . , .
Keep alive
, ip tables drop. , - 30 30 , , . , keep alive-.
keep alive- :
box.cfg.replication_timeout .
master' , keep alive-, , . 4 master slave keep alive- , . master'.
, . 6 , 5 . 10 , 9 . .
, , . , master', . - . .
6 , 3. , . , 5 , 3 .
, :
, Telegram-, . , GitHub, .