Как мы готовим 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

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

Шардирование по ключу 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/