|
Рубрика:
Безопасность /
Вопрос-ответ
|
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
|
Обеспечиваем
безопасную эксплуатацию базы данных
Что для вас чаще всего является причиной инцидентов с БД? Как вы мониторите БД? Как у вас организованы бэкапы? Как вы проводите изменения схемы и миграции? Приходилось ли вам настраивать шардирование/партицирование, и что было самым сложным?
 На вопросы отвечает Георгий Кашинцев,
руководитель отдела SRE, Rambler&Co
«В реальных системах производительность БД определяется не только аппаратными ресурсами, но и качеством схемы, запросов и ключей распределения данных»
В практике эксплуатации высоконагруженных PostgreSQL-кластеров большинство инцидентов связано не с отказами аппаратных ресурсов, а с деградацией запросов по мере роста объёма данных. Типичный сценарий - запрос, который годами работал быстро, внезапно начинает перегружать дисковую подсистему после того, как таблицы перестают помещаться в памяти.
Например, это может быть связано с некорректно выбранным фильтром запроса или неправильно построенным индексом. В этом случае планировщик выбирает последовательное сканирование вместо использования индекса, что существенно снижает производительность.
Чтобы не реагировать на такие ситуации постфактум, мы уделяем большое внимание мониторингу. Метрики БД собираются через postgres_exporter и alligator (alligatormon) в Prometheus.
Для нас критичны утилизация соединений, лаг репликации, среднее время выполнения запросов, количество операций в секунду (insert, update, select, delete), а также объём прочитанных и записанных кортежей и число последовательных сканирований (sequential scan).
Такой набор позволяет заранее предсказать рост I/O-нагрузки в ближайшей и среднесрочной перспективе, а не дожидаться инцидента, связанного с деградацией производительности базы данных.
Резервное копирование построено по классической промышленной схеме: ежедневные полные бэкапы в сочетании с непрерывной архивацией WAL, что позволяет делать point-in-time recovery. Реплика используется в первую очередь для обеспечения отказоустойчивости, каждая реплика в момент падения primary-узла готова его заменить. Также реплика используется для масштабирования операций чтения. При этом реплика не должна рассматриваться как замена резервному копированию, хотя и повышает уровень доступности данных в любой момент времени.
Изменения схемы и миграции выполняются через CI-пайплайны с обязательной обратной совместимостью. Между релизами приложений эта совместимость сохраняется: новые поля добавляются заранее, а удаление устаревших колонок происходит спустя несколько релизов.
Для крупных таблиц мы избегаем установки значений по умолчанию при добавлении столбцов, чтобы не спровоцировать полную перезапись и блокировки.
В распределённых системах нам приходилось реализовывать шардирование. Ключевой вопрос здесь - выбор ключа шардирования и способ его генерации. Lookup-ключ, хранящийся в отдельной БД, упрощает миграцию и балансировку, но создаёт единую точку отказа. Хеш-ключ устраняет эту зависимость, однако усложняет расширение кластера без перераспределения данных. На практике именно ошибочный выбор ключа шардирования чаще всего приводит к необходимости радикально перестраивать архитектуру системы.
В реальных системах производительность БД определяется не только аппаратными ресурсами, но и качеством схемы, запросов и ключей распределения данных. Например, данные можно сконцентрировать на одном шарде под конкретный тип запросов, получая доступ за константное время, либо равномерно распределить их по кластеру для балансировки нагрузки.
Ключевые слова: базы данных, бэкап, изменения схемы и миграции, производительность БД, шардирование
Подпишитесь на журнал
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
|
Обеспечиваем безопасную эксплуатацию базы данных
