Хабрахабр

Разговоры про PostgreSQL. Интервью с Алексеем Лесовским в подкасте «Цинковый прод». Часть первая

Разговор получился интересный и познавательный, поэтому предлагаю вашему вниманию расшифровку этого выпуска. Недавно мы пригласили в эфир "Цинкового прода" Алексея Лесовского из компании Data Egret. Если лень ждать продолжения — можно просто послушать аудиоверсию здесь. Из-за внушительного объема пришлось разбить текст на части.

Всем привет, это сороковой выпуск подкаста "Цинковый прод", и с нами в студии постоянные ведущие Антон Околелов, Никита Васильченко и Грицак Олег.

Лёша, представься пожалуйста, кто ты, чем занимаешься и так далее. Антон: Итак, у нас сегодня гость, Алексей Лесовский.

Я занимаюсь администрированием Постгреса, я PostgreSQL DBA (database administrator), работаю с посгресом каждый день, 7 дней в неделю, и администрирую клиентские базы данных. Алексей: Всем привет, меня зовут Алексей Лесовский, как меня Антоха уже представил. И к нам приходят самые разные люди со своими базами данных, как правило это компании — мелкие крупные небольшие, всякие разные, — у них с базой данных есть проблемы, мы эти проблемы анализируем и как-то пытаемся их устранить. У нас контора — она консалтинговая, занимается администрированием, поддержкой, сопровождением. Как-то так. Собственно, решаем проблемы других людей, других компаний.

Ну а в свободное время я люблю заниматься разными делами, гулять по лесу, кататься на сноуборде, ходить в походы, пить пиво

Антон: копченое пиво пить

Никита: перед выпуском Лёха рассказывал про копченое пиво

Раухбир мерцен. Алексей: да, копченое пиво, есть такое, очень вкусное, рекомендую.

Насколько это тяжело? Антон: ну ладно, скажи пожалуйста, ты дба-шник, работаешь уже давно, несколько лет. Я тебе звонил в пять утра где-то год назад или полтора. Тебе звонят ночью и просят починить базу.

Алексей: да, было, было дело.

Антон: как ты вообще выживаешь, расскажи

До 2014 я работал линуксовым администратором в веб разработке. Алексей: слушай, дба я работаю с 2014 года. Админил много всего, у нас была kvm-виртуализация, было много линуксов, были всякие Руби-он-рейлс, nginx-ы, php, рельсы...

Олег: Докер уже был?

Алексей: докер только начинался, мы его в продакшн нигде не вводили, но уже начинались тенденции к этому.

Потом я погнался за длинным рублем и решил, что можно работать на двух работах одновременно. И было много постгреса у нас в конторе. Я две работы совмещал, там как раз базы администрировались Postgresql consulting-ом. И начал еще работать админом удаленно на московскую контору. Ну, т.е. Там был Макс Богук, Илья Космодемьянский, и я как администратор начал делать часть задач связанных с посгресом. И вот мне в какой-то момент Макс такой говорит: слушай, а давай ты к нам пойдешь работать. я начал у них хлеб по-тихоньку отбирать. Уйдешь со всех своих работ, подработок, пойдешь к нам на фултайм.

Т.е. Ну, я согласился, я не стал раздумывать, мне в принципе предложили зарплату сопоставимую, и я устроился на одну работу и стал из дома работать, и вот я уже с 2014, получается, 5 лет работаю дба, работаю конкретно с посгресом, ну и по-старинке всякие админские темы, с ними работаю по привычке. если у нас в компании появляется задача с чем-нибудь разобраться с админской стороны, мне скидывают, я разбираюсь

Это не просто там, база в вакууме, она ведь где-то крутится, надо настроить операционную систему, правильно ведь? Антон: Ну а вообще, дба обязательно знать эти админские штуки?

он как бы сам не оперирует ресурсами напрямую, он как бы сгружает эти все работы операционной системе, а она сама разруливает дисковый ввод-вывод, управление страницами памяти, вот это всё, переключение процессов, и соответственно, если ты сталкиваешься с затыком постгреса, нужно еще и немного в операционной системе "рубить", как там всё работает и как это работает на стыке с постгресом. Алексей: да, да, именно так, потому что постгрес он вообще очень сильно полагается на подсистемы операционной системы, на виртуальную память, на управление дисками, т.е.

они мимо операционной системы, напрямую с диском могут работать, а в Посгресе такого нет, ты должен знать, как операционная система работает с базой. Если, допустим, сравнивать с Ораклом, у Оракла есть, например, свои подсистемы, которые работают с вводом-выводом, т.е.

