При настройка на MySQL хостинг репликация, параметърът Seconds_Behind_Master (SBM), както се показва от командата SHOW SLAVE STATUS, обикновено се използва като индикация за текущото забавяне на репликацията на подчинения . В тази публикация в блога разглеждаме как да разберем и тълкуваме тази стойност в различни ситуации.
Възможни стойности на секунди зад главния
Стойността на SBM, както е обяснено в документацията на MySQL, зависи от състоянието на подчинения MySQL като цяло и от състоянията на подчинения на MySQL SQL_THREAD и IO_THREAD в частност. Докато IO_THREAD се свързва с главния и чете актуализациите, SQL_THREAD прилага тези актуализации на подчинения. Нека да разгледаме възможните стойности на SBM по време на различни състояния на MySQL Slave.
Когато стойността на SBM е нула
- SBM винаги е NULL, ако вашият подчинен е спрян или вашата SQL нишка е спряна (или не се изпълнява).
- SBM също ще бъде NULL, ако IO нишката е спряна, при условие че SQL нишката вече е обработила всички събития от регистрационния файл на релето. Примерен изход на SHOW SLAVE STATUS (подрязан, за да показва само стойности от интерес) демонстрира това:
Slave_IO_State:
Master_Host:172.19.0.13
Slave_IO_Running:Не
Slave_SQL_Running:Да
Seconds_Behind_Master:NULL
Master_UUID:23b326b1-a452-11e8-91ca-000d3a065e8e
Slave_SQL_Running_State:Подчинен е прочел всички реле регистрационни файлове; чакам още актуализации
Извлечено_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:818-389213
Executed_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:1-389213
Когато стойността на SBM е нула или положителна
- SBM ще отразява валидна стойност (>=0) когато SQL нишката активно обработва събития. Това е вярно, независимо от състоянието на IO Thread. Например:
Slave_IO_State:
Master_Host:172.19.0.13
Slave_IO_Running:Не
Slave_SQL_Running:Да
Seconds_Behind_Master:3399
Master_UUID:23b326b1-a452-11e8-91ca-000d3a065e8e
Slave_SQL_Running_State:Изчаква подчинените работници да обработят своите опашки
Извлечено_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:818-389213
Executed_Gtid_Set:23b326b1-a452-11e8-91ca-000d3a065e8e:1-118774
В горния пример можем да видим, че подчинен е зад главния, като сравниме Retrieved_GTID_Set и Executed_GTID_Set. В такива случаи Seconds_Behind_Master ще представлява разликата между клеймото за дата на последната транзакция, обработена от SQL нишката, и клеймото за време на същата транзакция, когато е била обработена на главния. Това клеймо за време на транзакцията на главния се запазва чрез репликация и следователно подчиненият ще може да изчисли SBM локално.
Също така, след като подчинения напълно настигне всички релейни регистри (т.е. изпълненият GTID става 23b326b1-a452-11e8-91ca-000d3a065e8e:1-389213_ster/), завъртете на „0“, ако IO Thread се изпълнява, или на „NULL“, ако IO Thread не работи.
#MySQL урок – разбиране на секундите зад главната стойност Щракнете за туит
Разбиране на скоростта на изпълнение на MySQL Slave
Ако приемем, че SQL Thread и IO Thread на подчинения са в работещи състояния, е възможно да се разберат относителните скорости на изпълнение на главния и подчинения чрез наблюдение на стойността на SBM. Постоянна стойност „0“ или постоянна стойност показва, че подчинението се изпълнява със същата скорост като главната. От друга страна, наклонът нагоре за Seconds_Behind_Master показва, че подчинената работи по-бавно от главната.
Конзолата за наблюдение на ScaleGrid за MySQL в Azure изобразява стойностите на SBM във времето за подчинените възли.
Нулева или постоянна стойност на SBM
В горния пример подчинението е стартирано около 40 часа след като главният е имал активни записи. Веднъж стартиран, подчинението започна да репликира тези данни и виждаме, че SBM е доста плосък, което показва, че подчинението се изпълнява със същата скорост като главния. Също така имайте предвид, че падането на SBM до „0“ е рязко, което наистина означава, че въпреки че последната транзакция, извършена от подчинения, е била изпълнена около 40 часа преди това на главния, след като наваксаме, има забавяне „0“.
Увеличаване на стойностите на SBM
В графиката по-долу можем да видим, че SBM непрекъснато се увеличава, което означава, че скоростта на изпълнение на подчинения е по-малка в сравнение с тази на главния. Това всъщност е случай, в който изпълняваме 20 нишки, извършващи непрекъснати записи на главния и еднонишков подчинен не е в състояние да върви в крак с него.
Накрая, важно е да отбележим, че в нашите дискусии досега не сме предполагали никакви мрежови тесни места. В случай на бавни мрежи самата подчинена IO нишка ще изостава от главната и ако SQL нишката е достатъчно бърза, SBM ще се колебае между „0“ и положително число. В такива случаи SBM няма да бъде полезен параметър за разбиране на истинското изоставане с главния.
Ако ви е харесала тази публикация в блога, разгледайте нашите други популярни уроци за управление на база данни MySQL, за да научите повече за оптимизирането на внедряванията си:
- Изчисляване на размера на InnoDB буферен пул за вашия MySQL сървър
- Урок за MySQL – Конфигуриране и управление на SSL на вашия MySQL сървър
- Обяснена рамка за висока достъпност на MySQL – част I:Въведение
