Вы только что установили PostgreSQL и запустили свой первый кластер, создали несколько таблиц, загрузили данные и даже немного изменили конфигурацию PostgreSQL для повышения производительности.
Теперь вы думаете о том, как обеспечить высокую доступность вашего кластера.
К сожалению, сам PostgreSQL не имеет возможности выполнять автоматическое переключение при недоступности мастера, но, к счастью для нас, этого можно добиться с помощью сторонних утилит. Задача ясна, и вы начинаете изучать преимущества и недостатки всех утилит, чтобы выбрать лучшую.
И.
вы уже на неправильном пути, потому что в первую очередь вам надо определиться со значениями SLA, RTO и RPO. В этом докладе я планирую рассказать о ряде ошибок, которые допускают администраторы баз данных при настройке и эксплуатации высокодоступного кластера Postgres с автоматическим аварийным переключением.
Привет! Меня зовут Александр.
Я живу в Берлине уже 6 лет. Я работаю в Заландо.
Люди знают меня как разработчика Postgres-решения высокой доступности для автоматического переключения под названием Patroni. 
Я думаю, что многие из вас наверняка имеют представление о том, что такое Заландо.
Если нет, то это брат или сестра Ламоды.
Но мы работаем в Европе и в Россию ничего не поставляем.
Наш бизнес очень активно использует Postgres. И у нас еще много аппаратных кластеров в дата-центре.
Около 4 лет назад мы начали активно запускать новинки на Amazon. И они начали переносить не особо активные старые кластеры на Амазон.
Первая цифра медленно падает, вторая растёт, и растёт довольно быстро.
Некоторые кластеры в Amazon работают на инстансах EC2, некоторые — на Kubernetes, который снова работает на инстансах EC2. 
И я получаю много вопросов о том, как сделать что-то лучше.
Или люди имеют неверные ожидания от системы в отношении высокой доступности.
И я решил сделать доклад на эту тему, чтобы объяснить, что такое высокая доступность и как она связана с аварийным восстановлением, и почему одно не может жить без другого.
Я также расскажу вам, что вам нужно знать при построении системы высокой доступности и как правильно выполнять автоматическое переключение при отказе.
Я расскажу о нескольких инцидентах, которые публично обсуждались и были обнародованы по всему миру.
Эти инциденты не от нашей компании, но с ними все равно очень полезно ознакомиться, потому что полезно учиться на чужих ошибках.
Давайте обсудим ряд проблем, которые HA не должен решать, хотя люди этого ожидают. И в заключение дам вам несколько советов.
Начнем с простого (или сложного?).
Что такое высокая доступность или HA? 
Начнем с действительно простых.
Что такое доступность? Доступность очень проста.
Мы измеряем время, в течение которого система была доступна.
Например, в течение года делим на общее время, т.е.
когда система была доступна и недоступна.
И мы получаем значение доступности.
Причины недоступности могут быть разными.
Это какая-то плановая работа, когда мы, например, хотим обновить оборудование, переехать на другой сервер, обновить биос или какое-то программное обеспечение.
Бывают незапланированные простои.
Центр обработки данных может быть поврежден наводнением, извержением вулкана или чем-то еще.
Или, например, кто-то перерезал кабель, причем другой: сетевой или электрический.
Сеть может быть повреждена.
Ваш сервер может сгореть.
Ведь это все программное обеспечение, не лишенное ошибок.
Ошибки случаются.
Или просто человеческая ошибка.
Иногда люди удаляют данные по ошибке, удаляют таблицу, запускают обновление или удаление без предложенияwhere. Иногда даже просто удаляют каталог, что тоже бывает. 
Теперь вернемся к доступности.
Измеряется в девятках.
Все начинается с двух девяток и заканчивается семеркой, восьмеркой, девяткой.
Если учесть, сколько времени система может быть доступна или недоступна в году, то в двух девятках это три с половиной дня.
Это довольно много.
Вы можете отключать сервер на 15 минут в день и при этом находиться в пределах этих двух девяток.
Есть одна очень интересная вещь вроде 99,95%, то есть три с половиной девятки.
Почему я поместил это здесь? Потому что, например, Amazon, когда тебе продают RDS, они гарантируют эти три с половиной девятки.
Это не три девятки и не четыре, но это и не совсем середина, если посмотреть, как долго система может быть недоступна.
И чем больше девяток мы наберём, тем быстрее нам придется переключиться в случае неудачи.
Уже при семи девятках в году мы не можем быть недоступными более трёх секунд. Это очень маленький разрыв.
И только гигантские корпорации, такие как Google или Amazon, могут позволить себе создавать системы, доступные более чем в семи девятках или восьми девятках.
Что такое высокая доступность? На самом деле официального определения не существует. Существует определение IBM, согласно которому высокая доступность измеряется числом девяток.
А если девяток больше, то есть и другие названия.
В Википедии есть фраза, что это характеристика системы, нацеленная на некоторый уровень производительности или доступности, превышающий некоторые согласованные значения.
Здесь речь идет о какой-то договоренности.
Что это? На самом деле существует такое понятие, как уровень согласованного сервиса.
Я не знаю, как это перевести на русский.
Но это стандартная вещь.
Это соглашение, в котором описывается тип предоставляемой нами услуги, как она контролируется, что мы должны иметь с точки зрения производительности, доступности и т. д. Как мы можем сообщать о любых проблемах с услугой, как поставщик услуг должен реагировать на эти проблемы.
и как быстро они должны быть решены.
Соответственно, мониторинг также отвечает за измерение некоторой услуги индикации уровня.
Например, наша доступность.
А сервис уровня цели – это самое последнее, что вам отсюда нужно знать.
Оно говорит нам, к какому уровню мы стремимся.
Те.
мы хотим, чтобы наша доступность была, например, четырьмя девятками.
Если мы не набрали за год четыре девятки, значит, мы нарушили договоренность и за этим обычно следуют какие-то санкции.
Давайте еще раз посмотрим, какие могут быть причины недоступности.
Могут возникнуть проблемы:
- С железом.
- С сетью.
- Полностью с дата-центром.
- С программным обеспечением.
- Или ошибка пользователя.
Какой из них может решить наше автоматическое переключение? Явно не весь класс проблем.
Ряд проблем можно решить только с помощью аварийного восстановления, то есть аварийного восстановления.
Когда мы создаем систему высокой доступности, первое, о чем нам нужно подумать, — это аварийное восстановление.
Мы должны подготовить какой-то план.
Более того, этот план должен выполняться не только администратором базы данных или системным администратором, в нем должны быть задействованы деловые люди.
Потому что в первую очередь мы должны понимать, сколько транзакций мы можем потерять в результате какой-то катастрофы или как быстро мы должны вернуть нашу систему в работоспособное состояние.
Есть две ключевые вещи.
Это RPO (целевая точка восстановления), т. е.
сколько транзакций мы можем потерять и за какой период. И RTO (целевое время восстановления).
Вот как быстро нам нужно вернуть систему в рабочее состояние.
И посмотрите, как это связано с SLA, SLI, тогда SLA измеряется за длительный период времени, за год. И RTO предназначен для этого конкретного случая.
https://en.wikipedia.org/wiki/File:RPO_RTO_example_converted.png Обычно такой график рисуют для аварийного восстановления.
У нас есть РПО, РТО.
Это картинка из Википедии.
На этом конкретном графике недоступность службы превысила наше RTO (время восстановления).
На самом деле, будет гораздо интереснее, если мы добавим к этому графику еще несколько линий.
Чем больше данных мы теряем, тем больше финансовые потери для бизнеса.
И чем дольше наш сервис недоступен, тем выше потери для бизнеса.
Но с другой стороны, создание резервных копий, гарантирующих абсолютно отсутствие потерь, может оказаться весьма дорогостоящим.
В случае с PostgreSQL мы можем использовать синхронную репликацию (доступна «из коробки»), но стоимость все равно может удивить.
Или, например, если мы хотим осуществить переключение в случае выхода из строя мастера за какое-то минимальное время (секунды), то такая система тоже будет бессмысленно дорогой.
Когда мы выбираем RPO и RTO, это вопрос баланса между этими двумя кривыми.
То есть, сколько вы готовы потратить на нашу систему резервного копирования, сколько мы готовы потратить на поддержку систем автоматического переключения, чтобы их стоимость не превышала потери бизнеса в случае инцидента.
И как все это относится к Postgres? Очевидно, что автоматическое аварийное переключение не поможет нам сделать резервные копии и восстановить данные.
Соответственно, нам нужна какая-то резервная система.
Нам необходимо включить архивирование журналов в Postgres. Мы можем сделать это явно, вызвав некоторую команду архивирования.
Но мы должны выбрать какой-то адекватный тайм-аут. То есть если у нас не большая активность, то Постгрес через какой-то таймаут переключается на следующий WAL. По умолчанию я думаю, что archive_timeout установлен в ноль, то есть он будет ждать этого файла, пока он не заполнится.
И какие-то адекватные значения, например, 5 минут или 30 минут, их нужно выбирать вместе с руководством компании.
Есть еще вариант запустить pg_receivewal на каком-нибудь другом узле.
Это позволяет нам получить поток данных и архив журналов без загрузки мастера.
Это дает некоторые преимущества перед archive_command. Восстановление из резервной копии, если кто-то удалил данные, занимает довольно много времени.
Если мы говорим о базах данных размером в терабайты, то это могут быть часы или десятки часов.
Но, к счастью, у Postgres есть способ обойти эту проблему.
Мы можем запустить реплику, отстающую от мастера на какой-то период времени.
Например, на час, на два, на три.
У нас в Zalando есть одна реплика в дата-центре, которая отстает на час.
Соответственно, если кто-то удалил важные данные, у нас есть час, чтобы достать их из реплики.
RTO также очень важен.
Если, например, вы можете позволить себе RTO более 15 минут, то автоматическое переключение при отказе может даже не понадобиться.
То есть достаточно иметь какую-то систему мониторинга, которая будет уведомлять администратора базы данных.
И он разберётся, что происходит. Например, действительно умер этот мастер или он не отвечает из-за высокой нагрузки.
И если что-то действительно не так, администратор базы данных переключится на реплику.
А синхронная репликация очень важна, если вы не можете позволить себе потерять данные в результате аварийного переключения.
Людям очень часто хочется какого-то автоматического аварийного переключения, которое срабатывает за доли секунды или максимум за секунду.
В принципе, это, наверное, возможно.
Но такое решение будет достаточно дорогим и сложным.
И самое интересное, что сложность такой системы очень часто влияет обратно пропорционально доступности, нашей доступности.
Всегда должен быть какой-то баланс между тем, как быстро мы определяем, недоступен ли наш мастер или, возможно, что-то случилось с сетью.
И, соответственно, мы хотим избежать каких-либо ошибочных переключений.
Высокая доступность и аварийное восстановление не могут существовать отдельно друг от друга.
И очень часто аварийное восстановление включает в себя высокую доступность, т. е.
какое-то решение высокой доступности.
В первую очередь всегда следует думать о RPO и RTO. 
Как правильно сделать автоматическое переключение?
Очень часто ко мне обращаются: «Давайте возьмем мультимастер и проблем не будет. Мы можем писать в любой узел.
И если один из них выйдет из строя, то мы продолжим работу с другим.
Всё хорошо".
Какие решения у нас есть для Postgres? У нас есть PostgreSQL XC/XL. Это достаточно честный мультимастер, но есть одна точка отказа — глобальный менеджер транзакций.
И таким образом мы просто переносим нашу проблему из одной точки в другую.
Нам все равно нужно будет придумать какую-то высокую доступность для глобального менеджера транзакций.
BDR основан на логической репликации.
И есть какой-то способ разрешения конфликтов.
Если подумать о разрешении конфликтов, то на самом деле это оказывается эвентуальная последовательность.
Если одни и те же данные перезаписываются на разных узлах, мы не можем гарантировать какой-либо конкретный порядок.
Он будет работать только в соответствии с настройками.
Например, победит тот, кто немного опередил по времени.
Или по какому-то другому идентификатору.
К сожалению, конечная последовательность не всегда является чем-то приемлемым.
Но у этого решения есть огромное преимущество.
Он будет работать в географически распределенных системах.
То есть у вас может быть один сервер в Европе, другой в Америке, третий где-то в Азии, четвёртый в Австралии.
Также есть решение от PostgreSQL. Это более-менее честный мультимастер.
Каковы недостатки? Он за деньги - вот и все.
Во-вторых, он предназначен для работы в одной сети.
То есть задержка между узлами должна быть достаточно небольшой.
Но в принципе, судя по описанию, это честный мультимастер.
Если вы можете себе это позволить, то, вероятно, имеет смысл протестировать его и, возможно, купить.
Что такое хорошее решение высокой доступности? Во-первых, должен быть кворум.
Кворум очень важен.
Это позволяет нам отличать проблемы сбоя сервера от проблем с сетью.
То есть, если Google не работает, то вы обращаетесь к соседу и спрашиваете: «У тебя тоже Google не работаетЭ» Он говорит: «Да, это не работает».
Что это значит? Либо что-то не так с Google, что маловероятно, либо вы попадаете в сеть, отрезанную от Интернета.
И кворум несет ответственность за разрешение таких ситуаций.
Второе, что необходимо – это ограждение.
Если мы хотим переключить какую-то реплику в новом мастере, то мы должны убедиться, что старый мастер абсолютно недоступен.
И, как правило, люди все равно хотят сделать для старого мастера STONITH (Shoot The Other Node In The Head), то есть выполнить какой-то скрипт, который его добьет, если он жив и движется.
Есть несколько способов сделать это.
Можно подключиться к какому-нибудь свитчу и отключить этот порт. Вы действительно можете отключить электричество от этого конкретного узла.
Можем придумать что-нибудь еще.
И третий важный компонент систем высокой доступности — это сторожевой таймер.
Если наша система высокой доступности, которая присматривает за Postgres, внезапно дала сбой, что тоже может случиться, ведь любое программное обеспечение имеет ошибки, то этот узел не должен продолжать работать как мастер.
Есть, например, такая замечательная штука, как Linux watchdog. А если он не будет получать пинги, то через определенный промежуток времени он просто перезагрузит узел, тем самым не дав ему продолжать работать мастером и гарантируя отсутствие расщепления мозга.
Почему важны кворум, фехтование и контроль? Есть примеры.
Я уже приводил такие примеры на презентациях.
Но я нашел одну реальную реализацию, которая доступна на GitHub. 
https://github.com/MasahikoSawada/pg_keeper Что обычно делают люди? Мы хотим, чтобы все было просто, поэтому напишем простой скрипт, запустим его на подчиненном устройстве, и он отправит пинг главному устройству.
Если мастер недоступен, то будем продвигать слейва.
Что происходит на самом деле? У нас разделение сети, т.е.
один узел не видит другой.
Давайте сделаем раба господином.
И получаем двух мастеров - расщепленных мозгов.
Как я уже сказал, есть пример.
Эта утилита создана Масахико Савадой.
Пожалуйста, не используйте.
Как мы можем добиться большего? Давайте запустим какую-нибудь третью ноду, которая будет следить и за основной, и за резервной и принимать решения, что делать.
Очевидная проблема заключается в том, что такой узел является единственной точкой отказа.
Если она умрет, у нас не будет высокой доступности.
Но это не так уж и страшно, ведь и мастер, и реплика продолжают работать как ни в чем не бывало.
Другая проблема в том, что может произойти какое-то разделение сети, узел будет видеть только режим ожидания.
Мастер ей будет недоступен.
И мы будем способствовать режиму ожидания.
То есть фехтование в такой ситуации должно быть обязательным.
Но, к сожалению, иногда, чтобы правильно это реализовать, нужно подумать о каком-то втором сетевом канале, что не всегда возможно.
Правильным решением было бы использовать какую-то систему, основанную на кворуме.
Кворум гарантирует нам, что если мы можем записывать данные в нашу систему, например, Etcd, то мы находимся в той части сети, которую видят все остальные.
И только если это произойдет, мы сможем работать как мастера.
Патрони работает по этому принципу.
Патрони периодически пингует Etcd, что он лидер (мастер), что он все еще здесь и доступен.
Если такие пинги не придут, то ключ лидера пропадет из Etcd, standby узнает, что лидера у нас нет и начнет выборы.
Я расскажу три интересные истории.
https://gocardless.com/blog/incident-review-api-and-dashboard-outage-on-10th-october/ Во-первых, существует организация, которая занимается банковскими платежами и банковскими переводами.
Это называется GoCardless. Они построили свою систему высокой доступности на базе Corosync + Pacemaker. В принципе все хорошо, все правильно.
Кардиостимулятор обеспечивает кворум.
Он может переключать виртуальные IP, чтобы подключиться к мастеру, умеет корректно работать со сторожевым таймером.
Казалось, все было хорошо.
Но что произошло на практике? RAID-контроллер на ведущем устройстве вышел из строя.
Начал выдавать ошибки, но продолжал работать.
Что решили сделать инженеры? Подумали, давайте перезагрузим (выключим) мастер, и Pacemaker должен сработать, то есть переключить мастер на узел, который синхронен.
К сожалению, пока проверялось состояние этого синхронного узла, произошел сбой одного из процессов postgres. И в результате началось аварийное восстановление, подключиться туда было невозможно, и автоматического аварийного переключения не произошло.
Ребята полтора часа пытались прорекламировать себя с помощью Pacemaker. В конце концов они просто отключили Кардиостимулятор и переключили его вручную.
Общая продолжительность происшествия составила почти два часа.
Какие выводы из этого? Чему мы должны отсюда научиться? Любые системы, особенно те, которые занимаются высокой доступностью, очень сложны.
В некотором смысле они подобны автопилоту.
Автопилот может управлять гигантским авиалайнером.
Например, Airbus A380. Но автопилот тоже может сломаться.
Он может получить какие-то неверные данные и принять неверные решения.
Вы должны знать, как работает репликация postgres, как создавать реплики, как переключаться.
Вы должны уметь летать с обычным штурвалом.
А если вы начнете использовать какую-то новую систему, то поместите ее в тестовую среду, попытайтесь ее сломать.
Попробуйте сломать разные компоненты и посмотрите, что произойдет, чтобы быть готовыми.
Упражняться.
https://github.blog/2018-10-30-oct21-post-incident-analysis/ Еще один инцидент. Это произошло не так давно.
Так и произошло с GitHub, который Postgres не использует, но отсюда тоже можно узнать интересные вещи.
У GitHub есть два центра обработки данных.
Один находится на востоке Северной Америки, другой — на западе Северной Америки.
Мастер находится на востоке.
Реплики расположены в восточной и западной частях.
Но проблема в том, что приложения, работающие с этой базой данных, асимметричны.
Например, Джобс и GitHub.com работают только в восточном округе Колумбия.
Задержка между двумя дата-центрами составляет 60 миллисекунд. 
Что случилось? Планировались технические работы на сети.
И в результате сеть пропала на несколько секунд. Система автоматического переключения решила, что восточный ДЦ недоступен и переключилась на западный.
Но приложения Джобса и GitHub.com начали работать с мастером, который теперь находился на западе, добавив 60 миллисекунд к общему времени отклика.
Это было неприемлемо долго.
Все начало замедляться.
К сожалению, быстрое переключение обратно было невозможно, поскольку часть данных с востока на запад не реплицировалась (буквально несколько секунд нереплицированных данных).
Единственное, что можно было сделать, это пересобрать все реплики на востоке и переключить вручную.
В общей сложности на восстановление сервиса ушли сутки.
Это очень долго.
Чему мы можем научиться отсюда? Аварийное переключение между географически распределенными регионами не всегда может быть желательным.
Если вы рассчитываете на такое аварийное переключение, то подумайте о том, чтобы все ресурсы были как минимум симметричны.
И второй важный вывод. Pg_rewind очень важен.
А в MySQL, к сожалению, такой технологии нет. С Postgres мы могли просто откатить эти несколько секунд назад и быстро переключиться с запада на восток, не перестраивая реплики.
https://about.gitlab.com/blog/2017/02/10/postmortem-of-database-outage-of-january-31/ И последний пример, который тоже очень интересен.
Это произошло чуть больше двух лет назад с GitLab. У них не было системы автоматического переключения.
Обычная система мастера и реплики.
В какой-то момент на мастере произошло гигантское обновление, и реплика стала отставать.
Они не использовали слоты репликации.
В результате сегменты WAL на мастере, необходимые для реплики, были удалены.
Дежурный инженер начал восстанавливать реплику с помощью pg_basebackup. Запускает pg_basebackup, ничего не происходит. Нажимает Ctrl+C, очищает PGDATA, запускает заново - ничего не происходит. В чем проблема? По умолчанию pg_basebackup выполняет распространение контрольной точки, т. е.
ожидает появления контрольной точки.
А если в настройках не включен режим verbose, то мы не видим, что делает pg_basebackup. После нескольких попыток инженер случайно удаляет каталог данных на мастере.
Что делать в такой ситуации? Они, конечно, умные ребята, у них есть резервные копии.
Существует три типа резервных копий.
К сожалению, Pg_dump настроен на запуск один раз в день ночью.
И, к сожалению, не сработало, потому что запускалось с другого сервера.
Была использована какая-то хитрая система, которая подключалась к локально работающему Postgres и пыталась понять, какая у нас версия нашего сервера, и определить, какую версию pg_dump следует использовать.
Если Postgres не работал на резервном сервере, то использовалась самая младшая версия pg_dump. Возник конфликт интересов.
Реальный сервер работал на 9.5, pg_dump использовался на 9.2 и отказывался работать с 9.5. То есть дампы пустые, и за ошибками никто не следил.
Второй тип резервных копий — это снимки дисков Microsoft Azure. Для серверов баз данных они были отключены, потому что кто-то их протестировал и понял, что скорость восстановления из снимков очень медленная и смысла в их использовании нет. Третий тип резервного копирования — снимки LVM — также выполнялся один раз в день.
К счастью, снимки периодически проверялись на предмет постановки.
И только в результате того, что их периодически разворачивали — это был единственный работающий тип резервного копирования.
Но не забывайте, что резервные копии делались только один раз в день.
И здесь им повезло.
Один из инженеров сделал еще один снимок за 6 часов до инцидента.
То есть инцидент произошел ближе к полуночи, когда обычно происходит резервное копирование.
В общей сложности они могли потерять почти 24 часа данных.
Но, к счастью, снимок шестичасовой давности в некотором смысле спас их.
Чему мы должны отсюда научиться? RPO и RTO очень важны, и их следует выбирать с учетом особенностей вашего бизнеса.
Очевидно, что снапшоты или какие-то резервные копии, сделанные раз в сутки, дают RPO 24 часа, а это недопустимо.
Репликация не является резервной копией и не поможет восстановить данные.
Мы потеряли очередь и всё, до свидания.
Еще одна очень важная вещь, которую я хотел бы отменить.
Инженер использовал Runbook. У них было задокументировано, что делать в той или иной ситуации.
Реплика отсутствует — используйте pg_basebackup для ее повторной инициализации.
Но, к сожалению, периодического обучения они не проводили.
Если бы инженер запускал pg_basebackup вручную хотя бы раз в полгода и смотрел, как она себя ведет, он бы знал об этой особенности.
Но, очевидно, этого не произошло.
Вам следует периодически запускать наш аварийный скрипт. И мы должны следить за тем, чтобы резервные копии удалялись.
И мы обязательно должны попытаться их расширить.
И нужно следить за тем, чтобы они разворачивались и были в норме.
Теги: #Системное администрирование #Администрирование баз данных #postgresql #patroni #высокая доступность
-
Архитектура Памяти: Erlang Против Java
19 Oct, 24 -
Такой Железный И Такой Безымянный
19 Oct, 24 -
Бачинский И Одноклассники
19 Oct, 24 -
Ошибка Имени Пользователя
19 Oct, 24