Олег: приходилось постгрес на Винде поддерживать?

У них база была на Винде, это было вообще страшно, мы подключались по терминальному протоколу какому-то, открывался Remote Desktop, мы запускали там какие-то штуки связанные с записью перфоманса. Алексей: да, приходилось, у нас есть клиент, они с Виндоусом, мы обслуживали Питерскую контору какую-то, делали им аудит базы данных. А сейчас клиенты в основном все на Линуксе сидят. Короче, было тяжело, страшно, как страшный сон сейчас вспоминается. Практически на винде никого нет.

Олег: а какая сейчас основная боль на Постгре, которую у всех можно заметить?

Ну, мультимастер, понятно, штука такая, недостижимая. Алексей: очень много людей хотят автофейловер и мультимастер. Но все поработали с Галерой (с Mysql), и такие говорят: почему, мы в поcгресе тоже хотим мультимастер.

Но люди хотят мультимастер. Ну, в посгресе есть такие штуки, но только не в самом посгресовом ядре, есть такие штуки, которые реализуют типа мульти-мастер, но еще не продакшен совсем. Но сейчас слава богу появился Patroni, на Patroni можно автофейловер делать, люди потихоньку внедряют. И еще люди хотят автофейловер. Многие крупные компании его уже внедряют. Ну и вообще с моей точки зрения Patroni стандартом де факто уже стал. Тот же Гитлаб, они недавно делали доклады, они Патрони используют, всем довольны, всем рады.

Нас слушают в основном тимлиды и программисты Антон: Слушай, а можешь рассказать в двух словах рассказать, что такое патрони для простых программистов?

Никита: подождите, а можно я вас перебью, и попрошу еще более для непрограммистов объяснить, что такое мультимастер

Он их складывает в базу, в посгрес. Алексей: смотри, представим вот, Антоха — программист, он пишет приложения, а приложению надо хранить где-то свои данные. Блок питания сгорел, а приложению нужно продолжать работать с базой. В какой-то момент база размещена на одном сервере, а потом сервер раз — и перестал работать. И либо переключиться на нее, а в идеале никакого переключения не делать, чтобы наше приложение знало про эту вторую базу и в нее продолжала писать. И здесь возникает вариант, что нам нужно иметь какую-то копию базы и продолжать с ней работать.

Самый распространенный пример — нельзя писать одни и те же данные, условно говоря, в два инстанса, например работать с одной и той же таблицей, писать в одну и ту же таблицу через два сервера, там будут возникать конфликты и их нужно разруливать, это проблема, поэтому нужжно писать если пишем в одну таблицу, то пишем только через один сервер. Это собственно и есть мультимастер, когда у нас есть несколько узлов, доступных на чтение и на запись, и наше приложение может с ними одновренменно работать и писать данные в любой из этих узлов и читать данные из этих узлов, но природа так устроена, что это не совсем в идеале достигается, и есть свои плюсы и минусы, есть свои недостатки, свои юз кейсы использования мультимастера.

Никита: и это непосредственно с аутофейловером, да, связано?

Если мы не можем себе позволить мультимастер, то мы хотим какой-то прозрачный механизм, который будет переключать запасной узел в режим мастера, т.е. Алексей: да, и это связано с автофейловером, тут как бы одно вытекает из другого. Хочется какого-то прозрачного механизма, который где-то под капотом сработает, переключит базу, и наше приложение будет работать с тем же самым адресом и продолжать читать из этой базы. у нас есть приложение, оно работает, и как только у этого приложения из под ног выбили базу данных, разработчик не хочет менять конфиги этого приложения и указывать там новый адрес базы данных, перезапускать приложение, особенно если приложений много. Для этого уже нужен автофейловер, который прозрачно переключает запасной узел в режим мастера, и для этого как раз используется Patroni

Антон: Patroni — это чисто переключалка или это форк постгреса, какая-то надстройка?

