اسمي فلاديسلاف ، أشارك في تطوير Tarantool - DBMS وخادم التطبيقات في زجاجة واحدة. واليوم سوف أخبركم كيف طبقنا القياس الأفقي في تارانتول باستخدام وحدة VShard .

أولاً ، نظرية صغيرة.

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

تقسم المشاركة إلى نوعين: التقسيم حسب النطاقات والتقسيم بالتجزئة.

عند المشاركة مع النطاقات ، فإننا نحسب بعض مفتاح shard من كل سجل في الكتلة. يتم عرض مفاتيح القشرة هذه على خط مستقيم ، والذي ينقسم إلى نطاقات نضيفها إلى العقد المادية المختلفة.

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

سأتحدث عن القياس الأفقي باستخدام تقسيم التجزئة.

التنفيذ السابق

أول وحدة قياس أفقي كانت لدينا هي Tarantool Shard . هذا هو عملية مشاركة بسيطة للغاية من خلال التجزئة ، والتي تأخذ بعين الاعتبار مفتاح shard من المفتاح الأساسي لجميع الإدخالات في الكتلة.

function shard_function(primary_key) return guava(crc32(primary_key), shard_count) end 

ولكن بعد ذلك نشأت مهمة لم يتمكن Tarantool Shard من التعامل معها لثلاثة أسباب أساسية.

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

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

 format = {{'id', 'unsigned'}, {'email', 'string'}} box.schema.create_space('customer', {format = format}) format = {{'id', 'unsigned'}, {'customer_id', 'unsigned'}, {'balance', 'number'}} box.schema.create_space('account', {format = format}) 

في المثال أعلاه ، لا يمكن بسهولة مطابقة حقول id مع الحسابات والعملاء. ترتبط من خلال حقل الحساب customer_id id customer_id . سيؤدي حقل id نفسه إلى كسر تفرد مفتاح الحساب الأساسي. وبطريقة أخرى Shard غير قادر على قشرة.

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

ميزة أخرى من Tarantool Shard هي أنه عندما تفشل بعض العقد في مجموعات النسخ المتماثلة ، فإنها تظهر ضعف إمكانية قراءة القراءة .

حل جديد

لحل المشكلات الثلاث الموصوفة ، أنشأنا Tarantool VShard . يتمثل الاختلاف الرئيسي في أن مستوى تخزين البيانات يكون ظاهريًا: تظهر المستودعات الافتراضية أعلى المخزونات المادية ، ويتم توزيع السجلات فيما بينها. تسمى هذه المستودعات bucket'ami. لا يحتاج المستخدم إلى التفكير في أي عقدة تكمن فيها. الجرافة عبارة عن وحدة من البيانات الذرية غير القابلة للتجزئة ، كما هو الحال في التقسيم الكلاسيكي الواحد. يقوم VShard دائمًا بتخزين الجرافة بأكملها على عقدة فعلية واحدة وخلال إعادة المشاركة ، يقوم بنقل جميع البيانات الخاصة بالجرد الواحد تلقائيًا. بسبب هذا ، يتم توفير محلية. نحتاج فقط إلى وضع البيانات في مجموعة واحدة ، ويمكننا دائمًا التأكد من أن هذه البيانات سوف تترافق مع أي تغييرات في المجموعة.



كيف يمكنني وضع البيانات في مجموعة واحدة؟ في المخطط الذي قدمناه مسبقًا لعميل البنك ، سنضيف bucket id إلى الجداول وفقًا للحقل الجديد. إذا كانت البيانات المرتبطة هي نفسها ، ستكون السجلات في نفس المجموعة. الميزة هي أنه يمكننا تخزين هذه السجلات بنفس bucket id في فراغات مختلفة ، وحتى في محركات مختلفة. bucket id توفير bucket id بغض النظر عن كيفية تخزين هذه السجلات.

 format = {{'id', 'unsigned'}, {'email', 'string'}, {'bucket_id', 'unsigned'}} box.schema.create_space('customer', {format = format}) format = {{'id', 'unsigned'}, {'customer_id', 'unsigned'}, {'balance', 'number'}, {'bucket_id', 'unsigned'}} box.schema.create_space('account', {format = format}) 

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

