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

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

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

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

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

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

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

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

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

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

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

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

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