И он следит за состоянием постргесового кластера. Алексей: это, так скажем, отдельная служба, отдельный процесс, который работает на хосте с базой данных. Но мы же получаем в этом случае распределенный кластер, у нас же неслколько узлов в кластере, мастер и несколько реплик. Тут преследуется две цели — автофейловер и управление кластером. Если он вдруг умер — нужно переключить на роль "мастер" другой сервер. Соответственно нужно постоянно отслеживать состояние кластера, постоянно смотреть, жив ли мастер. Есть вариант, когда каждая из нод кластера — они проверяют друг друга. И для этого используется, вообще есть два подхода, как поддерживать этот кластер view, представление в кластере, как он должен жить в текущий момент. вне посгресового кластера. А можно хранить снаружи этот стейт, т.е. Это как правило DCS какой-то (система распределенного хранения конфигурации). И вот как раз Патрони использует этот подход, он берет и хранит состояние кластера в третьей системе. Т.е. Это может быть etcd, consul, либо это может быть куберенетесовский etcd. Ну и соответственно Patroni просто сохраняет стейт кластера в этой системе DCS и его обновляет. в зависимости от того, что в инфраструктуре есть.

Если это мастер, допустим, упал, выбирается новый мастер, и этот стейт снова обновляется в DCS. Если вдруг какой-то из узлов вдруг выходит из строя, происходит выбор нового узла. И вот засчет DCS Patroni поддерживает работоспособность кластера.

Антон: А если сеть мигнула между Patroni и базой?

Рассмотрим простой случай, допустим, это сервер. Алексей: Ну смотри, есть база данных, это либо какой-то сервер, либо это, допустим, в кубернетесе это может быть какой-то под. Это легковесный процесс, они работают на одном хосте и общаются условно говоря по локалхосту. На этом же сервер у нас запущена база, и на этом же сервере мы запускаем агента Patroni. У нас может сеть мигнуть между хранилищем DCS и узлом, где работают база и Patroni.

В зависимости от того, насколько тяжелое это сетевое моргание происходит. Тут разные могут быть варианты. Они просто выберут нового мастера, а старый мастер он увидит, что он изолирован, и Patroni перезапустит его в режиме read only. Бывает, что, если это был мастер, и он оказался изолированным, то остальные узлы обнаружат, что мастер пропал. Плохо, если у нас приложение будет писать в два узла одновременно. Ну, чтобы не было сплит-брейна. Поэтому патрони просто перезапускает узел в read only и всё, и он работает. Потом разработчикам придется данные разгребать, а это очень тяжелая такая работа — чтобы в консистентный вид эти данные собрать. Скорее всего этот изолированный узел, который был старым мастером, он подключится в качестве реплики к новому мастеру... Как только сеть восстановится, Patroni сможет достучаться до DCS, они уже там дальше согласуют cluster view и прийдут к какому-то согласованному решению.

Ну ладно, а на практике как это работает? Антон. Чтобы вот Олег взял и внедрил у себя, например, Patroni, ему надо принять для этого решение. Есть ли какие-то проблемы, подводные камни.

Да, прям сразу Олег.

Ну смотри, мы используем Patroni у клиентов начиная с прошлого года. Алексей. И мы в то время не очень хорошо представляли как с этим работать, но за год мы поработали, в принципе нас все устраивает. У нас первый клиент появился по-моему в ноябре 2018-го. В принципе, чтоб довести его до ума, в общем-то не очень нужно много шагов, буквально два-три действия со стороны постгреса, со стороны конфигов патрони, и все это работает довольно-таки хорошо. Мы научились его готовить.

Она во-первых простая, она написана на Питоне, она ест мало памяти и работает в принципе надежно. Штука надежная. Но как правило это надо либо Consul либо etcd. Единственное, что в инфраструктуре должна быть эта DCS. Но у многих компаний эта штука уже используется для всяких разных service discovery, поэтому с этим проблем, как правило, нет.

А какие проблемы возникают: самая основная проблема, про которую не сразу народ вчухивает — то, что при автофейловере мы можем потерять какую-то часть данных

Олег: из-за лага репликации?

Допустим был какой-то лаг репликации, происходит выбор нового мастера среди других реплик. Алексей: представим себе ситуацию, когда автофейловер происходит при репликации, старый мастер ушел в оффлайн, но какую-то часть данных мы в него все равно при этом записали. И в этот момент он запускает команду pg_rewind. Поднимается новый мастер и если у нас Патрони настроен таким образом, чтобы упавший узел автоматически включать в кластер, допустим, автозапуск сервисов включен, то когда старый мастер поднимется, он увидит, что он уже не мастер, он отстает, он попытается подключиться к новому мастеру и стать его репликой.