بفضل bucket'am والمحلية حسب bucket id يمكننا دائمًا قراءة البيانات من عقدة واحدة في طلب واحد ، بغض النظر عن حجم الكتلة.



تحتاج إلى حساب bucket id وتعيين نفس القيم بنفسك. بالنسبة للبعض ، هذه ميزة لشخص عيب. أعتبرها ميزة يمكنك من خلالها اختيار وظيفة حساب bucket id بنفسك.

ما هو الفرق الرئيسي بين المشاركة الكلاسيكية والمشاركة الافتراضية مع الجرافة؟

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

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

استخدام

لنفترض أننا اخترنا وظيفة bucket id الجرافات وصبنا الكثير من البيانات في المجموعة بحيث لم يكن هناك مساحة إضافية. الآن نريد إضافة العقد ، وبالتالي انتقلت البيانات إليهم بأنفسنا. في VShard ، يتم ذلك على النحو التالي. أولاً ، قم بتشغيل العقد الجديدة و Tarantools عليها ، ثم قم بتحديث تكوين VShard. فهو يصف جميع أعضاء المجموعة ، وجميع النسخ المتماثلة ، ومجموعات النسخ المتماثلة ، والماجستير ، ومعرفات المستخدمين المعينة ، وأكثر من ذلك بكثير. نضيف عقدًا جديدة للتكوين ، وباستخدام وظيفة VShard.storage.cfg ، نستخدمها في جميع عقد الكتلة.

 function create_user(email) local customer_id = next_id() local bucket_id = crc32(customer_id) box.space.customer:insert(customer_id, email, bucket_id) end function add_account(customer_id) local id = next_id() local bucket_id = crc32(customer_id) box.space.account:insert(id, customer_id, 0, bucket_id) end 

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



نظرًا لأن عدد المخازن الافتراضية لا يتغير - وتعتمد وظيفة shard فقط على هذه القيمة - يمكننا إضافة أكبر عدد ممكن من المخازن الفعلية دون إعادة حساب وظيفة shard.

كيف يتم توزيع البوكيتات بين المتاجر المادية بمفردها؟ عندما يتم استدعاء VShard.storage.cfg على إحدى العقد ، تستيقظ عملية إعادة التوازن. هذه عملية تحليلية تحسب التوازن المثالي في الكتلة. يذهب إلى جميع العقد المادية ، ويسأل من لديه عدد bucket'ov ، ويبني طرقًا لحركتهم من أجل متوسط ​​التوزيع. يرسل rebalancer الطرق إلى المخازن المزدحمة ، ويبدأون في إرسال الجردل. بعد بعض الوقت ، تصبح الكتلة متوازنة.

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

على سبيل المثال ، يبلغ وزن أحد المتاجر 100 ، والآخر لديه 200. ثم يخزن الأول أقل عددًا من الدلو مرتين. يرجى ملاحظة أنني أتحدث تحديدا عن نسبة الأوزان. المعاني المطلقة لها أي تأثير. يمكنك اختيار الأوزان بناءً على توزيع كتلة 100٪: يحتوي أحد المتاجر على 30٪ ، والآخر لديه 70٪. يمكنك أن تأخذ سعة التخزين بالجيجابايت كأساس ، أو يمكنك قياس الأوزان في عدد bucket'ov. الشيء الرئيسي هو مراقبة الموقف الذي تحتاجه.



مثل هذا النظام له تأثير جانبي مثير للاهتمام: إذا قمت بتعيين وزن صفري لبعض المتاجر ، فسوف يطلب الموازن من المتجر توزيع كل دلوته. بعد ذلك ، يمكنك إزالة مجموعة النسخ المتماثلة بالكامل من التكوين.

