Привет, Хабр!
О том, как правильно готовить кластеризацию для PostgreSQL, написано уже достаточно. А потому сегодня вашему вниманию предлагается небольшой сборник рекомендаций, как администратору СУБД под управлением Patroni гарантированно проснуться в три часа ночи от звонка из отдела мониторинга.
etcd — это просто хранилище конфигурации, ресурсы и обслуживание ему не нужны, ни в коем случае не тратьте на это время
Разумеется, нет совершенно никакого смысла вчитываться в документацию по такой незначительной части инфраструктуры, как кластер etcd, в особенности — если вы используете его для поддержания работоспособности сразу десятка кластеров баз данных. Забудьте и не вспоминайте, что там хранится еще и история ключей, в том числе — и те самые голосования и значения имени лидера, которые по умолчанию меняются раз в две секунды при работе Patroni.
Чтобы быть совершенно уверенным в неизбежности бодрящей ночной пробежки до рабочего места и гарантировать себе оплачиваемую (правда ведь?) переработку, нужно ни в коем случае не заглядывать вот в этот раздел документации и уж точно не трогать настройки параметра auto-compaction-retention. Особая рекомендация для эстетов: разместите базу данных etcd в самом маленьком разделе под завязку забитого тома, чтобы быть точно уверенным, что ваш администратор СХД не будет тратить время на такое скучное и лишнее дело, как сон.
Впрочем, если вы человек проактивный, выделите заранее как можно больше места. При выполнении рекомендаций выше увлекательные и совершенно не влияющие на работу низлежащего Patroni перезагрузки узлов etcd по 10+ минут в случае сбоя также могут скрасить скучное ожидание следующего рабочего дня.
API создаются для удобства — не стоит ограничивать к ним доступ
Забыли залогиниться под административной учетной записью на нужный хост? А etcd всё равно принял вашу команду на изменение ключей? Здорово! Не обращайте внимания, что в случае с Patroni среди ключей можно обнаружить такие приятные вещи, как archive_command. Команда позволяет, например, выполнить вообще любую команду на уровне хоста СУБД PostgreSQL с соответствующими правами. И правда ведь, злоумышленник — он на то и злоумышленник, чтобы воплощать всяческие пороки. Он, в отличие от вас, наверняка чертовски ленив. Будьте вежливы — не утруждайте и без того занятого человека получением доступа к нужному хосту и ни в коем случае не закрывайте общение между Patroni и etcd сертификатами SSL.
Обязательно храните логи в директории с СУБД
Сами подумайте — как удобно, если в процессе работы reinit после сбоя одного из узлов СУБД заодно будет очищена существенная часть уже устаревшей информации. Смело опускаем момент, что она говорит о причине произошедшего, нам это всё равно не нужно. Вы же человек неленивый, злоумышленником явно не являетесь — а значит, и без всяких подсказок от СУБД сможете выявить причины аварии. А даже если и нет — что же нам теперь, совсем по ночам не работать, если каждый сбой будет повторяться всего один раз? Для того чтобы сохранять гибкость ума и решать задачу по анализу неисправности вслепую, как настоящий эксперт, положите, пожалуйста, в ту же директорию журналы самого Patroni. Поверьте, так будет даже интереснее!
Вся репликация всегда должна быть синхронной
Мы уже выяснили, что вы человек добросовестный и ответственный. Поэтому ваши подсистемы СУБД должны соответствовать заданным высоким стандартам, даже вон та махонькая реплика с одной десятой частью ресурсов, добавленная в кластер исключительно для создания тестовых стендов. Она в случае чего обязана, как настоящий герой, принять на себя удар нетерпеливых пользователей и стать мастером или, на худой конец, синхронной репликой. Ни в коем случае не ограничивайте этот благородный порыв ключом nosync в локальной конфигурации такого ведомого сервера — он тоже хочет переработок, как и вы.
У вас и так две копии данных, а то и больше!
Не надо защищать свою СУБД резервным копированием поверх кластеризации — вы и так уже гарантировали себе бесперебойную работу, установив и настроив Patroni. В конце концов, если вдруг пользователь повредит данные на всех узлах разом удачной SQL-командой, не лишайте его удовольствия поиска потерянных или искаженных данных в других источниках. Достать из бэкапа корректную копию — это слишком просто. Пусть человек потрудится на благо компании, не мешайте ему быть героем!
Оставьте мониторинг в покое
Напоследок: оставьте вообще Patroni без внимания! Позвольте ему развиваться, как свободному персонажу, ведь лишь так вы сможете держать руку на пульсе своего кластера PostgreSQL. Игнорируйте все метрики, оставьте свои алерты в прошлом и наслаждайтесь спокойствием, ведь ничто не сможет нарушить работу вашей базы данных, пока Patroni работает в тени, исправляя сам все проблемы на лету.
Отличной ночи!
И да – не благодарите.