حلول التوسع لـ MySQL (النسخ المتماثل، التجميع)

Question

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

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

Answer 1

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

وهذا هو ما كنت قد تمكنت من تجميع:  

التجميع

وتجميع بالمعنى العام بتوزيع الحمل عبر العديد من الخوادم التي تظهر إلى تطبيق خارجي كما ملقم واحد.

الخلية NDB العنقودية

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

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

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

Continuent سيكويا

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

ولقد قرأت بعض الأشياء الجيدة على ذلك، وعموما يبدو واعدا جدا.

الاتحاد

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

.

النسخ المتماثل وتحميل موازنة

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

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

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

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

عملية التجزئة وpartioning

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

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

أخرى

أبو الهول

أبو الهول هو محرك بحث في النصوص، والتي يمكن استخدامها لأكثر بكثير من عمليات البحث الاختبار. بالنسبة للعديد من الاستفسارات وهو أسرع بكثير من الخلية (وخاصة لتجميع والفرز)، ويمكن الاستعلام الأنظمة البعيدة في نفس الوقت وتجميع النتائج - التي جعلها مفيدة جدا في الاستخدام مع عملية التجزئة.

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

موجز

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

وانا ذاهب أيضا لإعطاء تسديدة لContinuent سيكويا ومعرفة ما اذا كان يمكن القيام به حقا ما يعد به لأنه سوف تنطوي على أقل قدر من التغييرات على رمز التطبيق.

Answer 2

تنصل:لم أستخدم MySQL Cluster، لذلك سأعتمد فقط على ما سمعته.

MySQL Cluster هو حل HA (التوفر العالي).إنه سريع، لأنه كله في الذاكرة، ولكن نقطة البيع الحقيقية هي التوفر.ليس هناك نقطة واحدة من الفشل.من ناحية أخرى، مع النسخ المتماثل، إذا تعطل البرنامج الرئيسي، فيجب عليك التبديل فعليًا إلى النسخة المتماثلة، وقد يكون هناك قدر صغير من وقت التوقف.(على الرغم من أن حل DRBD هو بديل آخر يتمتع بتوفر عالٍ)

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

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

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

Answer 3

هناك بعض المناقشات الجيدة حول كيفية قيام الأشخاص الذين يحافظون على drupal.org بتنظيم خوادم قواعد البيانات الخاصة بهم:

• مدونة يجف Buytaert
• مدونة عادات العمل

كلاهما من عام 2007، لذلك قد يكون دعم المجموعات أقوى الآن، ولكن في ذلك الوقت اختاروا النسخ المتماثل.

Answer 4

والشيء باردة حول القيام النسخ المتماثل أنه من السهل. مجرد انشاء 2 صناديق الخلية، تغيير serverID على المربع الثاني، ثم أشر المربع الثاني في أول استخدام للسيد تغيير قيادة.

وهنا هو الرقيق عينة ذات الصلة my.cnf التكوين

#
#       Log names
#

log-bin=binlog
relay-log=relaylog
log-error=errors.log

#
#       Log tuning
#

sync_binlog = 1
binlog_cache_size = 1M

#
#       Replication rules (what are we interested in listening for...)
#
#       In our replicants, we are interested in ANYTHING that isn't a permission table thing
#

replicate-ignore-db =      mysql
replicate-wild-ignore-table=mysql.%

#
#       Replication server ID
#

server-id      =        2

وهكذا تأكد من كل الرقيق يحصل على serverID بمقدار 1 (الرقيق القادمة حتى يتم الخادم 3)

وانشاء اسم المستخدم وكلمة المرور التي عبدا يمكن الاتصال على، ثم اركض تغيير رئيسية لMASTER_HOST = 'x.x.x.x'؛ تغيير رئيسية لMASTER_PASSWORD = "كسكسكسكسكس"؛

ووهلم جرا.

وأخيرا، تشغيل "بدء الرقيق"؛

وحتى يأتي عبدك ويبدأ النسخ المتماثل. هاه حلوة!

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

ويمكنك التحقق من حالة الرقيق عن طريق تشغيل:

وإظهار حالة الرقيق \ G

والمتعة معها .. سهلة سووو ...

Answer 5

وحين نفعل الدراسة توافر عالية جئت عبر العديد من الحلول، وربما في حالتنا الذي كان أكثر إرسال النظام المكثف، وجدت مجموعة DRBD أفضل من الكتلة NDB، حيث أنه يوفر أكثر عدد من المعاملات في الثانية الواحدة.

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

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

وحاولت سرد بعض من التعلم فعلت خلال إنشاء الكتلة DRBD على HTTP: / /www.techiegyan.com/؟p=132

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

وأنا حتى الآن لاكتشاف التكوين ماجستير ماجستير في DRBD. سيتم تحديث كما وعندما أحصل على النجاح في ذلك.

وشكرا.

Answer 6

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

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

باختصار، نقوم بتشغيل mnesia أعلى مجموعة MySQL.يمكن لمجموعة MySQL التعامل مع مجموعات كبيرة من البيانات، ويمكن أن تنمو قاعدة البيانات إلى 50 جيجابايت أو أكثر.لدينا الذاكرة التي تعمل على تشغيل إرلانج/مكتب المدعي العام التطبيقات. جافا و بي أتش بي الوصول إلى البيانات من Mnesia عبر تخصيصها استراحة (حديثاً تقطير) واجهات برمجة التطبيقات التي تستخدم JSON وXML كتنسيقات تبادل.

قامت طبقة الوصول إلى البيانات بتجريد الوصول إلى البيانات في Mnesia والبيانات القديمة المشحونة في MySQL Cluster إذا لزم الأمر.Mnesia موجود هنا بشكل أساسي لتشغيل تطبيقات Erlang/OTP. وبمجرد ازدحامه بالبيانات، نقوم بإلقائها في مجموعة MYSQL.يمكن لطبقة الوصول إلى البيانات الوصول إلى كل من البيانات الموجودة في mnesia وMySQL في واجهة برمجة تطبيقات مجردة نيابة عن جميع التطبيقات.

ما يمكنني قوله هنا هو أن Mnesia كان الخيار الأفضل بالنسبة لنا.الجداول مجزأة ومفهرسة بدرجة عالية، وأداء الاستعلامات جيد جدًا ويتم نسخ قاعدة البيانات عبر موقعين متصلين عبر نفق.

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

لقد استفدنا من بنية بيانات Erlang المعقدة وحقيقة أن Mnesia يمكنها استيعابها دون تغيير.تعد تطبيقات Erlang /OTP أكثر كفاءة من جميع التطبيقات الأخرى باللغات القديمة ومع نظامنا نخطط لترحيلها كلها إلى تقنية Erlang/OTP.من Erlang، يمكننا الوصول بسهولة إلى البيانات من MySQL Cluster وتنفيذ الاستعلامات على خوادمها بشكل رائع للغاية، في الواقع، استنتجنا أن Erlang/OTP يمكنه استخدام موارد خادم MySQL بشكل كامل بسبب التزامن الهائل (Erlang).

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

أنصحك بمراجعة برنامج mnesia ومن يدري فقد يلبي عددًا من احتياجات التوزيع أو النسخ الخاصة بك.

Answer 7

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

Answer 8

يمنعنا القيد "في الذاكرة" من استخدام مجموعة MySQL لما يقرب من 50 جيجا بايت من البيانات، لذلك نحن نستخدم DRBD بالإضافة إلى Linux Heartbeat.

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

Answer 9

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

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

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

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