Download to read offline
Uploaded byBadoo Development
Как мы готовим MySQL
Документ описывает использование MySQL в компании Badoo, которая обслуживает более 320 миллионов пользователей с усредненной нагрузкой на 3000 серверов. Рассматриваются механизмы масштабирования и шардирования баз данных, а также процесс репликации и бэкапа данных, включая плюсы и минусы каждой стратегии. В заключение приводится информация о процессе выполнения DDL и обработки запросов на изменение структуры базы данных.
More Related Content
Как мы готовим MySQL
- 1. Как мы готовим MySQL НиколайКоролёв Site Reliability Engineer Badoo
- 2. • 320 млнпользователей • 12 млн пользователей ежедневно • 32 млн пользователей ежемесячно • ~ 3000 серверов О компании
- 3.
- 4. Подробнее о нашихбазах* • 310 серверов • 370 Тб • 64 млн таблиц • Пиковый QPS > 1 900 000 *кластер пользовательских данных
- 5. Секрет успеха DBA •Стабильность работы баз данных • Приемлемое время выполнения запросов • Сохранность и доступность данных пользователей
- 6.
- 7.
- 8. Активный пользователь сподпиской
- 9.
- 10.
- 11.
- 12.
- 13.
- 14. • Партицирование • Репликация Вариантымасштабирования ШАРДИРОВАНИЕ
- 15. • Партицирование • Репликация •Шардирование Варианты масштабирования ШАРДИРОВАНИЕ
- 16. Шардирование по ключуuser_id ШАРДИРОВАНИЕ
- 17. Шардирование по ключуuser_id ШАРДИРОВАНИЕ
- 18. Шардирование по ключуuser_id ШАРДИРОВАНИЕ
- 19. набор шардированных таблиц, связанныхс определенными пользователями Спот – это … ШАРДИРОВАНИЕ
- 20. Что такое UDB? •KV Storage: user_id => spot_id • HandlerSocket ✓QPS ~ 50k ✓Request time ~ 5ms ШАРДИРОВАНИЕ
- 21. Что делать соspot_id? В коде есть карта; оригинал карты в базе ШАРДИРОВАНИЕ
- 22. Что получилось? • Реализовалисхему шардирования данных • Создали кластер серверов бд - dbs • Сделали сервис UDB и карту спотов ШАРДИРОВАНИЕ
- 23.
- 24.
- 25.
- 26. • RTT ~120 ms • connect ~ 0.6 s Badoo в 2008 РЕПЛИКАЦИЯ
- 27. A. Проблема внешняя: –Запрос информации с удаленной площадки B. Проблема внутренняя: – Скрипты, работающие со всеми пользователями, работают слишком долго Почему это проблема ? РЕПЛИКАЦИЯ
- 28.
- 29. Требования • Данные толькодля чтения • Нужна только часть спота • Другой профиль нагрузки => репликация “много к 1” РЕПЛИКАЦИЯ
- 30. Готовое решение? (2008) MySQLreplication: 1. Работает в 1 поток 2. Позволяет только схему “1 к 1” РЕПЛИКАЦИЯ
- 31. Пилим велосипед: своярепликация •Логирование •Доставка •Проигрывание РЕПЛИКАЦИЯ
- 32. Логирование: пишем DMLв таблицу РЕПЛИКАЦИЯ
- 33. Доставка: сохраняем надиск РЕПЛИКАЦИЯ
- 34. Доставка: сжимаем иотправляем РЕПЛИКАЦИЯ
- 35.
- 36. Проигрывание: распаковываем, применяем РЕПЛИКАЦИЯ ✓IOPS ✓Memory (fscache / running scripts )
- 37.
- 38. • Перезаливка полногоотношения Инструменты РЕПЛИКАЦИЯ
- 39. • Перезаливка одной/несколькихтаблиц в отношении Инструменты РЕПЛИКАЦИЯ
- 40. • Проверяем отставаниерепликации • Репликационный лаг мы мониторим Zabbix-ом Репликация: мониторинг РЕПЛИКАЦИЯ
- 41. Плюсы и минусынашего решения Минусы: • Репликационный лаг от 10 сек до 1 мин • Диагностика и исправление проблем подразумевает наличие глубоких знаний о нашей системе РЕПЛИКАЦИЯ
- 42. Плюсы и минусынашего решения Минусы: • Репликационный лаг от 10 сек до 1 мин • Диагностика и исправление проблем подразумевает наличие глубоких знаний о нашей системе Плюсы: • Репликация “много”=>”много” • Проигрывание репликации в несколько потоков • Инструменты для восстановления данных на реплике (dbb) РЕПЛИКАЦИЯ
- 43.
- 44.
- 45.
- 46. В споте этихизменений нет! DDL Миграция БД
- 47. В споте этихизменений нет! DDL Репликационная пара
- 48. В споте этихизменений нет! До релиза задачи схема должна быть изменена DDL
- 49. Вот так выглядитфлоу • Разработчик ставит тикет на DDL (ALTER request) • DBA делает ревью DDL • Выполняется ALTER request на всём кластере • Разработчик выкатывает фичу в продакшн DDL
- 50. Выполнение DDL • Обычный блокирующийALTER / CREATE / DROP (MySQL 5.6 FTW) • Небольшой размер спота • Среднее время выполнения ~ 40 минут DDL
- 51. Результат выполнения DDL •Скрипт отправляет письмо о завершении и его статусе • DBA убеждается что ALTER успешно выполнен и закрывает тикет • Разработчик может релизить свою задачу (договоренность) DDL
- 52. • Разработчиков много=> задач на DDL много • “Легкие” DDL можно сгруппировать, но что делать с остальными? • Нужна очередь Растущие запросы на DDL DDL
- 53. Очередь DDL • Выстраиваетсявручную DBA • По принципу FIFO • Порядок очереди может быть нарушен DDL
- 54. Вот так иживём! DDL
- 55. Наш кластер • ~100 dbs • Железо не гомогенное (серверы покупались в разное время) • Разное соотношение активных/неактивных пользователей Устанавливаем новый сервер => появляются пользователи На сколько хватит сервера? РАСПРЕДЕЛЕНИЕ НАГРУЗКИ
- 56.
- 57.
- 58.
- 59. РАСПРЕДЕЛЕНИЕ НАГРУЗКИ Активный пользователь Неактивный пользователь CPU Memory Diskspace IOPS Каждому своё…
- 60.
- 61. Проект “кладбище” • Миграцияосуществляется в фоновом режиме • DBA активного участия не принимает • Освободилось до 25% ресурсов основного кластера РАСПРЕДЕЛЕНИЕ НАГРУЗКИ
- 62. last but notleast БЭКАП
- 63. Бэкап • Общее количествоспотов - 360 000 • Количество таблиц в споте > 80 • Общий объем данных > 190 Тб Как это бэкапить? БЭКАП
- 64. Условия успешного бэкапа •Консистентность данных важна в пределах спота • Все таблицы в InnoDB • Маленький размер спота • DDL происходит по расписанию mysqldump БЭКАП
- 65.
- 66. Итого мы бэкапим •25 Тб сжатых данных • Время полного бэкапа - менее 24 часов • Последняя копия – на sqlbackup • Остальные – на ленте БЭКАП
- 67.
- 68.