نقل الجرافة الذرية

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

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

قد يكون لديك أسئلة:

• ماذا سيحدث لتلك الطلبات التي عملت مع المجموعة عندما بدأت في نقلها؟
  
  هناك نوعان من الروابط في البيانات الوصفية لكل مجموعة: القراءة والكتابة. عندما يقدم المستخدم طلبًا إلى المجموعة ، يشير إلى كيفية عمله أو القراءة فقط أو قراءة الكتابة. لكل طلب ، يتم زيادة العداد المرجعي المقابل.
  
  لماذا أحتاج إلى عداد مرجعي لقراءة الطلبات؟ دعنا نقول نقل الجرافة بهدوء ، وهنا يأتي جامع القمامة ويريد حذف هذا الجرافة. يرى أن عدد الروابط أكبر من الصفر ، لذلك لا يمكنك حذفه. وعندما تتم معالجة الطلبات ، سيتمكن جامع البيانات المهملة من إكمال عمله.
  
  يضمن العداد المرجعي لطلبات الكتابة عدم بدء الجرافة في الاستمرار أثناء العمل مع طلب كتابة واحد على الأقل. لكن يمكن أن تأتي طلبات الكتابة باستمرار ، ومن ثم لن يتم نقل الجرافة أبدًا. والحقيقة هي أنه إذا أعرب الموازن عن رغبته في نقله ، فسيتم حظر طلبات التسجيل الجديدة ، وسينتظر النظام الحالي انتهاء بعض المهلة. إذا لم تكتمل الطلبات في الوقت المخصص ، سيبدأ النظام مرة أخرى في قبول طلبات الكتابة الجديدة ، مع تأجيل نقل المجموعة لبعض الوقت. وبالتالي ، فإن الموازن سيجعل محاولات النقل حتى تنجح واحدة.
  
  يحتوي VShard على API bucket_ref منخفض المستوى في حال كان لديك بعض الميزات عالية المستوى. إذا كنت تريد فعل شيء ما بنفسك ، فما عليك سوى الوصول إلى واجهة برمجة التطبيقات هذه من الرمز.
• هل من الممكن عدم حجب السجلات على الإطلاق؟
  
  هذا مستحيل. إذا كان الدلو يحتوي على بيانات مهمة تحتاج إلى وصول ثابت للكتابة ، فسيتعين عليك منع نقلها تمامًا. هناك bucket_pin وظيفة لهذا ، فإنه يعلق بإحكام بإحكام مجموعة النسخ المتماثلة الحالية ، ومنع نقلها. في هذه الحالة ، ستتمكن المجموعة المجاورة من التحرك دون قيود.
  
  
  
  هناك أداة أقوى من bucket_pin - حظر مجموعة النسخ المتماثلة. لم يعد يتم ذلك في التعليمات البرمجية ، ولكن من خلال التكوين. يحظر حظر حركة أي bucket'ov من هذه المجموعة المتماثلة set'a واستقبال جديدة. وفقًا لذلك ، ستكون جميع البيانات متاحة للتسجيل باستمرار.
  
  

VShard.router

يتكون VShard من وحدتين فرعيتين: VShard.storage و VShard.router. يمكن إنشاؤها بشكل مستقل وتوسيع نطاقها حتى في حالة واحدة. عند الوصول إلى نظام المجموعة ، لا نعرف مكان تواجد الجرافة ، وسيبحث VShard.router عن bucket id .

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



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

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

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

قراءة عدم الاستقرار

تذكر المشاكل التي واجهناها في البداية:

• لم يكن هناك مكان للبيانات. قررنا بإضافة bucket'ov.
• إعادة المشاركة أبطأت كل شيء وتباطأت. نفذت bucket'ami نقل البيانات الذرية تنفيذها ، تخلصت من إعادة فرز وظائف قشرة.
• قراءة غير مستقرة.

