Привет) К сожалению не могу тут подсказать. Для своей задачи мы формировали и отправляли кастомные метрики на уровне приложения, сами графики же строили во внутренней системе, а не средствами YC.
нет ни процессоров, ни оперативной памяти и дисков, всё занято выполнением запросов на чтение данных?! Синхронизация будет стоять и ждать освобождения ресурсов. Это ваш случай
Не наш случай. Flow control преимущественно срабатывал когда с ресурсами было все ок. ОЗУ и CPU в полке скорее всего исключение за счет неоптимизированных запросов в моменте. Само собой, когда ресурсов недостаточно, то очевидно, что проблемы могут быть не только с синком
эта нагрузка на чтение оказалась чрезмерной...
Запросы на чтение стали потреблять меньше ресурсов, ресурсов стало хватать
На репликах постоянная нагрузка не более 5-10%, т.е. по ресурсам все свободно.
В вашем случае было достаточно почистить базу данных от ненужных старых данных
Запросы на чтение стали потреблять меньше ресурсов, ресурсов стало хватать, проблемы синхронизации решены.
Почему запросы на чтение должны меньше потреблять ресурсов из за того что база весит меньше? RPS ушел? Или может объем данных получаемых стал меньше? Где корреляция? База же не переливается постоянно полностью, а ДО наливается в соответствии с курсором в binlog. Поэтому базе относительно синка, по большей части равно какого она размера, главное данные в моменте которых не достает в реплике и которые надо перенести
У вас есть какие то подробности или может материалы по поводу того, что селективная нагрузка или объем данных (который не переливается в данный момент) влияет на синк реплик?
Binlog же не хранит никакой информации о старых данных, а тем более информации о селектах, поэтому нет никакой причины тормозить синк. Единственное место которое я вижу, где может повлиять размер таблиц - это неоптимизированные запросы, в которых используется какой нибудь file sort.
Это ресурсы не монолита, а дедиков, на которых базировался mysql. У нас 3 ДЦ, в каждом по master+slave, итого 6 ног. Ресурсы одной ноды - 1ТБ ОЗУ и 256 ядер.
На вопрос почему так много, нет точного ответа, но предполагаю, что эти сервера были собраны еще до того, как Еда, как проект, стала принадлежать Яндексу. Просто собрали сервера сильно с запасом, выкрутили настроечки в виде threads и buffer_pool_size в максимальные значения и в таком виде продалось Я. Ну а нам в целом, этого хватало с лихвой.
Может где то некорректно выразился но да, 3 ДЦ, в каждом master+slave. Galera cluster же это заворачивает в multi master схему, что позволяет писать в любой мастер из ДЦ. Слейвы для чтения, либо для замены вышедшего из строя мастера рамках ДЦ
Тогда одну базу можно разбить на 89 меньшего размера
А не было необходимости вроде. Проблема же не в том что данных очень много и выборки медленно работают, а в том что из за большого количества вставок в базу в моменте, данные не успевали доезжать до реплики из за чего мастер останавливался. Т.е. решать надо было что то с модифицирующими запросами. Вот тут про шардирование и репликацию ответил)
Наша проблема же заключалась в том, что у нас срабатывал flow control при большом RPS на insert, данные не успевали засинкаться с репликами (а galera cluster - это multi master схема). Поэтому не думаю, что партиции бы нам помогли в данном случае, ибо объем данных не меняется
Классическое шардирование возможно бы помогло, но тут несколько моментов:
Неизвестно, как себя поведет тот же галеровский wait sync с бОльшим количеством нод. Т.е. если один шард притупит, есть вероятность словить еще больше проблем (это просто предположение)
В конечном итоге, после таких оптимизаций, данные то никуда не денутся и в ближайшем будущем их все придется разносить по сервисам) А тут мы вроде и подготовились к реализации нового сервиса, перенеся данные в отдельную базу), и тут же нагрузку сняли с базы монолита
Изначально мы стали говорить про clickhouse и kafka, эти решения тяжелые и не универсальные для нашего случая, поэтому я в дополнение к тому, что они нам не подходят, добавил что это требует дополнительных сил в виде инфраструктуры) Проблем в коммуникации нет, просто у каждого свой бэклог/цели и нельзя просто принести огромный проект который сразу же все начнут делать
сколько времени заняла эта фича кстати в днях?
Первый десяток табличек где то за 3 месяца в 1 руки. Это со сборами всяких аппрувов под квоты на базы, написание кода и переключение. Когда попробовали и написали доку, тогда уже остальные команды стали разносить свои таблички, но опять же, занималась не фулл тайм. Итого где то до полу года ушло на все от старта, до решения основных проблем.
Т.к. TS у нас последовательный, то в обертке это выглядело по типу conn1->rollback(); conn2->rollback(); тут вроде проблем не словили
если удавалось сделать запись только в одну БД, а вторая была недоступна
На эту ситуацию у нас был алерт и мы запускали вручную скрипт чтобы синхронизировать данные за какой то интервал времени. Но за весь период переноса, такая ситуация возникала буквально пару раз и то, потому что мы долго задерживались на стратегии когда писали в обе базы.
Изменились ли показатели на первых графиках с временем выполнения запросов в бд? Или срез пика в прошлом году это и есть итог ваших работ?
В целом, не изменилось. Так и есть, пик показывает, что основные проблемы были исправлены в конце 23, когда собрали самые проблемные запросы, всеми навалились и исправили. На остальном таймлайне просто хотелось показать, что мы продолжали мониторить запросы и в случае появления новых проблем их быстро правили. Сейчас, по выгрузкам мы видим, что "стреляющие" случаи - единичные, поэтому вкладываться в их оптимизацию нет имеет смысла.
Не кажется ли средний показатель в 300 мс неприемлемо большим?
А это же только в рамках выборки slow queries, а не всех запросов базы. Т.е. в эту выборку может попасть например 10 запросов за неделю, а для такого незначительного кол-ва думаю что приемлемо. К сожалению график собирал с агрегированных данных уже, поэтому кол-во этих запросов на тот момент посмотреть не получится
Как несколько коннектов повлияло на rps монолита?
RPS в монолите не изменился никак, вроде и не должен был) Может имелось ввиду тайминги? Если да, то в моменте, когда писали в обе базы, на некоторых эндпоинтах выросли на ~100мс, после полного перехода тайминги пришли в норму
Стал ли haproxy чаще сбоить? Замечал сбои при подобных распилах?
Привет! Конкретно в нашем стриме, у нас экспертизы все таки больше с pg, все наши сервисы по дефолту работают с pg.
В каких целях вы используете galera?
У нас все таки легаси монолит) Яндекс.Еда как проект, изначально принадлежал и разрабатывался другой компанией (до того как его купил Я.), решение в виде использования galera cluster принималось видимо по каким то своим соображениям, актуальным на тот момент. Могу предположить, что использовали из-за multi master схемы, которая одновременно позволяет и разгрузить бд, и особо не прилагать усилий для поддержки логики по получению неконсистентных данных из слейвов
Почему не использовали kafka
kafka в нашем проекте у нас нет вообще, а затащить ее только ради этого очень дорого
Зачем хранить в реляционной СУБД архивные данные? Кажется Clickhouse от Яндекса как для этого., CDC коннекторы при миграции?
Как уже сказал, хранятся они там по причине "исторически так сложилось, никто не переделывал". Использовать clickhouse актуально только для таблиц логов, а как я писал выше, переносили мы таблички не только с такими данными. Нужен был какой то универсальный инструмент, который могли бы использовать другие команды для своих таблиц.
Так же, все решения, которые нельзя реализовать в рамках приложения, требуют привлечения ребят из инфраструктуры, а это дополнительные ресурсы и время. В нашем решении пришлось привлечь ребят из инфры только чтобы получить квоты на создание баз. Остальное уже чисто руками разработчиков
Какие еще варианты решения проблемы рассматривали и почему отвергли их?
Был вариант например, с вынесением таблиц при помощи DataTransfer, но нам он не подошел потому что там нет плавной раскатки. К тому же, при переключении приложения на новый коннект потребуется какой то небольшой downtime.
P.S. Хотя с помощью него мы уже успешно мигрировали базу в облако)
100k rps - но это нормальная нагрузка для многих
100к рпс да, это нормально, но у нас и не было проблемы с читающим трафиком, проблема именно с пишущим, когда прилетала большая пачка модифицирующих запросов и срабатывал flow control.
Привет) К сожалению не могу тут подсказать. Для своей задачи мы формировали и отправляли кастомные метрики на уровне приложения, сами графики же строили во внутренней системе, а не средствами YC.
Не наш случай. Flow control преимущественно срабатывал когда с ресурсами было все ок. ОЗУ и CPU в полке скорее всего исключение за счет неоптимизированных запросов в моменте. Само собой, когда ресурсов недостаточно, то очевидно, что проблемы могут быть не только с синком
На репликах постоянная нагрузка не более 5-10%, т.е. по ресурсам все свободно.
Почему запросы на чтение должны меньше потреблять ресурсов из за того что база весит меньше? RPS ушел? Или может объем данных получаемых стал меньше? Где корреляция? База же не переливается постоянно полностью, а ДО наливается в соответствии с курсором в binlog. Поэтому базе относительно синка, по большей части равно какого она размера, главное данные в моменте которых не достает в реплике и которые надо перенести
У вас есть какие то подробности или может материалы по поводу того, что селективная нагрузка или объем данных (который не переливается в данный момент) влияет на синк реплик?
Binlog же не хранит никакой информации о старых данных, а тем более информации о селектах, поэтому нет никакой причины тормозить синк. Единственное место которое я вижу, где может повлиять размер таблиц - это неоптимизированные запросы, в которых используется какой нибудь file sort.
Это ресурсы не монолита, а дедиков, на которых базировался mysql. У нас 3 ДЦ, в каждом по master+slave, итого 6 ног. Ресурсы одной ноды - 1ТБ ОЗУ и 256 ядер.
На вопрос почему так много, нет точного ответа, но предполагаю, что эти сервера были собраны еще до того, как Еда, как проект, стала принадлежать Яндексу. Просто собрали сервера сильно с запасом, выкрутили настроечки в виде threads и buffer_pool_size в максимальные значения и в таком виде продалось Я. Ну а нам в целом, этого хватало с лихвой.
Может где то некорректно выразился но да, 3 ДЦ, в каждом master+slave. Galera cluster же это заворачивает в multi master схему, что позволяет писать в любой мастер из ДЦ. Слейвы для чтения, либо для замены вышедшего из строя мастера рамках ДЦ
А не было необходимости вроде. Проблема же не в том что данных очень много и выборки медленно работают, а в том что из за большого количества вставок в базу в моменте, данные не успевали доезжать до реплики из за чего мастер останавливался. Т.е. решать надо было что то с модифицирующими запросами. Вот тут про шардирование и репликацию ответил)
Наша проблема же заключалась в том, что у нас срабатывал flow control при большом RPS на insert, данные не успевали засинкаться с репликами (а galera cluster - это multi master схема). Поэтому не думаю, что партиции бы нам помогли в данном случае, ибо объем данных не меняется
Классическое шардирование возможно бы помогло, но тут несколько моментов:
Неизвестно, как себя поведет тот же галеровский wait sync с бОльшим количеством нод. Т.е. если один шард притупит, есть вероятность словить еще больше проблем (это просто предположение)
В конечном итоге, после таких оптимизаций, данные то никуда не денутся и в ближайшем будущем их все придется разносить по сервисам) А тут мы вроде и подготовились к реализации нового сервиса, перенеся данные в отдельную базу), и тут же нагрузку сняли с базы монолита
Изначально мы стали говорить про clickhouse и kafka, эти решения тяжелые и не универсальные для нашего случая, поэтому я в дополнение к тому, что они нам не подходят, добавил что это требует дополнительных сил в виде инфраструктуры) Проблем в коммуникации нет, просто у каждого свой бэклог/цели и нельзя просто принести огромный проект который сразу же все начнут делать
Первый десяток табличек где то за 3 месяца в 1 руки. Это со сборами всяких аппрувов под квоты на базы, написание кода и переключение. Когда попробовали и написали доку, тогда уже остальные команды стали разносить свои таблички, но опять же, занималась не фулл тайм. Итого где то до полу года ушло на все от старта, до решения основных проблем.
не совсем понял откуда у вас такой вывод получился? вроде про проблемы взаимодействия с другими отделами я ничего не писал
Хороший вопрос)
Т.к. TS у нас последовательный, то в обертке это выглядело по типу conn1->rollback();
conn2->rollback(); тут вроде проблем не словили
На эту ситуацию у нас был алерт и мы запускали вручную скрипт чтобы синхронизировать данные за какой то интервал времени. Но за весь период переноса, такая ситуация возникала буквально пару раз и то, потому что мы долго задерживались на стратегии когда писали в обе базы.
В целом, не изменилось. Так и есть, пик показывает, что основные проблемы были исправлены в конце 23, когда собрали самые проблемные запросы, всеми навалились и исправили. На остальном таймлайне просто хотелось показать, что мы продолжали мониторить запросы и в случае появления новых проблем их быстро правили. Сейчас, по выгрузкам мы видим, что "стреляющие" случаи - единичные, поэтому вкладываться в их оптимизацию нет имеет смысла.
А это же только в рамках выборки slow queries, а не всех запросов базы. Т.е. в эту выборку может попасть например 10 запросов за неделю, а для такого незначительного кол-ва думаю что приемлемо. К сожалению график собирал с агрегированных данных уже, поэтому кол-во этих запросов на тот момент посмотреть не получится
RPS в монолите не изменился никак, вроде и не должен был) Может имелось ввиду тайминги? Если да, то в моменте, когда писали в обе базы, на некоторых эндпоинтах выросли на ~100мс, после полного перехода тайминги пришли в норму
Нет, проблем не наблюдали, все как часики
Привет! Конкретно в нашем стриме, у нас экспертизы все таки больше с pg, все наши сервисы по дефолту работают с pg.
У нас все таки легаси монолит) Яндекс.Еда как проект, изначально принадлежал и разрабатывался другой компанией (до того как его купил Я.), решение в виде использования galera cluster принималось видимо по каким то своим соображениям, актуальным на тот момент. Могу предположить, что использовали из-за multi master схемы, которая одновременно позволяет и разгрузить бд, и особо не прилагать усилий для поддержки логики по получению неконсистентных данных из слейвов
kafka в нашем проекте у нас нет вообще, а затащить ее только ради этого очень дорого
Как уже сказал, хранятся они там по причине "исторически так сложилось, никто не переделывал". Использовать clickhouse актуально только для таблиц логов, а как я писал выше, переносили мы таблички не только с такими данными. Нужен был какой то универсальный инструмент, который могли бы использовать другие команды для своих таблиц.
Так же, все решения, которые нельзя реализовать в рамках приложения, требуют привлечения ребят из инфраструктуры, а это дополнительные ресурсы и время. В нашем решении пришлось привлечь ребят из инфры только чтобы получить квоты на создание баз. Остальное уже чисто руками разработчиков
Был вариант например, с вынесением таблиц при помощи DataTransfer, но нам он не подошел потому что там нет плавной раскатки. К тому же, при переключении приложения на новый коннект потребуется какой то небольшой downtime.
P.S. Хотя с помощью него мы уже успешно мигрировали базу в облако)
100к рпс да, это нормально, но у нас и не было проблемы с читающим трафиком, проблема именно с пишущим, когда прилетала большая пачка модифицирующих запросов и срабатывал flow control.