Отказоустойчивый кластер PostgreSQL + Patroni. Реальный опыт внедрения / Виктор Еремченко (Miro)

Приглашаем на конференцию HighLoad++ 2024, которая пройдет 2 и 3 декабря в Москве!
--------
HighLoad++ Siberia 2019

Тезисы и презентация:

Я расскажу, как мы комплексно подошли к проблеме отказоустойчивости PostgreSQL, какие варианты мы рассматривали и как остановились на Patroni.

Доклад содержит этапы тестирования этого решения и примеры, как мы обеспечили быстрое внедрение на production.

[-dubok-]

Отличный и очень понятный и грамотный доклад! Всё по полочкам. Почерпнул для себя полезные идеи, например, что касается тестовой среды, аналогичной продакшену, спасибо!

[mshilov]

раз у ж вы в Амазоне, почему бы не пользоваться ElasticCache для redis и RDS/Aurora для Postgres? Да, оно стоит чуть дороже чем ваши EC2. Но вы на эти переезды, даунтаймы, репликации итд. Потратили больше денег и времени.

[Petyaumniy]

Теперь я понял, вот почему оно так тормозит.

[Алексей-мцй]

Rm -rf можно было заменить на переименование директории (mv)?!
Не так опасно ведь?!)

[GlebWritesCode]

Не понял с redis - почему нельзя развернуть кластер? Да и без него можно переехать на машину побольше без downtime

[GlebWritesCode]

Ну и решать требование низкой latency заменой in-memory базы на дисковую - странно, вы вообще проводили тесты?

[Алексей-мцй]

Удалить дирректорию, чтобы зафиксировать мастер? А вырубить сервис или сервер нельзя?

[notkeo]

Ого, шардирование на уровне кода, connection manager, отсутствие транзакций между шардами, асинхронная репликация (диски в AWS тоже могут биться, ага, посмотрим как асинхронно восстановитесь), сторонний failover через Consul + patroni. Просто тонна денег и сил влито. Есть куда более адекватные замены PostgreSQL, которые делают все это из коробки. Посмотрите в сторону CockroachDB, сэкономите кучу денег и сил.

[SimargL_IncognitO]

Со слов "мы полностью расположены в Amazon-е" можно закрывать...

[КоддШредингерр]

Мы жили на одной хрени, переезжаем в другую. Но по факту так и не поняли какая нам СУБД лучше подойдет в том числе и в плане долгосрочных перспектив, а не на пару лет вперед. Тут либо вечно кочевать из одной бесплатной субд в другую, либо сделать решение долговечным и стабильным, купив стабильное, платное и зарекомендовавшее временем решение (Oracle, MS SQL Server, Postgres Pro). Ну или заниматься переездами вечными и вечно кормить тех, кто будет это делать. Или стать частью команды над Open Source-решением и его использовать, но также развивая и это решение. Просто пользоваться Open Source решением без его непосредственного развития-также опасно.
Также в традиционном смысле транзакции нерационально использовать в высоко нагруженных системах. Транзакции особенно распределенные реализуются на всех слоях информационной системы, а не только транзакциями СУБД.

[SimargL_IncognitO]

"Мы переезжаем, будем ещё долго переезжать..."
А чем вы "умники" думали, когда код исходный писали?!

[BatShvit]

Кластер где есть мастер не может быть отказоустойчивым, потому что перевыбор мастера занимает время.