Предоставяне на повече MySQL клъстер алгоритъм и арбитраж - член на

MySQL Cluster - решението за изграждане на устойчиви на грешки системи. В увода, кратко описание на основните понятия, по-подробна информация в документацията. Описани по-долу важи за версията на MySQL Cluster 5.1, който се намира в момента на освобождаване на членове на етапа на кандидат освобождаване.

Нода ще се нарича логическо сървъра представляваща клъстера. Но един физически сървър може да бъде поставен няколко възела. В групата от три основни типа възли:

  1. възел данни (NDB възел) - изпълним метод ndbd, отговорен за съхранение на данни фрагмент в клъстер. клъстер параметър Важно NoOfReplicas (броят на копия) - броят на възлите на данни, в която се съхранява всеки отделен фрагмент. Общият брой на възли от данни трябва да е кратен на броя на копия. Група възли - брой възел (броят на възлите в групата е броят на копия), който съхранява същата информация. Например NoOfReplicas = 2, броят на възлите - 6. Всяка маса е разделена на 6 части (хеш на първичен ключ), изброят им F1, F2, F3, F4, F5, F6. 6 възли (D1, D2, D3, D4, D5, D6) 3 групи - всяка група на първия възел (D1, D2) съхранява фрагментите F1, F2; възли на втората група D3, D4 съхранява фрагменти F3, F4; възлите на третата група D5, D6 съхраняват фрагменти F5, F6. Неспазването на всички възли на една група води до провал на клъстера.
  2. SQL възел (или API-възел) - изпълним метод Mysqld. В SQL-възел приема клиентски свързвания и достъп до данните за възлите на данните. В допълнение, всеки SQL-възел може да съхранява собствените си не-NDB маса (MyISAM, InnoDB.), Като че ли това не е част от клъстера.
  3. Управление възел (управление-възел) - изпълним процес ndbmgmd. Отговорно за конфигурацията на клъстер, всеки възел има достъп до възел за управление, когато връзката с клъстер. Тя не контролира сделки и други актуални въпроси, и се съсредоточава изключително върху конфигурацията. Тя консумира малко системни ресурси, така че често се поставя на една и съща физическа сървър на друг възел на. В случай на неуспех на контролните възли, клъстера ще продължи нормалната работа, но няма да бъде в състояние да рестартирате възел. Конфигурацията може да съдържа един или повече контролни възли.

Арбитър и арбитраж algortimy

Един клъстър винаги е арбитър. Арбитърът, назначен от стартиране на клъстера и може да се променя в рамките на процедурата по промяна арбитър. От назначаването на арбитър, като промяната може да се намери в трупите на клъстера. В стандартната конфигурация, арбитърът е възел за управление, но това не е непременно така. Един арбитър може да бъде всеки управление или SQL възел. Тези възли в конфигурация могат да бъдат определени параметър ArbitrationRank (арбитър ранг); стойности на параметри са: 0 - възел никога няма да бъде арбитър, 1 - възел ще бъде арбитър на висок приоритет; 2 - Нода ще стане арбитъра само ако няма кандидати с висока priritetom. Във всеки момент в клъстер само един арбитър.

Деактивирането възел група, разделена на мозъка

Арбитърът е длъжен в ситуация, в клъстера изключен няколко възела. Нека клъстера са физически разделени в 2 броя (например, в резултат на повреда на мрежата marshrutirizatora). Възможно е, че всяко парче ще съхранява всички данни за касетъчните (т.е. най-малко един възел във всяка група). Всяка част ще действа като пълен клъстер, което води до нарушаване на целостта на данните (например, някои клиенти ще работят с една филия, а някои - в друга). Тази ситуация е потенциално опасно и се нарича разделен на мозъка.

арбитраж алгоритъм

арбитраж алгоритъм е доста проста. Той започва да работи веднага след откриването на фрагментация на всеки работен касетъчни фрагменти възел данни.

  1. Виждам поне един възел на данни от всяка група (с други думи - дали видимата част на клъстера всички данни)? Ако не - изключите. Ако отговорът е да, продължете алгоритъм
  2. Има ли някой от възлите данни на отпаднали ученици в един възел във всяка група (с други думи - дали втората част на всички данни)? Ако не - тогава се изключва втората част на член 1, че мога да продължа. Ако е така, продължи алгоритъма.
  3. Попитайте арбитър. Ако съдията не може - изключите. Ако арбитърът е достъпно, за да разберете дали се намирам аз в текущата конфигурация - ако не се изключи, и ако е така - да се продължи работата

Смяна на арбитър

Ако в резултат на фрагментация изчезна арбитър, след арбитраж алгоритъм, възли избират нов арбитър. Алгоритъмът за избор сега е проста - възел избира най-ниската номерирана (nodeid), като между старши ArbitrationRank.

Защо е конфигурацията на двете лица, не е okazoustoychivoy?

Помислете за следната конфигурация, postoennuyu на две физически машини:

  • Първият сървър - възел данни 1, на SQL възел-1, контролния възел 1
  • Вторият сървъра - възел данни 2, на SQL възел-2 (също така възможно да се контролира възел 2)

Значение NoOfReplicas = 2 осигурява съкращения данни; както възли са част от една и съща група. На пръв поглед изглежда, че otkzoustoychiva на конфигурация, но на практика не е така. При стартиране на клъстер арбитър първо ще контролен възел. Представете си ситуация, в която е повреден първия сървър (например изключване, изгоряла мрежова карта или дефектен пристанище в marshrutirizatore). През втория възел данни арбитраж работа на алгоритъма:

  1. Виж, ако един възел във всяка група? Да, само една група от този възел - I.
  2. Това става otklyuchivashayasya част от пълен набор от данни? Да, възел данни 1 съдържа копие на данните.
  3. Попитайте арбитър. Арбитърът не е налична. Изключване.

Ние виждаме, че провалът на един сървър забранява цялото обединение. Същото ще се случи в конфигурация с три сървъри и NoOfReplicas = 3, когато сървърът е изключена, съдържащ арбитър.

Един прост пример на конфигурация отказоустойчива

Нека читателят се уверите, че следната конфигурация е стабилен във връзка с провала на някой от трите физически сървъри:

  • Първият сървър - възел данни 1, SQL-1 възел (ArbitrationRank = 0), (NoOfReplicas = 2)
  • Вторият сървъра - данни възел 2, SQL-възел 2 (ArbitrationRank = 0), (NoOfReplicas = 2)
  • На трето място на сървъра - управляващ възел (ArbitrationRank = 2)

съкращение на данни не е гаранция за преодоляване на срив. Винаги предтестовата готовност конфигурация с помощта на описания по-горе agloritma или чрез физически Изключете сървъри.