MariaDB
 sql >> база данни >  >> RDS >> MariaDB

Мониторинг на производителността на MariaDB в хибриден облак

Ефективността в нашата база данни MariaDB е една от областите, които искаме да наблюдаваме отблизо и да наблюдаваме в производствена среда и нейното навременно работещо състояние. Може да бъде изключително взискателно за време, работа и пари, ако архитектурната настройка използва хибриден облак. Не само това, има такива определени области, които трябва да разгледате, особено мрежовият посредник, който обслужва своята свързаност като локален или частен облак, който комуникира с публичния облак (GCP, AWS, Azure и т.н.) и обратно .

Този блог е свързан с наблюдение на производителността на вашите MariaDB бази данни в хибридна облачна инфраструктура. Ще ви предоставим основите и най-важните ключови индикатори, когато наблюдавате ефективността на вашата база данни MariaDB в хибридна облачна настройка.

Защо имате нужда от наблюдение на производителността?

В хибриден облак може да е сложно да наблюдавате всяка услуга, от която се възползвате. За разлика от вашия собствен център за данни или вашия частен облак, вие имате пълен контрол върху хардуерната и софтуерната инфраструктура. С публичния облак има ограничения за услугите, които сте предложили, и това може да доведе до допълнителни разходи, ако искате различни услуги, които ще ви предоставят показатели и регистрационни файлове. Сигурността също е проблем по отношение на вашите поверителни данни, които се събират.

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

В рамките на хибриден облак не всички инструменти за софтуерен мониторинг са създадени да управляват ключови показатели, които трябва да се наблюдават и наблюдават. Трябва да имате идеята и знанията, за да определите необходимите показатели и изисквания, които инструментът може да предостави. При хибриден облак се очаква естеството на работата на хибридния облак да бъде сложно. Услугите са силно разпространени и смесени с други услуги, които не са обвързани само с един доставчик.

В това отношение вашият софтуер за наблюдение има тези специалности и има ли възможността да идентифицира и отделя от кой облак принадлежи. Софтуерът или инструментите за наблюдение трябва да имат способността да се справят с тесни места, проблеми със сигурността, латентности, да предоставят мащабируемост, да уведомяват за текущи проблеми и да предоставят прогнози. Прогнозата може да избегне по-нататъшни последици, които могат да доведат до бедствие или ефективност на въздействието на вашите бази данни MariaDB. Това помага на целия екип, включително инфраструктурни инженери, инженери на бази данни, сървърни администратори и разработчици, да гарантират, че сървърите на бази данни са здрави и работят на нивото на очакванията си.

Неща, които трябва да имате предвид при наблюдение на база данни

Когато наблюдавате своя клъстер от база данни MariaDB (репликация или Galera) или възел, има две основни неща, които трябва да вземете предвид:операционната система и самата база данни. Ще трябва да дефинирате кои показатели ще наблюдавате от двете страни и как ще го направите. Трябва да наблюдавате метриката винаги в контекста на вашата система и трябва да търсите промени в модела на поведение.

В повечето случаи ще трябва да използвате няколко инструмента (тъй като е почти невъзможно да намерите такъв, който да покрива всички желани показатели.) 

Имайте предвид, че когато един от вашите показатели е засегнат, това може да засегне и други, което прави отстраняването на проблема по-сложно. Наличието на добра система за наблюдение и известяване е важно, за да направите тази задача възможно най-проста.

Винаги наблюдавайте активността на сървъра си (мрежа, диск, зареждане, памет и процесор)

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

Мрежа

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

Ако използвате Galera, тъй като MariaDB надстрои своя Galera до версия 4, репликацията на поточно предаване се добавя като една от основните функции и промени спрямо предишната версия. Тъй като стрийминг репликацията се справя с недостатъците, които имаше в предишните издания, но му позволява да управлява повече от 2GB набори за запис от Galera Cluster 4. Това позволява големите транзакции да бъдат фрагментирани и силно се препоръчва да се активира това само на ниво сесия. Това означава, че наблюдението на вашата мрежова активност е много важно и от решаващо значение за нормалната дейност на вашия MariaDB клъстер. Това ще ви помогне да определите кой възел е имал най-много или най-висок мрежов трафик въз основа на периода от време.

Добър пример за изобразяване на наблюдение на мрежата е използването на ClusterControl. Той идентифицира всеки от възлите и предоставя преглед на неговата мрежова активност на възел, независимо от кой облак се намира възелът. Вижте екранната снимка по-долу:

Активност на процесора, паметта и зареждането

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

И така, как активността на процесора, паметта и натоварването при наблюдение помага на вашата MariaDB? Е, както споменах по-горе, това са едно от малкото неща, които все пак са голям фактор за ежедневните рутинни проверки. Сега това също ви помага да определите дали това са периодични или случайни събития. Ако е периодично, може да е свързано с архивиране, работещо в един от вашите възли на база данни на MariaDB, или това е масивна заявка, която изисква оптимизация. Например, лоши заявки без подходящи индекси или небалансирано използване на извличане на данни, като например правене на сравнение на низове за такъв голям низ. Това може да бъде безспорно неприложимо за бази данни от типа OLTP, особено ако това наистина е естеството и изискванията на вашето приложение. По-добре използвайте други аналитични инструменти като MariaDB Columnstore или други инструменти за аналитична обработка на трети страни (Apache Spark, Kafka или MongoDB и т.н.) за извличане на големи низови данни и/или съвпадение на низове.

