Как мы готовим MySQL

Как мы готовим MySQLНиколай КоролёвSite Reliability EngineerBadoo

• 320 млн пользователей

• 12 млн пользователей ежедневно

• 32 млн пользователей ежемесячно

• ~ 3000 серверов

О компании

C/Go9%

PHP32%

Other22%

Photos15%MySQL

22%

Наша инфраструктура

Подробнее о наших базах*

• 310 серверов

• 370 Тб

• 64 млн таблиц

• Пиковый QPS > 1 900 000

*кластер пользовательских данных

Секрет успеха DBA

• Стабильность работы баз данных

• Приемлемое время выполнения запросов

• Сохранность и доступность данных пользователей

Пользователь

Активный пользователь

Активный пользователь с подпиской

Пользователь глазами DBA

ШАРДИРОВАНИЕ


Старт проекта


Развитие проекта


Первая проблема

Варианты масштабирования

• Партицирование



• Репликация




• Репликация

• Шардирование



Шардирование по ключу user_id






набор шардированных таблиц, связанных с определенными пользователями

Спот – это …


Что такое UDB?

• KV Storage: user_id => spot_id

• HandlerSocket

✓QPS ~ 50k

✓Request time ~ 5ms


Что делать со spot_id?

В коде есть карта; оригинал карты в базе


Что получилось?

• Реализовали схему шардирования данных

• Создали кластер серверов бд - dbs

• Сделали сервис UDB и карту спотов


Badoo в 2006

РЕПЛИКАЦИЯ

Badoo в 2008


Badoo в 2008


• RTT ~ 120 ms• connect ~ 0.6 s

Badoo в 2008


A. Проблема внешняя:

– Запрос информации с удаленной площадки

B. Проблема внутренняя:

– Скрипты, работающие со всеми пользователями, работают слишком долго

Почему это проблема ?


Идея!


Требования• Данные только для чтения

• Нужна только часть спота

• Другой профиль нагрузки

=> репликация “много к 1”


Готовое решение? (2008)

MySQL replication:

1. Работает в 1 поток

2.Позволяет только схему “1 к 1”


Пилим велосипед: своя репликация

•Логирование

•Доставка

•Проигрывание


Логирование: пишем DML в таблицу


Доставка: сохраняем на диск


Доставка: сжимаем и отправляем


Проигрывание: распаковываем, применяем


Проигрывание: распаковываем, применяем


✓IOPS✓Memory (fs cache / running scripts )

Общая схема репликации


• Перезаливка полного отношенияИнструменты


• Перезаливка одной/нескольких таблиц в отношенииИнструменты


• Проверяем отставание репликации

• Репликационный лаг мы мониторим Zabbix-ом

Репликация: мониторинг


Плюсы и минусы нашего решенияМинусы:• Репликационный лаг от 10 сек до 1 мин• Диагностика и исправление проблем подразумевает наличие глубоких знаний о нашей системе


Плюсы и минусы нашего решенияМинусы:• Репликационный лаг от 10 сек до 1 мин• Диагностика и исправление проблем подразумевает наличие глубоких знаний о нашей системеПлюсы:• Репликация “много”=>”много”• Проигрывание репликации в несколько потоков• Инструменты для восстановления данных на реплике (dbb)


DDL

DDL

Зачем нам DDL?

DDL

Зачем нам DDL?

DDL

В споте этих изменений нет!

DDL

Миграция БД


DDL

Репликационная пара


До релиза задачи схема должна

быть изменена

DDL

Вот так выглядит флоу

• Разработчик ставит тикет на DDL (ALTER request)

• DBA делает ревью DDL

• Выполняется ALTER request на всём кластере

• Разработчик выкатывает фичу в продакшн

DDL

Выполнение DDL

• Обычный блокирующий ALTER / CREATE / DROP (MySQL 5.6 FTW)• Небольшой размер спота• Среднее время выполнения ~ 40 минут

DDL

Результат выполнения DDL•Скрипт отправляет письмо о завершении и его статусе

•DBA убеждается что ALTER успешно выполнен и закрывает тикет

•Разработчик может релизить свою задачу (договоренность)

DDL

• Разработчиков много => задач на DDL много

• “Легкие” DDL можно сгруппировать, но что делать с остальными?

• Нужна очередь

Растущие запросы на DDL

DDL

Очередь DDL

• Выстраивается вручную DBA

• По принципу FIFO

• Порядок очереди может быть нарушен

DDL

Вот так и живём!

DDL

Наш кластер• ~ 100 dbs

•Железо не гомогенное (серверы покупались в разное

время)

• Разное соотношение активных/неактивных пользователей

Устанавливаем новый сервер => появляются пользователи

На сколько хватит сервера?РАСПРЕДЕЛЕНИЕ НАГРУЗКИ

“Температура” спота

РАСПРЕДЕЛЕНИЕ НАГРУЗКИ

Жизненный цикл сервера


“Температура” спота v.2



Активный пользователь

Неактивный пользователь

CPU

Memory Disk space

IOPS

Каждому своё…

Разделяем профили нагрузки


Проект “кладбище”• Миграция осуществляется в фоновом режиме

• DBA активного участия не принимает

• Освободилось до 25% ресурсов основного кластера


last but not least

БЭКАП

Бэкап

• Общее количество спотов - 360 000

• Количество таблиц в споте > 80

• Общий объем данных > 190 Тб

Как это бэкапить?

БЭКАП

Условия успешного бэкапа• Консистентность данных важна в пределах спота

• Все таблицы в InnoDB

• Маленький размер спота

• DDL происходит по расписанию

mysqldump

БЭКАП

Схема бэкапа

БЭКАП

Итого мы бэкапим

• 25 Тб сжатых данных

• Время полного бэкапа - менее 24 часов

• Последняя копия – на sqlbackup

• Остальные – на ленте

БЭКАП

KISS

Спасибо!

Вопросы?

Николай Королёв[email protected]

@BadooDevhttps://habrahabr.ru/company/badoo/

https://tech.badoo.com/ru/

mailto:[email protected]

https://habrahabr.ru/company/badoo/

https://tech.badoo.com/ru/

Technology

Как мы готовим MySQL