В предишни публикации в блога разгледахме теми за наблюдение на вашия клъстер Galera, независимо дали е MySQL или MariaDB. Въпреки че версиите на технологиите не се различават много, MariaDB Cluster има някои големи промени от версия 10.4.2. В тази версия той поддържа Galera Cluster 4 и има някои страхотни нови функции, които ще разгледаме в тази публикация в блога.
За начинаещи, които все още не са запознати с MariaDB Cluster, е практически синхронен мулти-главен клъстер за MariaDB. Той е достъпен само за Linux и поддържа само XtraDB/InnoDB двигателите за съхранение (въпреки че има експериментална поддръжка за MyISAM - вижте системната променлива wsrep_replicate_myisam).
Софтуерът е пакетна технология, която се захранва от MariaDB Server, патч MySQL-wsrep за MySQL Server и MariaDB Server, разработен от Codership (поддържа Unix-подобна ОС), и библиотеката на доставчика на Galera wsrep.
Можете да сравните този продукт с MySQL Group Replication или с MySQL InnoDB Cluster, който има за цел да осигури висока наличност. (Въпреки че се различават по различни принципи и подходи за предоставяне на HA.)
Сега, когато разгледахме основите, в този блог ще предоставим съвети, които смятаме за полезни, когато наблюдаваме вашия MariaDB клъстер.
Основното на MariaDB клъстер
Когато започнете да използвате MariaDB Cluster, трябва да определите каква точно е вашата цел и защо сте избрали MariaDB Cluster на първо място. Първо трябва да разберете какви са функциите и техните предимства, когато използвате MariaDB Cluster. Причината да ги идентифицирате е, че те по същество са това, което трябва да се наблюдава и проверява, за да определите ефективността, нормалното здравословно състояние и дали работи в съответствие с вашите планове.
По същество се идентифицира като без подчинено забавяне, без загубени транзакции, мащабируемост при четене и по-малки латентности на клиента. Тогава могат да възникнат въпроси като, как не прави подчинено забавяне или загубени транзакции? Как прави четенето мащабируемо или с по-малки латентности от страна на клиента? Тези области са една от ключовите области, които трябва да търсите и наблюдавате, особено за тежка производствена употреба.
Въпреки че самият клъстер MariaDB може да бъде съответно персонализиран. Прилагането на промени в поведението по подразбиране, като pc.weight или pc.ignore_quorum, или дори използването на мултикаст с UDP за голям брой възли, може да повлияе на начина, по който наблюдавате естеството на вашия MariaDB клъстер. Но от друга страна, най-важните променливи на състоянието обикновено са вашата сребърна подплата тук, знаейки, че състоянието и потокът на вашия клъстер се справят добре или влошаването му, което показва възможен проблем, водещ до катастрофална повреда предварително.
Винаги наблюдавайте активността на сървъра си (мрежа, диск, зареждане, памет и процесор)
Наблюдението на активността на вашия сървър също може да бъде сложна задача, ако имате много сложен стек, който е преплетен в архитектурата на вашата база данни. Въпреки това, за MariaDB Cluster, винаги е най-добре вашите възли винаги да са настроени възможно най-отдадени, но опростени. Въпреки че това не ви ограничава да използвате всички резервни ресурси, по-долу са общите ключови области, които трябва да разгледате.
Мрежа
Galera Cluster 4 включва стрийминг репликация като една от основните функции и промени спрямо предишната версия. Тъй като стрийминг репликацията се справя с недостатъците, които имаше в предишните издания, но му позволява да управлява повече от 2GB набори за запис от Galera Cluster 4. Това позволява големите транзакции да бъдат фрагментирани и силно се препоръчва да се активира това само на ниво сесия. Това означава, че наблюдението на вашата мрежова активност е много важно и от решаващо значение за нормалната дейност на вашия MariaDB клъстер. Това ще ви помогне да определите кой възел е имал най-много или най-висок мрежов трафик въз основа на периода от време.
И как това ще ви помогне да подобрите местата, където са идентифицирани възли с най-висок мрежов трафик? Е, това ви предоставя място за подобрение с топологията на вашата база данни или архитектурния слой на вашия клъстер от база данни. Използването на балансьори на натоварване или прокси сървър на база данни ви позволява да конфигурирате проактивно трафика на вашата база данни, особено когато определяте кои конкретни записи да отидат до конкретен възел. Да кажем, от 3-те възела, един от тях е по-способен да обработва големи и големи заявки поради разлики с хардуерните спецификации. Това ви позволява да управлявате повече от вашите капиталови разходи и да подобрите планирането на капацитета си при промяна на изискванията за определен период от време.
Диск
Тъй като мрежовата активност има значение и за производителността на вашия диск, особено по време на промиване. Също така е най-добре да определите как се изпълняват времето и извличането, когато се достигне високо пиково натоварване. Има моменти, когато зареждате хоста на вашата база данни, като не само сте посветени на дейност на Galera Cluster, но и комбинирате с други инструменти като docker, SQL прокси сървъри като ProxySQL или MaxScale. Това ви дава контрол със сървъри с ниско натоварване и ви позволява да използвате наличните резервни ресурси, които могат да бъдат използвани за други полезни цели, особено за стека на архитектурата на вашата база данни. След като сте в състояние да определите кой възел при наблюдение има най-ниско натоварване, но все още може да управлява използването на дисковия IO, тогава можете да изберете конкретния възел, докато наблюдавате времето, което минава. Отново, това все още ви дава по-добро управление с планирането на капацитета ви.
Активност на процесора, паметта и зареждането
Позволете ми накратко да посоча тези три области, които да разгледате при наблюдение. В този раздел винаги е най-добре да имате по-добра видимост на следните области наведнъж. Това е по-бързо и по-лесно за разбиране, особено като се изключи затруднение в производителността или идентифициране на грешки, които причиняват спиране на вашите възли и които също могат да повлияят на другите възли и възможността за слизане надолу в клъстера.
И така, как активността на процесора, паметта и натоварването при наблюдение помага на вашия MariaDB клъстер? Е, както споменах по-горе, това са едно от малкото неща, които все пак са голям фактор за ежедневните рутинни проверки. Сега това също ви помага да определите дали това са периодични или случайни събития. Ако е периодично, може да е свързано с архивиране, работещо в един от вашите възли на Galera, или това е масивна заявка, която изисква оптимизация. Например, лоши заявки без подходящи индекси или небалансирано използване на извличане на данни, като например правене на сравнение на низове за такъв голям низ. Това може да бъде безспорно неприложимо за бази данни от тип OLTP, като например MariaDB Cluster, особено ако това наистина е естеството и изискванията на вашето приложение. По-добре използвайте други аналитични инструменти като MariaDB Columnstore или други инструменти за аналитична обработка на трети страни (Apache Spark, Kafka или MongoDB и т.н.) за извличане на големи низови данни и/или съвпадение на низове.
Така че след като всички тези ключови области се наблюдават, въпросът е как да се наблюдава? Трябва да се следи поне на минута. С прецизно наблюдение, т.е. колективните показатели за секунда могат да бъдат ресурсоемки и много алчни по отношение на вашите ресурси. Въпреки че половин минута колективност е приемлива, особено ако вашите данни и RPO (цел за точка на възстановяване) са много ниски, така че имате нужда от по-подробни показатели за данни в реално време. Много е важно да можете да наблюдавате цялата картина на вашия клъстер от база данни. Освен това, също така е най-добре и важно винаги, когато какви показатели наблюдавате, да имате правилния инструмент, който да привлече вниманието ви, когато нещата са в опасност или дори само предупреждения. Използването на подходящия инструмент като ClusterControl ви помага да управлявате тези ключови области, които да бъдат наблюдавани. Използвам тук безплатна версия или общностно издание на ClusterControl и ми помага да наблюдавам моите възли без никакви проблеми от инсталирането до наблюдението на възлите само с няколко щраквания. Например, вижте екранните снимки по-долу:
Изгледът е по-прецизен и бърз преглед на това, което се случва в момента. Може да се използва и по-подробна графика,
или с по-мощен и богат модел на данни, който също поддържа език за заявки, може ви предоставя анализ на това как се представя вашият MariaDB клъстер въз основа на исторически данни, сравнявайки навреме неговата производителност. Например,
Това само ви предоставя по-видими показатели. Така че виждате колко важно наистина е да имате правилния инструмент, когато наблюдавате своя MariaDB клъстер.
Осигурете колективно наблюдение на вашите MariaDB клъстерни статистически променливи
От време на време не може да бъде неизбежно версиите на MariaDB Cluster да произвеждат нови статистически данни за наблюдение или подобряване на естеството на наблюдението на базата данни чрез предоставяне на повече променливи на състоянието и прецизиране на стойности, които да се разглеждат. Както споменах по-горе, използвам ClusterControl за наблюдение на моите възли в този примерен блог. Това обаче не означава, че това е най-добрият инструмент. Искам да кажа, че PMM от Percona е много богат, когато става въпрос за колективно наблюдение за всяка статистическа променлива, която винаги, когато MariaDB Cluster предлага по-нови статистически променливи, можете да използвате това и също така да го промените, тъй като PMM е инструмент с отворен код. Голямо предимство е, че също така разполагате с цялата видимост на вашия MariaDB Cluster, тъй като всеки аспект се брои особено в производствена база данни, която обслужва стотици хиляди заявки в минута.
Но нека разгледаме проблема по-конкретно тук. Какви са тези статистически променливи, които да разгледаме? Има много неща, на които да разчитате за MariaDB Cluster, но като се фокусираме отново върху функциите и предимствата, за които вярваме, че използвате MariaDB Cluster това, което той може да предложи, тогава ще се съсредоточим върху това.
Galera Cluster – Контрол на потока
Контролът на потока на вашия MariaDB клъстер ви предоставя преглед на това как се представя здравето на репликацията в целия клъстер. Процесът на репликация в Galera Cluster използва механизъм за обратна връзка, което означава, че той сигнализира за всички възли в този клъстер и маркира дали възелът трябва да постави на пауза или да възобнови репликацията според нуждите си. Това също така не позволява на всеки възел да изостава твърде много, докато другите прилагат входящите транзакции. Ето как контролът на потока служи като своя функция в Galera. Сега това трябва да се види и да не се пренебрегва при наблюдение на вашия MariaDB клъстер. Това, както е споменато в едно от предимствата при използването на MariaDB Cluster е, че избягването на забавяне на подчинените. Въпреки че това е твърде наивно, за да се разбере за контрола на потока и забавянето на подчинения, но с контрола на потока, това ще повлияе на производителността на вашия клъстер Galera, когато има много опашка и ангажименти или изтриването на страници на диска става много ниско за такива проблеми с диска или просто изпълняването на заявка е лоша заявка. Ако сте начинаещ в това как работи Galera, може да ви е интересно да прочетете тази външна публикация за това какво представлява контролът на потока в Galera.
Изпратени/получени байтове
Изпратените или получени байтове корелират с мрежовата активност и дори са една от ключовите области, които трябва да изглеждате рамо до рамо с контрола на потока. Това ви позволява да определите кой възел е най-засегнат или приписващ проблемите с производителността, които страдат във вашия клъстер Galera. Много е важно, тъй като можете да проверите дали може да има някакво влошаване по отношение на хардуера, като вашето мрежово устройство или основното устройство за съхранение, за което синхронизирането на мръсни страници може да отнеме твърде много време.
Зареждане на клъстер
Е, това е повече от дейността на базата данни за това колко промени или извличане на данни са били заявени или извършени досега от времето на работа на сървъра. Помага ви да изключите какъв вид заявки засягат най-вече производителността на клъстера от база данни. Това ви позволява да осигурите място за подобрение, особено по отношение на балансирането на натоварването на вашите заявки за база данни. Използването на ProxySQL ви помага тук с по-изтънчен и детайлен подход за маршрутизиране на заявки. Въпреки че MaxScale също предлага тази функция, ProxySQL има по-голяма детайлност, въпреки че също има известно въздействие върху производителността или цената. Въздействието идва, когато имате само един ProxySQL като SQL прокси, за да изработите маршрутизирането на заявката и може да се бори, когато има висок трафик. Като цена, ако добавите повече ProxySQL възли, за да балансирате повече от трафика, който е в основата на KeepAlived. Въпреки че това е перфектна комбинация, но може да се изпълнява на ниска цена, докато не е необходимо. Как обаче ще можете да определите дали е необходимо, нали? Това е въпросът, който остава тук, така че зоркото око за наблюдение на тези ключови области е много важно, не само за наблюдаемост, но и за подобряване на производителността на клъстера от база данни с течение на времето.
Като такива, има много променливи, които да разглеждате в MariaDB клъстер. Най-важното нещо тук, което трябва да вземете под внимание, е инструментът, който използвате за наблюдение на клъстера от база данни. Както споменахме по-рано, предпочитам да използвам лиценза за безплатна версия на ClusterControl (Community Edition) тук в този блог, тъй като ми предоставя повече начини с гъвкавост за разглеждане в клъстер на Galera. Вижте примера по-долу,
Отметих или оградих в червено тези раздели, които ми позволяват визуално да наблюдавам здравето на моя MariaDB клъстер. Да речем, ако вашето приложение е алчно да използва стрийминг репликация от време на време и изпраща голям брой фрагменти (голям мрежов трансфер) за интерактивност на клъстера, най-добре е да определите колко добре вашите възли могат да се справят със стреса. Особено по време на стрес тестове, преди да нанесете конкретни промени във вашето приложение, винаги е най-добре да опитате и тествате, за да определите управлението на капацитета на вашия продукт за приложение и да определите дали текущите ви възли и дизайн на базата данни могат да се справят с натоварването на изискванията на вашето приложение.
Дори в общностно издание на ClusterControl мога да събирам детайлни и по-прецизни резултати за здравето на моя MariaDB Cluster. Вижте по-долу,
Така ще подходите към наблюдението на вашия MariaDB клъстер. Перфектната визуализация винаги е по-лесна и по-бърза за управление. Когато нещата вървят на юг, не можете да си позволите да загубите производителността си, а също така времето за престой може да повлияе на вашия бизнес. Въпреки че наличието на безплатно не ви осигурява лукса и комфорта при управление на бази данни с голям трафик, наличието на аларми, известия и управление на базата данни в една област е добавки за разходка в парка, които ClusterControl може да направи.
Заключение
MariaDB Cluster не е толкова лесен за наблюдение в сравнение с традиционните асинхронни настройки на MySQL/MariaDB master-slave. Работи по различен начин и трябва да имате правилните инструменти, за да определите какво се случва и какво се случва във вашия клъстер от база данни. Винаги подготвяйте планирането на капацитета си предварително, преди да стартирате своя MariaDB Cluster без подходящо наблюдение предварително. Винаги е най-добре натоварването и дейността на вашата база данни да са известни преди катастрофално събитие.