Така че след като всички тези ключови области се наблюдават, въпросът е как да се наблюдава? Трябва да се следи поне на минута. С прецизно наблюдение, т.е. колективните показатели за секунда могат да бъдат ресурсоемки и много алчни по отношение на вашите ресурси. Въпреки че половин минута колективност е приемлива, особено ако вашите данни и RPO (цел за точка на възстановяване) са много ниски, така че имате нужда от по-подробни показатели за данни в реално време. Много е важно да можете да наблюдавате цялата картина на вашия клъстер от база данни. Освен това, също така е най-добре и важно винаги, когато какви показатели наблюдавате, да имате правилния инструмент, който да привлече вниманието ви, когато нещата са в опасност или дори само предупреждения. Използването на подходящия инструмент като ClusterControl ви помага да управлявате тези ключови области, които да бъдат наблюдавани. Използвам безплатна версия или общностно издание на ClusterControl, което ми помага да наблюдавам моите възли без никакви проблеми от инсталирането до наблюдението на възлите само с няколко щраквания. Например, вижте екранните снимки по-долу:

Осигурява и база за всеки възел с прост преглед на графиката,

или с по-мощен и богат модел на данни, който също поддържа език за заявки, използващ Prometheus, може да ви предостави анализ на това как се представя вашата база данни MariaDB въз основа на исторически данни, сравнявайки нейната производителност навреме. Например,

Това само ви предоставя по-видими показатели. Така че виждате колко важно наистина е да имате правилния инструмент, когато наблюдавате вашата база данни MariaDB в хибриден облак.

Колективно наблюдение на вашите статистически променливи MariaDB

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

Изпратени/получени байтове

Изпратените или получени байтове корелират с мрежовата активност и са една от ключовите области, които трябва да гледате един до друг, особено в хибридна облачна топология. Това ви позволява да определите кой възел е най-засегнат или приписващ на проблемите с производителността, които страдат във вашата база данни MariaDB. Много е важно, тъй като можете да проверите дали може да има някакво влошаване по отношение на хардуера, като вашето мрежово устройство или основното устройство за съхранение, за което синхронизирането на мръсни страници може да отнеме твърде много време.

Вижте примерната екранна снимка,

Зареждане на клъстер

Това е повече от дейността на базата данни за това колко промени или извличане на данни са били заявени или извършени досега от времето на работа на сървъра. Помага ви да изключите какъв вид заявки засягат най-вече производителността на клъстера от база данни. Това ви позволява да осигурите място за подобрение, особено по отношение на балансирането на натоварването на вашите заявки за база данни.

Като такива, има много променливи, които да разглеждате в сървър на база данни на MariaDB. Най-важното нещо тук, което трябва да вземете под внимание, е инструментът, който използвате за наблюдение на клъстера от база данни. С ClusterControl (Community Edition) ми предоставя повече начини с гъвкавост за разглеждане в база данни на MariaDB. Вижте примера по-долу,

След това можете също да изберете от падащото меню другите променливи, които да разгледате,

Това е много полезно и ви помага да определите например топология на репликация в хибриден облак. Можете да получите бърз преглед на състоянието и производителността, свързани с мрежата, но също и с други променливи указатели, за да разгледате и проверите какви са тесните места, които биха повлияли на производителността на MariaDB в хибридна облачна топология. Можете да определите дали приложението ви е алчно за записвания, тогава репликацията и мрежовият трансфер са засегнати, можете да получите интерактивността на клъстера в рамките на две или повече облачни инфра. Най-добре е да определите колко добре вашите възли могат да се справят със стреса. Особено по време на стрес тестове, преди да нанесете конкретни промени във вашето приложение, винаги е най-добре да опитате и тествате, за да определите управлението на капацитета на вашия продукт за приложение и да определите дали текущите ви възли и дизайн на базата данни могат да се справят с натоварването на изискванията на вашето приложение.

За по-подробни и богати показатели за данни можете да получите повече данни с помощта на мониторинг, базиран на агенти. Вижте по-долу,

Така ще подходите към наблюдението на вашия MariaDB клъстер. Перфектната визуализация винаги е по-лесна и по-бърза за управление. Когато нещата вървят на юг, не можете да си позволите да загубите производителността си, а също така времето за престой може да повлияе на вашия бизнес. Въпреки че наличието на безплатна версия не ви осигурява лукс и комфорт при управление на бази данни с голям трафик; наличието на аларми, известия и управление на база данни в една зона е добавки за разходка в парка, които ClusterControl може да направи.

Заключение

Наблюдението на вашите сървъри на бази данни MariaDB в хибридна облачна среда не е лесно и също е сложно, особено когато има редица услуги и сложни взаимоотношения, които формулират целия пакет от вашата технология. Използването на правилните инструменти за наблюдение ви помага да управлявате приложението си ефективно и същевременно да подобрявате производителността. Освен това, с подходящите инструменти за наблюдение в ръка, ще имате повече време да се съсредоточите върху подобряването на вашите приложения заедно с други бизнес процеси.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Как да извадите минути от стойност на дата и час в MariaDB

  2. Внедряване на MySQL, MariaDB, Percona Server, MongoDB или PostgreSQL - става лесно с ClusterControl

  3. Изграждане на горещ режим на готовност на Amazon AWS с помощта на MariaDB Cluster

  4. Как да постигнем PCI съответствие за MySQL и MariaDB с ClusterControl - Повторението

  5. Ръководство за поточно репликация на клъстер на MySQL Galera:част втора