Предоставяне на повече MySQL клъстер алгоритъм и арбитраж - член на
MySQL Cluster - решението за изграждане на устойчиви на грешки системи. В увода, кратко описание на основните понятия, по-подробна информация в документацията. Описани по-долу важи за версията на MySQL Cluster 5.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. Неспазването на всички възли на една група води до провал на клъстера.
- SQL възел (или API-възел) - изпълним метод Mysqld. В SQL-възел приема клиентски свързвания и достъп до данните за възлите на данните. В допълнение, всеки SQL-възел може да съхранява собствените си не-NDB маса (MyISAM, InnoDB.), Като че ли това не е част от клъстера.
- Управление възел (управление-възел) - изпълним процес ndbmgmd. Отговорно за конфигурацията на клъстер, всеки възел има достъп до възел за управление, когато връзката с клъстер. Тя не контролира сделки и други актуални въпроси, и се съсредоточава изключително върху конфигурацията. Тя консумира малко системни ресурси, така че често се поставя на една и съща физическа сървър на друг възел на. В случай на неуспех на контролните възли, клъстера ще продължи нормалната работа, но няма да бъде в състояние да рестартирате възел. Конфигурацията може да съдържа един или повече контролни възли.
Арбитър и арбитраж algortimy
Един клъстър винаги е арбитър. Арбитърът, назначен от стартиране на клъстера и може да се променя в рамките на процедурата по промяна арбитър. От назначаването на арбитър, като промяната може да се намери в трупите на клъстера. В стандартната конфигурация, арбитърът е възел за управление, но това не е непременно така. Един арбитър може да бъде всеки управление или SQL възел. Тези възли в конфигурация могат да бъдат определени параметър ArbitrationRank (арбитър ранг); стойности на параметри са: 0 - възел никога няма да бъде арбитър, 1 - възел ще бъде арбитър на висок приоритет; 2 - Нода ще стане арбитъра само ако няма кандидати с висока priritetom. Във всеки момент в клъстер само един арбитър.
Деактивирането възел група, разделена на мозъка
Арбитърът е длъжен в ситуация, в клъстера изключен няколко възела. Нека клъстера са физически разделени в 2 броя (например, в резултат на повреда на мрежата marshrutirizatora). Възможно е, че всяко парче ще съхранява всички данни за касетъчните (т.е. най-малко един възел във всяка група). Всяка част ще действа като пълен клъстер, което води до нарушаване на целостта на данните (например, някои клиенти ще работят с една филия, а някои - в друга). Тази ситуация е потенциално опасно и се нарича разделен на мозъка.
арбитраж алгоритъм
арбитраж алгоритъм е доста проста. Той започва да работи веднага след откриването на фрагментация на всеки работен касетъчни фрагменти възел данни.
- Виждам поне един възел на данни от всяка група (с други думи - дали видимата част на клъстера всички данни)? Ако не - изключите. Ако отговорът е да, продължете алгоритъм
- Има ли някой от възлите данни на отпаднали ученици в един възел във всяка група (с други думи - дали втората част на всички данни)? Ако не - тогава се изключва втората част на член 1, че мога да продължа. Ако е така, продължи алгоритъма.
- Попитайте арбитър. Ако съдията не може - изключите. Ако арбитърът е достъпно, за да разберете дали се намирам аз в текущата конфигурация - ако не се изключи, и ако е така - да се продължи работата
Смяна на арбитър
Ако в резултат на фрагментация изчезна арбитър, след арбитраж алгоритъм, възли избират нов арбитър. Алгоритъмът за избор сега е проста - възел избира най-ниската номерирана (nodeid), като между старши ArbitrationRank.
Защо е конфигурацията на двете лица, не е okazoustoychivoy?
Помислете за следната конфигурация, postoennuyu на две физически машини:
- Първият сървър - възел данни 1, на SQL възел-1, контролния възел 1
- Вторият сървъра - възел данни 2, на SQL възел-2 (също така възможно да се контролира възел 2)
Значение NoOfReplicas = 2 осигурява съкращения данни; както възли са част от една и съща група. На пръв поглед изглежда, че otkzoustoychiva на конфигурация, но на практика не е така. При стартиране на клъстер арбитър първо ще контролен възел. Представете си ситуация, в която е повреден първия сървър (например изключване, изгоряла мрежова карта или дефектен пристанище в marshrutirizatore). През втория възел данни арбитраж работа на алгоритъма:
- Виж, ако един възел във всяка група? Да, само една група от този възел - I.
- Това става otklyuchivashayasya част от пълен набор от данни? Да, възел данни 1 съдържа копие на данните.
- Попитайте арбитър. Арбитърът не е налична. Изключване.
Ние виждаме, че провалът на един сървър забранява цялото обединение. Същото ще се случи в конфигурация с три сървъри и NoOfReplicas = 3, когато сървърът е изключена, съдържащ арбитър.
Един прост пример на конфигурация отказоустойчива
Нека читателят се уверите, че следната конфигурация е стабилен във връзка с провала на някой от трите физически сървъри:
- Първият сървър - възел данни 1, SQL-1 възел (ArbitrationRank = 0), (NoOfReplicas = 2)
- Вторият сървъра - данни възел 2, SQL-възел 2 (ArbitrationRank = 0), (NoOfReplicas = 2)
- На трето място на сървъра - управляващ възел (ArbitrationRank = 2)
съкращение на данни не е гаранция за преодоляване на срив. Винаги предтестовата готовност конфигурация с помощта на описания по-горе agloritma или чрез физически Изключете сървъри.