В предишния ни блог за таблата за управление на SCUMM разгледахме таблото за преглед на MySQL. Новата версия на ClusterControl (версия 1.7) предлага редица графики с висока разделителна способност на полезни показатели и ние разгледахме значението на всеки от показателите и как те ви помагат да отстраните неизправности в базата данни. В този блог ще разгледаме таблото за управление на MySQL Replication. Нека продължим с подробностите за това табло за управление за това какво може да предложи.
Табло за управление за репликация на MySQL
Таблото за управление за репликация на MySQL предлага много ясни набори от графики, които улесняват наблюдението на вашия MySQL главен и реплика(и). Започвайки от върха, той показва най-важните променливи и информация за определяне на здравето на репликата(ите) или дори на главния. Това табло предлага много полезна част при проверка на здравето на подчинените или на главен в настройката главен-главен. Можете също така да проверите на това табло за управление създаването на двоичен дневник на главната и да определите цялостното измерение по отношение на генерирания размер за конкретен даден период от време.
Първото нещо в това табло за управление ви представя най-важната информация, която може да ви е необходима за здравето на вашата реплика. Вижте графиката по-долу:
По принцип той ще ви покаже IO_Thread, SQL_Thread на подчинената нишка, грешка при репликация и ако е активирана променлива read_only. От примерната екранна снимка по-горе цялата информация показва, че моят подчинен 192.168.70.20 е здрав и работи нормално.
Освен това ClusterControl има информация за събиране, ако отидете на Cluster -> Overview. Превъртете надолу и можете да видите графиката по-долу:
Друго място за преглед на настройката за репликация е изгледът на топологията на настройката за репликация, достъпен в Клъстер -> Топология. Той дава с бърз поглед изглед на различните възли в настройката, техните роли, забавяне на репликацията, извлечен GTID и други. Вижте графиката по-долу:
В допълнение към това, изгледът на топологията също така показва всички различни възли, които формират част от клъстера на вашата база данни, независимо дали са възлите на базата данни, балансьорите на натоварване (ProxySQL/MaxScale/HaProxy) или арбитрите (garbd), както и връзките между тях. Възлите, връзките и техните състояния се откриват от ClusterControl. Тъй като ClusterControl непрекъснато наблюдава възлите и съхранява информация за състоянието, всички промени в топологията се отразяват в уеб интерфейса. В случай на докладване на повреда на възли, можете да използвате този изглед заедно с таблата за управление на SCUMM и да видите какво въздействие може да го причини.
Изгледът на топологията има известна прилика с Orchestrator, в който можете да управлявате възлите, да променяте главните, като плъзгате и пускате обекта върху желания главен, рестартирате възли и синхронизирате данни. За да научите повече за нашия изглед на топология, ви предлагаме да прочетете предишния ни блог – „Визуализация на вашата клъстерна топология в ClusterControl“.
Нека сега да продължим с графиките.
-
Закъснение на репликацията на MySQL
Тази графика е много позната на всеки, който управлява MySQL, особено на тези, които работят на ежедневна база върху настройката си главен-подчинен. Тази графика съдържа тенденциите за всички забавяния, записани за конкретен период от време, посочен в това табло. Всеки път, когато искаме да проверим периодичното време на падане, което има нашата реплика, тогава тази графика е добра за разглеждане. Има определени случаи, в които репликата може да изостава поради странни причини, като например вашият RAID има деградиран BBU и се нуждае от подмяна, таблица няма уникален ключ, но не е на главния, нежелано пълно сканиране на таблица или пълно сканиране на индекс, или лоша заявка беше оставен да работи от разработчик. Това също е добър индикатор, за да определите дали забавянето на подчинените е ключов проблем, тогава може да искате да се възползвате от паралелната репликация. -
Binlog Size
Тези графики са свързани една с друга. Графиката Binlog Size ви показва как вашият възел генерира двоичния дневник и помага да се определи неговото измерение въз основа на периода от време, който сканирате. -
Binlog данни, записани на час
Binlog данни, записани почасово, е графика, базирана на текущия и предишния записан ден. Това може да е полезно винаги, когато искате да определите колко голям е вашият възел, който приема записи, които по-късно можете да използвате за планиране на капацитета.
-
Binlogs Count
Да приемем, че очаквате висок трафик за дадена седмица. Искате да сравните колко големи записи преминават през вашия господар и подчинени с предходната седмица. Тази графика е много полезна за този вид ситуация - За да се определи колко високи са били генерираните двоични регистрационни файлове на самия главен или дори на подчинените, ако е активирана променливата log_slave_updates. Можете също да използвате този индикатор, за да определите генерираните двоични регистрационни данни от главните срещу подчинените, особено ако филтрирате някои таблици или схеми (replicate_ignore_db, replicate_ignore_table, replicate_wild_do_table) на вашите подчинени устройства, които са били генерирани, докато log_slave_updates е активиран. -
Binlogs, създадени на час
Тази графика е бърз преглед за сравняване на създаването на вашите binlogs на час от вчера и днешната дата. -
Relay Log Space
Тази графика служи като основа на генерираните релейни регистрационни файлове от вашата реплика. Когато се използва заедно с графиката за забавяне на репликацията на MySQL, тя помага да се определи колко голям е броят на генерираните релейни регистрационни файлове, които администраторът трябва да вземе предвид по отношение на наличността на диска на текущата реплика. Това може да причини проблеми, когато вашият подчинен е силно изоставащ и генерира голям брой релейни регистри. Това може бързо да изразходва вашето дисково пространство. Има определени ситуации, при които поради големия брой записи от главния, подчинената/репликата ще изостава значително, като по този начин генерирането на голямо количество регистрационни файлове може да причини сериозни проблеми на тази реплика. Това може да помогне на оперативния екип, когато говори с ръководството си за планиране на капацитета. -
Релейният дневник се записва на час
Същото като пространството на Relay Log Space, но добавя бърз преглед за сравняване на вашите регистрационни файлове, записани от вчера и днешната дата.
Заключение
Научихте, че използването на SCUMM за наблюдение на вашата MySQL репликация добавя повече производителност и ефективност към оперативния екип. Използването на функциите, които имаме от предишни версии, комбинирани с графиките, предоставени със SCUMM, е като да отидете на фитнес и да видите огромни подобрения в производителността си. Това е, което SCUMM може да предложи:наблюдение на стероиди! (сега ние не препоръчваме да приемате стероиди, когато ходите на фитнес!)
В част 3 от този блог ще обсъдя таблата за управление на InnoDB Metrics и MySQL Performance Schema.
