Как мы готовим mysql / Николай Королёв (badoo)
TRANSCRIPT
Как мы готовим 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
ШАРДИРОВАНИЕ
Шардирование по ключу user_id
ШАРДИРОВАНИЕ
Шардирование по ключу 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/