يتم حل المشكلة الأخيرة بواسطة VShard.router باستخدام النظام الفرعي لتجاوز قراءة تلقائية.

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



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

كيف يبدو في التكوين:



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

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

تسجيل عدم الاستقرار

نظرًا لأننا نتحدث عن تجاوز الفشل في القراءة ، فماذا عن فشل الكتابة عند تغيير المعالج؟ هنا ، VShard ليست وردية للغاية: لم يتم تنفيذ انتخاب سيد جديد فيها ، سيكون عليك القيام بذلك بنفسك. عندما نختارها بطريقة أو بأخرى ، من الضروري أن تتولى هذه الحالة الآن سلطة السيد. نقوم بتحديث التكوين عن طريق تحديد master = false للسيد القديم ، و master = true للتطبيق الجديد ، وتطبيقه عبر VShard.storage.cfg ولفه على وحدة التخزين. ثم كل شيء يحدث تلقائيا. توقف المعلم القديم عن قبول طلبات الكتابة ويبدأ في المزامنة مع الطلب الجديد ، لأنه قد تكون هناك بيانات تم تطبيقها بالفعل على المعلم القديم ، لكن الطلب الجديد لم يصل بعد. بعد ذلك ، يدخل الرئيسي الجديد الدور ويبدأ في قبول الطلبات ، ويصبح المعلم القديم نسخة طبق الأصل. هذه هي الطريقة التي يعمل بها فشل الكتابة في VShard.

 replicas = new_cfg.sharding[uud].replicas replicas[old_master_uuid].master = false replicas[new_master_uuid].master = true vshard.storage.cfg(new_cfg) 

كيف الآن لمتابعة كل هذه الأحداث المتنوعة؟

في الحالة العامة ، يكون VShard.storage.info - VShard.storage.info و VShard.router.info .

يعرض VShard.storage.info المعلومات في عدة أقسام.

 vshard.storage.info() --- - replicasets: <replicaset_2>: uuid: <replicaset_2> master: uri: storage@127.0.0.1:3303 <replicaset_1>: uuid: <replicaset_1> master: missing bucket: receiving: 0 active: 0 total: 0 garbage: 0 pinned: 0 sending: 0 status: 2 replication: status: slave Alerts: - ['MISSING_MASTER', 'Master is not configured for ''replicaset <replicaset_1>'] 

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

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

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

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

يحتوي VShard.router.info على نفس الأقسام ، لكنهم مختلفون قليلاً.

 vshard.router.info() --- - replicasets: <replicaset_2>: replica: &0 status: available uri: storage@127.0.0.1:3303 uuid: 1e02ae8a-afc0-4e91-ba34-843a356b8ed7 bucket: available_rw: 500 uuid: <replicaset_2> master: *0 <replicaset_1>: replica: &1 status: available uri: storage@127.0.0.1:3301 uuid: 8a274925-a26d-47fc-9e1b-af88ce939412 bucket: available_rw: 400 uuid: <replicaset_1> master: *1 bucket: unreachable: 0 available_ro: 800 unknown: 200 available_rw: 700 status: 1 alerts: - ['UNKNOWN_BUCKETS', '200 buckets are not discovered'] 

القسم الأول هو النسخ المتماثل. , : , replica set' , , , replica set' bucket' , .

Bucket bucket', ; bucket' ; , replica set'.

Alert, , , failover, bucket'.

, .

VShard?

— bucket'. int32_max ? bucket' — 30 16 . bucket', . bucket', bucket'. , .

— - bucket id . , - , bucket — . , bucket' , VShard bucket'. -, bucket' bucket, -. .

ملخص

Vshard :

• ;
• ;
• ;
• read failover;
• bucket'.

VShard . - . — . , . .

— lock-free bucket' . , bucket' . , .

— . : - , , ? .