Приложение должно работать в транзакционном режиме, должна быть синхронная или реплика с минимальным отставанием. Если эти условия выполняются - то ошибки будут только по тем запросам, которые были к упавшей реплике или мастеру.
Остальные же коннекты, которые были в idle состоянии ничего не почувствуют.
На самом деле не всё радужно - у того же stackgres pgbouncer является частью пода с postgres.Ну и про приложения, которые требуют сессии забывать не надо.
По факту ZereDowntime для transaction-mode ready приложений даст Zalando, Stolon, Crunchydata. Причём у Stolon свой прокси, который еще и нагрузку балансировать умеет. Stackgres не даст такого из коробки. А KubeDB я уже не помню где pgbounser держит.
Всё упирается в деньги. Если проект может себе позволить для всего managed решения - то это отлично. Однако такие решения 1.5-2 раза дороже того же объема ресурсов, если вы просто vm возьмете. А если проект вообще не в облаке, а получить схожие функции охота? Тогда и ставят подобные решения - ceph, Longhorn и т. д. Чтобы получить слой хранения, с которым можно было бы работать как с облаком. Куче приложений он требуется - начиная от dev- стендов и заканчивая вполне себе production redis.
В итоге не ясно - довольны компании или нет. Однако удивляться не стоит - если 20 лет ничего не делать, то на пустом месте ничего за пару лет не вырастет. А Байкалу удачи.
Коллеги достаточно чётко отвечают на этот вопрос - стоимость трафика и дисков с высоким IOPS была слишком высока. От этого проект никак не смог бы деться без переезда.
По поводу спотовых инстансов - да, могут жить месяцами, а потом резко закончится. В нашей практике были случаи когда у нас была Autoscaling group на спотах с 3 типами инстансов. И в один прекрасный день все типы стали резко недоступны на несколько часов.
Так в начале статьи же сказано, что такое городилось под линейку chipcore. Это самые бюджетные "сервера", на десктопном железе. Для тех, кто хочет петпроект разместить дешево, но в нормальном цоде, чтобы сетка и питание были бы неплохими.
Если вас не устраивают существующие решения, которые позволяют сделать то, что вы хотите - никто не мешает реализовать свое.
Ваш скептицизм по поводу repmgr или операторов крайне странный. Так как требуется либо создать ресурс из 20 строк либо конфигурационный файл в 5 строк и разложить ключи, как в случае repmgr.
Логическая репликация даёт консистентные таблицы, единственная проблема в том, что она не переносит значения последовательностей и их придётся восстановить в момент переключения. В итоге при схеме с логической репликацией мы получаем много подготовительной работы и мараторий на schema change, но переключение за 8 секунд.
Вариант с pg_upgrade потребует от администратора базы меньше времени на подготовку, однако придётся обновлять все индексы(при обновлении до 12 или 13 версии) и пересобирать toast таблицы(в случае обновления до 14) . На работающем проде это может быть больнее, нежели настройка логической реплики.
К сожалению в текущих реалиях (с 11 на 13 или 14 postgres) это равносильно запуску еще одного кластера патрони. Алгоритм прост - делаем 2ой кластер, подымаем логическую репликацию, переключаемся на новый кластер после синхронизации.
Ну тут-то как раз загадки нет. Дешевле поддерживать один универсальный сервис, который объединял бы в себе сразу 3 других: Git storage, CI/CD и Registry. Кроме того Флант имеет богатый опыт поддержки Gitlab, который не ограничивается только CI/CD, но и покрывает другие аспекты: бэкап, обновление и мониторинг.
В истории #4 стоило просто указать recovery_target_time или аналогичные по принципу работы директивы
Хочу попросить прощения у автора - статью прочитал и пропустил ссылку на github. В итоге минуснул статью.
Так как нет возможности переголосовать - плюсанул карму напрямую. Впредь буду внимательнее.
По самой статье - хороший чарт. А вы не рассматривали вариант создания библиотечного чарта?
Везде есть оговорки.
Приложение должно работать в транзакционном режиме, должна быть синхронная или реплика с минимальным отставанием. Если эти условия выполняются - то ошибки будут только по тем запросам, которые были к упавшей реплике или мастеру.
Остальные же коннекты, которые были в idle состоянии ничего не почувствуют.
На самом деле не всё радужно - у того же stackgres pgbouncer является частью пода с postgres.Ну и про приложения, которые требуют сессии забывать не надо.
По факту ZereDowntime для transaction-mode ready приложений даст Zalando, Stolon, Crunchydata. Причём у Stolon свой прокси, который еще и нагрузку балансировать умеет. Stackgres не даст такого из коробки. А KubeDB я уже не помню где pgbounser держит.
Будем посмотреть, как говорится.
Производительнее - да, но что по энергоэффективности? Поди знатные калориферы будут.
Всё упирается в деньги. Если проект может себе позволить для всего managed решения - то это отлично. Однако такие решения 1.5-2 раза дороже того же объема ресурсов, если вы просто vm возьмете. А если проект вообще не в облаке, а получить схожие функции охота? Тогда и ставят подобные решения - ceph, Longhorn и т. д. Чтобы получить слой хранения, с которым можно было бы работать как с облаком. Куче приложений он требуется - начиная от dev- стендов и заканчивая вполне себе production redis.
Блочное хранилище. Для dev postgres, например, очень удобно иметь плавающий диск, как ebs в AWS.
Да, всё так. Но хочется всё-таки верить в светлое будущее.
В итоге не ясно - довольны компании или нет. Однако удивляться не стоит - если 20 лет ничего не делать, то на пустом месте ничего за пару лет не вырастет. А Байкалу удачи.
Конфиги присутствуют, но где же код? Хочется получить код приложений и попробовать воспроизвести тестирование.
Коллеги достаточно чётко отвечают на этот вопрос - стоимость трафика и дисков с высоким IOPS была слишком высока. От этого проект никак не смог бы деться без переезда.
По поводу спотовых инстансов - да, могут жить месяцами, а потом резко закончится. В нашей практике были случаи когда у нас была Autoscaling group на спотах с 3 типами инстансов. И в один прекрасный день все типы стали резко недоступны на несколько часов.
Так в начале статьи же сказано, что такое городилось под линейку chipcore. Это самые бюджетные "сервера", на десктопном железе. Для тех, кто хочет петпроект разместить дешево, но в нормальном цоде, чтобы сетка и питание были бы неплохими.
Вот, на здоровье
Я в принципе могу расписать, если интересует, как упростить конфигурации, чтобы было легче.
Если вас не устраивают существующие решения, которые позволяют сделать то, что вы хотите - никто не мешает реализовать свое.
Ваш скептицизм по поводу repmgr или операторов крайне странный. Так как требуется либо создать ресурс из 20 строк либо конфигурационный файл в 5 строк и разложить ключи, как в случае repmgr.
Вам стоит посмотреть либо в сторону операторов postgres в kubernetes. Либо в сторону repmgr
Логическая репликация даёт консистентные таблицы, единственная проблема в том, что она не переносит значения последовательностей и их придётся восстановить в момент переключения. В итоге при схеме с логической репликацией мы получаем много подготовительной работы и мараторий на schema change, но переключение за 8 секунд.
Вариант с pg_upgrade потребует от администратора базы меньше времени на подготовку, однако придётся обновлять все индексы(при обновлении до 12 или 13 версии) и пересобирать toast таблицы(в случае обновления до 14) . На работающем проде это может быть больнее, нежели настройка логической реплики.
К сожалению в текущих реалиях (с 11 на 13 или 14 postgres) это равносильно запуску еще одного кластера патрони. Алгоритм прост - делаем 2ой кластер, подымаем логическую репликацию, переключаемся на новый кластер после синхронизации.
Ну тут-то как раз загадки нет. Дешевле поддерживать один универсальный сервис, который объединял бы в себе сразу 3 других: Git storage, CI/CD и Registry. Кроме того Флант имеет богатый опыт поддержки Gitlab, который не ограничивается только CI/CD, но и покрывает другие аспекты: бэкап, обновление и мониторинг.