Процедура последовательного перезапуска
Кластеры YDB могут обновляться без простоев, поскольку обычно они содержат избыточные компоненты и поддерживает процедуру последовательного перезапуска. Чтобы обеспечить постоянную доступность данных, YDB включает в себя систему управления кластером (CMS), которая отслеживает все сбои в работе и узлы, отключённые для обслуживания, например при перезапуске. CMS останавливает новые запросы на обслуживание, если они могут поставить под угрозу доступность данных.
Однако, даже если данные всегда доступны, перезапуск всех узлов за относительно короткий промежуток времени может оказать заметное влияние на общую производительность. Каждая таблетка, которая выполнялась на перезапускаемом узле, будет запущена снова на другом узле. Перемещение таблетки между узлами требует времени и может повлиять на задержки запросов, связанных с ней. Смотрите рекомендации по процедуре последовательного перезапуска.
Кроме того, новая версия YDB может обрабатывать запросы по-другому. Хотя производительность, как правило, повышается с каждым обновлением, в некоторых пограничных случаях производительность может снижаться. Смотрите рекомендации по производительности разных версий.
Диагностика
Важно
Диагностика последовательных перезапусков и обновлений YDB основана только на вторичных признаках. Чтобы быть абсолютно уверенным в том, что происходит обновление или последовательный перезапуск узлов, обратитесь к администратору вашей базы данных.
Чтобы проверить, не обновляется ли YDB кластер:
-
Откройте Встроенный UI.
-
На вкладке Nodes проверьте, отличаются ли версии YDB на узлах.
Также проверьте, имеют ли узлы с новой версией YDB более низкие значения времени с момента запуска (uptime).
Внимание
Низкий uptime узла YDB может также указывать на другие проблемы. Например, см. Недостаточный объём памяти (RAM).
Рекомендации
В случае последовательного перезапуска
Если из-за процесса последовательного перезапуска кластера YDB задержки приложения вырастают выше критического уровня, подумайте о том, чтобы замедлить процесс перезапуска:
-
Если узлы перезапускаются группами, сократите размер групп, вплоть до одного узла за раз.
-
Разнесите во времени перезагрузки в каждом датацентре и/или серверной стойке.
-
Вставьте дополнительные паузы между перезагрузками.
В случае отличий в работе разных версий
Целью является как можно более раннее обнаружение негативного влияния новой версии YDB на скорость выполнения определённых запросов в конкретной пользовательской нагрузке:
-
Просмотрите список изменений YDB сервера, обращая особое внимание на изменения, связанные с производительностью и относящиеся к вашей рабочей нагрузке.
-
Используйте выделенный кластер для тестирования YDB под нагрузкой, которая настолько точно соответствует вашей рабочей нагрузке, насколько это возможно. Всегда сначала развёртывайте новую версию YDB на таких кластерах, чтобы оценить влияние новой версии в тестовом окружении. Отслеживайте задержки как на стороне клиента, так и на стороне сервера, чтобы выявить любые потенциальные проблемы с производительностью.
-
Используйте канареечное развертывание (canary deployment), обновив сначала только один узел кластера и проанализировав любые изменения в его поведении. Если всё выглядит стабильно, постепенно распространите обновление на большее количество узлов, например, на всю серверную стойку или датацентр, и повторяйте проверки на наличие аномалий. Если возникнут какие-либо проблемы, немедленно вернитесь к предыдущей версии и попытайтесь воспроизвести проблему в тестовой среде.
Сообщайте о любых выявленных проблемах с производительностью на GitHub YDB. Предоставьте контекст и все детали, которые могут помочь воспроизвести проблему.