В этот момент мы можем потерять часть данных. Эта команда отматывает журнал транзакций на старом узле (старом мастере) до того момента, чтобы получить возможность подключиться к новому мастеру, то есть затирается журнал транзакций. Если, например, все реплики имеют большой лаг, то выборы просто не будут инициированы, и тут нужно уже ручное вмешательство админа, чтобы админ пришел и руками запустил автофейловер. В самом Патрони есть защита небольшая, есть некоторые крутилки, которые позволяют при большом отставании репликам не участвовать в выборах. Пока не восстановится его работа. Либо они все будут ждать пока старый мастер поднимется. И они уже к нему подключатся и будут его дальше нагонять.

Ну то есть в Патрони есть механизмы, которые позволяют не терять данные, но риск есть, поэтому надо аккуратно

Антон: а если синхронную репликацию включить?

Не каждый может пойти на эту сделку. Алексей: синхронна репликация, тут видишь, когда мы синхронную репликацию испльзуем, мы теряем в производительности. Но если у нас используется несколько узлов, допустим больше двух, то нужно еще рассматривать вариант, когда у нас происходит авария и на мастере, и на синхронной реплике. Но если мы используем синхронную репликацию, риск потери данных снижается. Возможны разные варианты, их нужно оценивать, смотреть и понимать, подходит нам такое поведение или нет. И у нас остается вторая реплика, и может получиться так, что мы можем запромоутить её, и часть данных снова потерять.

Антон: слушай, сразу два сервера чтобы отвалились — это как предусматривать нашествие инопланетян

Алексей: и на старуху бывает проруха

Олег: ты вспомни как раз-таки звонок в пять утра Леше в последний раз, с чем оно было интересно связано, Антон, а не то, что у нас сразу две базы упали?

Ну да, такое бывает. Антон: это был человеческий фактор.

Алексей: я кстати не помню причину звонка

А систем могла и на одном работать, но один перевезли в другой дата-центр, включили. Антон: мы там переносили два сервера, они работали параллельно, записывали данные, не важно. В общем у нас два сервера упало, стали подниматься, а так как они были жестко настроены на запись, у них чекпоинты редкие были очень или что-то такое. Второй пока перевозили, и там какой-то проводок задели в момент установки, и старый тоже вырубился — что-то перепутали. Он долго запускался, мы не понимали, что происходит

Олег: сто гигов wal-логов

Ну собственно там особо ничего и не сделать было... Антон: мы не понимали, что происходит, почему не запускается и в итоге пришлось звонить.

Алексей: ну там единственное, что мы наверно подключились, посмотрели что все в порядке

Олег: подтвердили смерть пациента

Антон: по сути надо было только ждать, по большому счету.

Да, ну это известная проблема. Алексей. Есть такая проблема. При некоторых настройках чекпоинты долгие.

Так вот, если вспоминать, то ну может раз в полгода кто-нибудь позвонит Но вообще если вспоминать этот ночной звонок, нас на практике редко звонят по ночам, у нас настрена автоматика специальная — дежурные, всё как полагается, выбираются по специальному графику.

Олег: всё с нашей компании наверно

Алексей: нет, разные

Антон: Олег, звони чаще

Олег: мы сегодня свитчовер будем делать, как раз звонить видимо буду

Алексей: у нас парни есть, у них вечернее время перекрывается, они как раз будут работать

Чем они отличаются, какие бывают Антон: слушай, Леха, ты говорил, что у Патрони есть какие-то аналоги.

В ней реализован механизм, когда узлы кластера постгресового проверяют друг друга, кто живой, кто не живой. Алексей: вариантов в общем-то два, есть repmgr, эта штука появилась давным-давно, лет 10 назад. Но на мой взгляд это не очень, такая схема работы мне не очень нравится.

А если хочется прямо автофейловер, то там нужно отдельный поставить демонок repmgrd, и, получается, автофейловер у нас заводится. И там автофейловера из коробки нет, repmgr изначально заточен именно на управление кластером и на ручное переключение, на свитчовер. Нужно отдельно его ставить. Штука удобная, хорошая, но да — автофейловера из коробки у нас нет. Она такая гибкая, кастомизируемая. Вообще штука хорошая, удобная, в том плане, что она хорошо конфигурируется, удобно кластеры посгресовые поддерживать. Из бекапов, из реплик наливать других, из мастера. Реплики можно наливать самыми разными способами. И в нее очень много фич разных натолкали, она очень хорошая. Короче, такая гибкая штука, потому что 10 лет.

Он появился примерно в то же время, когда и Patroni, чуть позже. А другой вариант — это Stolon. Написан он на Go.

