MariaDB Server предлага асинхронна и синхронна репликация. Може да бъде настроен да има репликация от няколко източника или с настройка за няколко главни.
За приложение с интензивно четене и запис настройката главен-подчинен е често срещана, но може да се различава в зависимост от основния стек, необходим за изграждане на високодостъпна среда на база данни.
Наличието на настройка за репликация главен-подчинен може да не задоволи нуждите ви, особено в производствена среда. Самият MariaDB сървър (настройка главен-подчинен) не е достатъчен, за да предложи висока наличност, тъй като все още има една точка на отказ (SPOF).
MariaDB представи корпоративен продукт (MariaDB Platform) за справяне с този проблем с висока наличност. Той включва различни компоненти:корпоративна версия на MariaDB, MariaDB ColumnStore, MaxScale и олекотени MariaDB конектори. В сравнение с други доставчици със същото предложение за корпоративно решение, това може да бъде рентабилен вариант, но не всеки се нуждае от това ниво на сложност.
В този блог ще ви покажем как да използвате MariaDB Server, използвайки репликация във високодостъпна среда с опцията да избирате от използването на всички безплатни инструменти или нашия рентабилен софтуер за управление за изпълнение и наблюдавайте инфраструктурата на сървъра на MariaDB.
Настройка на топологията с висока достъпност на MariaDB
Обикновената настройка за топология главен-подчинен с MariaDB Server използва асинхронен или синхронен подход със само един главен получаващ запис, след което репликира промените си в подчинените точно както на диаграмата по-долу:
Но отново, това не обслужва висока наличност и има една точка на провал. Ако главният умре, тогава клиентът на приложението ви вече не функционира. Сега трябва да добавим в стека, за да имаме механизъм за автоматично отказване, за да избегнем SPOF и също така предлага балансиране на натоварването за разделяне на четене-записване и по кръгов начин. Така че засега ще имаме типа топология,
Сега тази топология служи за по-голяма безопасност по отношение на SPOF. MaxScale ще извърши разделянето на четене и запис върху възлите на базата данни от вашия главен срещу подчинените. MaxScale прави перфектен подход, когато се занимава с този тип настройка. MaxScale също има вградено автоматично откриване. Така че каквито и промени да настъпят в състоянието на възлите на вашата база данни, тя ще открие и ще действа съответно. MaxScale има наличност за преминаване към отказ или дори превключване. За да научите повече за неговия механизъм за преодоляване на отказ, прочетете предишния ни блог, който се занимава с механизма на превключване при отказ на MariaDB MaxScale.
Обърнете внимание, че механизмът за преодоляване при отказ на MaxScale с MariaDB Monitor също има своите ограничения. Най-добре се прилага само за настройка главен-подчинен без прекалено сложна настройка. Това означава, че настройката главен-главен не се поддържа. Въпреки това, MaxScale може да предложи повече неща. Той не само извършва някакво балансиране на натоварването, тъй като извършва разделяне на четене и запис, той има вграден SmartRouter, който изпраща заявката до най-ефективния възел. Въпреки че това не добавя функцията да бъдат високо достъпни, но помага на възлите да не се забиват в трафика и да се избегнат някои възли на базата данни от недостатъчна производителност, което може да доведе до изчакване или до напълно недостъпен сървър, причинен от продължителна активност с висока интензивност на ресурси .
Едно нещо като предупреждение за използването на MaxScale, те използват BSL (License за бизнес източник). Може да се наложи да прегледате ЧЗВ, преди да приемете този софтуер.
Друга опция за избор е използването на по-удобен подход. Може да бъде рентабилно за вас да изберете да използвате ClusterControl и да имате прокси сървъри в средата, като използвате HaProxy, MaxScale или ProxySQL, за които последният може да бъде конфигуриран от по-лека до конфигурация на по-производствено ниво, която извършва маршрутизиране на заявки, филтриране на заявки, защитна стена или сигурност. Вижте илюстрацията по-долу:
Сега върху тях седи ClusterControl. ClusterControl е настроен с висока наличност, т.е. CMON HA. Като алтернатива, прокси слоят може да бъде избран или от HaProxy - много лека опция за избор, MaxScale, както беше споменато по-горе, или ProxySQL, който има по-прецизен набор от параметри, ако искате повече гъвкавост и конфигурация, идеални за високо мащабирани производствена настройка. ClusterControl ще се справи с автоматичното откриване по отношение на здравословното състояние на възлите, особено на главния, който е основният възел, за да определи дали изисква отказ или не. Сега това може да бъде по-самодостатъчно, но добавя повече разходи поради редица възли, необходими за прилагане на тази настройка, както и използването на ClusterControl автоматично отказване, което се прилага за нашия предварителен и корпоративен лиценз. Но от друга страна, той ви осигурява цялата безопасност, сигурност и наблюдаемост към вашата инфраструктура на базата данни. Това всъщност е по-скоро евтина корпоративна реализация в сравнение с наличните решения на световния пазар.
Разгръщане на вашата MariaDB Master-Slave репликация за висока наличност
Да приемем, че имате съществуваща настройка главен-подчинен на MariaDB. За този пример ще използваме ClusterControl, използвайки безплатното издание на общността, което можете да инсталирате и използвате безплатно. Това просто прави работата ви лесна и бърза за настройка. За да направите това, просто трябва да импортирате съществуващия си MariaDB репликационен клъстер. Разгледайте предишния ни блог за това как да управлявате MariaDB с ClusterControl. За този блог първоначално имам следната настройка като моя MariaDB репликационен клъстер, както се вижда по-долу:
Сега нека използваме MaxScale тук като алтернативно решение от платформата MariaDB, която също предлага висока наличност. За да направите това, е много лесно да се използва с ClusterControl само с няколко щраквания, след което можете да настроите своя MaxScale, който да работи върху съществуващия ви MariaDB репликационен клъстер. За да направите това, просто отидете на Управление → Балансиране на натоварване → MaxScale и ще можете да настроите и предоставите подходящите стойности, както се вижда по-долу,
След това просто активирайте или щракнете върху опцията за отметка, за да изберете кои сървъри трябва да бъдат добавен като част от вашия мониторинг на MaxScale. Вижте по-долу,
Ако приемем, че имате повече от един възел MaxScale за добавяне, просто повторете същите стъпки.
Накрая, ще настроим Keepalived, за да поддържаме нашите MaxScale възли винаги достъпни, когато е необходимо. Това става много бързо само с прости стъпки с помощта на ClusterControl. Отново трябва да отидете на Управление → Балансиране на натоварване, но вместо това изберете Keepalived,
Както забелязахте, поставих моя Keepalived заедно с MaxScale на същия възел на моя роб (192.168.10.30). Докато, от друга страна, вторият (2-ри) Keepalived работи на 192.168.10.40 заедно с Maxscale на същия хост.
Резултатът от топологията е готов за производство, което може да ви осигури маршрутизиране на заявки, висока наличност и автоматично отказване, оборудвано с обширно наблюдение и наблюдаемост с помощта на ClusterControl. Вижте по-долу,
Заключение
Използването само на репликация на MariaDB сървър не ви предлага висока наличност. Разширяването и използването на инструменти на трети страни ще ви осигури високодостъпен стек от база данни, като не разчитате само на продуктите на MariaDB или дори да използвате платформата MariaDB.
Има начини да постигнете това и да го управлявате, за да бъде по-рентабилен. И все пак, има огромна разлика да се възползвате от тези решения, налични на пазара, като ClusterControl, тъй като ви осигурява скорост, по-малко караница и разбира се върховна наблюдаемост с актуални събития в реално време, не само за здравето но също и събитията, които се случват във вашия клъстер от база данни.
