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

Sdílet
Vložit
  • čas přidán 4. 12. 2019
  • Приглашаем на конференцию Saint HighLoad++ 2024, которая пройдет 24 и 25 июня в Санкт-Петербурге!
    Программа, подробности и билеты по ссылке: vk.cc/cuyIqx
    --------
    --------
    HighLoad++ Siberia 2019
    Тезисы и презентация:
    www.highload.ru/siberia/2019/...
    Я расскажу, как мы комплексно подошли к проблеме отказоустойчивости PostgreSQL, какие варианты мы рассматривали и как остановились на Patroni.
    Доклад содержит этапы тестирования этого решения и примеры, как мы обеспечили быстрое внедрение на production.
    --------
    Нашли ошибку в видео? Пишите нам на support@ontico.ru

Komentáře • 25

  • @-dubok-
    @-dubok- Před 9 měsíci +2

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

  • @mshilov
    @mshilov Před 3 lety +7

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

  • @Petyaumniy
    @Petyaumniy Před 10 měsíci +1

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

  • @GlebWritesCode
    @GlebWritesCode Před 4 lety

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

  • @user-xn5tj9ko2u
    @user-xn5tj9ko2u Před 7 měsíci

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

  • @GlebWritesCode
    @GlebWritesCode Před 4 lety +1

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

  • @user-xn5tj9ko2u
    @user-xn5tj9ko2u Před 3 lety +1

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

    • @moscow8881
      @moscow8881 Před rokem +1

      я полагаю они перед удалением должны были остановить postgres ))

  • @notkeo
    @notkeo Před 4 lety

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

    • @namefn3492
      @namefn3492 Před 4 lety +2

      CockroachDB (NOSQL) энтерпрайс тоже денег просит за сапппорт и фитчи. И сколько денег тайна. У вас есть информация про то, сколько стоит решение уровня энтерпрайс? (название выбрали еще то таракан). Реактивные драйвера под CockroachDB? В чем ее преимущества реальные (не на картинках) перед MongoDB? И интересно сколько стоит найти спеца по CockroachDB на саппорт и много ли таких спецов в РФ. Раньше все пищали про то, что постгре нет спецов (в отличие от оракла), теперь тоже самое говорят про NoSQL. Вы попробуйте такое решение в энтерпрайзе защитить и обосновать. Тут PostgreSQL который обвешан сертификатами ФСТЭК смотрится выгоднее на фоне конкурентов. Я к поклноникам PostgreSQL себя не отношу, но такова реальность

    • @GlebWritesCode
      @GlebWritesCode Před 3 lety

      @@namefn3492 порядка 80$ в месяц стоит 1 нода в cockroach cloud (GCP us-west2, 2 vCPU, 60GB). не очень понял почему они nosql - уже года 3 как реляционная база

  • @user-id2pi9ww2w
    @user-id2pi9ww2w Před 4 lety +2

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

    • @user-xn5tj9ko2u
      @user-xn5tj9ko2u Před 3 lety +1

      Postgres Pro?) Да ладно) с учетом того, что описанные "костыли"(то есть приклад не из коробки в данном случае) все равно будут использоваться... и насколько лучше про чем свободный постгрес - еще вопрос...

    • @user-id2pi9ww2w
      @user-id2pi9ww2w Před 3 lety +1

      @@user-xn5tj9ko2u , думаете они взяли открытый постгресс и немного добавили фич, которые невсегда стабильно работают как описано в доке, затем поменяв наклейку с постгресс на постгресс про и зарегистрировали как российское ПО?)
      На самом деле такое сплошь и рядом-берут опен соурс+добавляют чего-то небольшое=российский софт, а потом идут и говорят, что он может заменить западные аналоги. Хотя сами же слизали с западного ПО)

    • @user-xn5tj9ko2u
      @user-xn5tj9ko2u Před 3 lety +1

      @@user-id2pi9ww2w вы, конечно, правы, и так происходит часто, но я не считаю это главной проблемой слона. В данном случае слон из коробки - ограниченное ПО, и для указанных решений в любом случае требует других применения других программных продуктов, в отличии от mssql и oracle

    • @user-id2pi9ww2w
      @user-id2pi9ww2w Před 3 lety

      @@user-xn5tj9ko2u , соглашусь.
      Приходится много чего допиливать или брать стороннее

  • @SimargL_IncognitO
    @SimargL_IncognitO Před 4 lety +9

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

    • @SimargL_IncognitO
      @SimargL_IncognitO Před 3 lety

      @@alex-0x6b Ну, подумайте сами.

    • @SimargL_IncognitO
      @SimargL_IncognitO Před 3 lety

      @@alex-0x6b Ну, считайте, коль нравится и так думкаете.

    • @cno1ick
      @cno1ick Před 2 lety +4

      @@SimargL_IncognitO Токсик

  • @SimargL_IncognitO
    @SimargL_IncognitO Před 4 lety +5

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

    • @namefn3492
      @namefn3492 Před 4 lety

      полтора года переезд внушает, "перенесли небольшую часть данных" и будем еще полтора года переезжать. мне нравится честность докладчика. инстансы редиса стали неожиданно давать лайтанси большую. была nosql bd (+in memory) и вдруг поехали на SQL БД с требованием низкое лэйтанси (странное решение). Пока не понимаю почему туже монгу не выбрали, тем более живут в клауде. Потсгре вообще большое число коннектов сам по себе без сторонних решений выдерживать не может по дефолту, что уже на мысли толкать должно. Шардирование на уровне логики приложения, то есть в коде (без комментариев).

    • @user-xn5tj9ko2u
      @user-xn5tj9ko2u Před 3 lety

      На доработках больше работы и денег можно заработать больше, чем на perpetum mobile "под ключ"

    • @vladislavstepanov7591
      @vladislavstepanov7591 Před 9 měsíci

      @@namefn3492 про монго смешно. С каких пор монга начала быстро работать на чтение?)

  • @BatShvit
    @BatShvit Před rokem

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