Если открыть сайт проекта, там будут картинки, и сам Stolon состоит из нескольких компонентов. Но у него более развесистая архитектура. Потом есть так называемые Sentinel узлы. У него есть keeper узлы, которые работают с БД, которые поднимают Постргес. Управляют они состоянием кластера и переконфигурируют его в случае чего. Они отслеживают состояние кластера, проеверют его доступность, проверяют, что ноды живы или не живы.

Приложение клиентское работает именно с проксями. И есть так называемые прокси-узлы, через них идет весь трафик. Т.е. И как раз-таки, если какой-то из узлов сваливается, прокси перераспределяют поток трафика на другие узлы. И также, как и патрони, Stolon хранит конфиграцию в системе DCS, это может быть consul, etcd. это по сути балансировщики. И как-то вот он так работает на развесистой архитектуре.

А для Кубернетеса это подходит гораздо лучше. Мне он нравится меньше, потому что в нем как раз-таки много компонентов, и если на bare metal это развертывать, то получается, что тебе все эти компоненты надо где-то размещать, отдельные серверочки держать. Потому что мы можем все эти компоненты ( они легковесные довольно-таки) запустить в отдельных подах, и они будут в отдельных подах работать, и это больше подходит под архитектуру Кубера.

Он не поддерживает гибкое конфигурирование узлов. Но если сравнивать его с патрони, он по фичам гораздо беднее. Допустим, мы можем иметь аналитическую реплику с одним набором настроек. Например, с помощью Патрони мы можем разную конфигурацию иметь для разных Посгресов. А в Stolon как ты определил конфигурацию, и эта конфигурация будет для всех узлов. И можем иметь для oltp-нагрузки отдельную реплику с другим набором настроек.

Они зашиты в исходниках Столона, при установке они устанавливаются, и всё. И там есть некоторые настройки, штук 6 или 8, их вообще нельзя переопределить. И Столон не позволяет ее регулировать, меня этот момент довольно-таки сильно смущает. Они нечастно нужны, но есть одна настройка — wal_keep_segments — она чисто дба-шная штука, очень часто бывает, что ее нужно подкрутить, поменять. Он новую реплику создает всегда с мастера. Плюс, у Столона ограниченный функционал по созданию новых реплик. нельзя новую реплику создать на основе другой реплики, чтобы не грузить мастер. Т.е. Такое не поддерживается, там создание новой реплики — это всегда нагрузка на мастер. Или, допустим, налить ее с бекапа. Но это не очень удобно бывает.

Если не ошибаюсь, с кластеризацией тоже связано. Олег: кстати, работал, слышал ли что-нибудь про Citus?

Citus недавно приобрели Майкрософтовцы, они делали колоночную базу баднных CitusDB, по-моему. Алексей: Citus — там есть два момента. По сути это тот же самый посгрес, но у него есть отдельное расширение, которое добавляет колоночный формат хранения, который для аналитических ворклоадов

Антон: типа кликхауса?

Со всеми его плюсами и минусами. Алексей: ну да, типа того, но на основе Постгреса. Изначально это тоже был экстеншн к посгресу, он позволял организовывать автофейловер в кластере. Но они как бы в мае этого года выпустили такую штуку, называется pg autofailover. Ну, вокруг этого экстеншена появилась дополнительная инфраструктура, И засчет этой инфраструктуры можно городить всякие автофейловеры. Потом они пошли дальше, в конце лета они его допилили, появился отдельный демон. Потому что штука молодая, там наверняка еще куча багов всяких есть, а у нас уже есть хорошо работающий Патрони. Но я честно скажу, я не пробовал, не смотрел. смысла на него пока обращать внимания не особо много. Т.е.

Если я правильно понял, он под капотом держит тоже несколько постгресов, и он даже может джойны по всем этим нодам прогонять. Олег: про Citus. Там фишка — это большие джойны, и он там побежал...

Алексей: ну, да, да

Олег: интересно, этот инструмент и подобные инструментарии, они спокойно выкатываются на продакшен или там надо с нуля пересобирать, грубо говоря, схемы там допиливать, таблички

А так, чтобы поверх посгреса, я думаю, что мало вероятно. Алексей: я думаю, что можно просто взять его, поставить отдельно и начать его использовать. Погонять его в тестовой лабе в принципе можно, но в целях ознакомления. Но мы с ним "in the wild" не ставились.

Продолжение расшифровки выпуска будет выложено на Хабр в ближайшее время, а пока что подписывайтесь на подкаст "Цинковый прод", впереди много интересного!

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть