Доброго времени суток. Cпасибо за качественную контент, у меня есть несколько вопросов по этой теме 1) как быть если приложения для чтения используются слейвы (синхронно) и количество слейвов несколько (3-4); 2) приложения не умеет равномерно сбалансировать селект запрос по slave (для этого я пользуюсь haproxy, это не претензия а хотел узнат естли другая боле простой или решения мене накладных расходов); 3) кроме slave серверов есть другие slave ы (асинхронная каскадная реплика) для бэкапа и отстающая реплика для экстренного востонавления если случился какой то удаления а слейвы уже все проиграли а бэкап недостаточно близко короче потеря данных при восстановлении из бэкапа нас не устраивает. 4) при добавлении slave в кластер patroni он от мастера скопируйте все данные но если у тебя большая БД то это долго и при ЧНН это очень заметно тормозит мастер и как я прочитал про patroni умеет востанавит из бэкапа (wal-g или pg_probackup) а потм догнать мастер с делту то что не хватает. Побывали ли ты этот? Заранее спасибо!
1) Здесь не совсем вас понял, если речь идет о 3-4 синхронных репликах, то такой вариант не очень рекомендуется. Так как при этом сильно просядет tps. Но коенчно все зависит от задач. 2) Я же не говорю что не нужно использовать вообще haproxy. Любой инструмент хорош, если он вам подходит. Можно попробовать использовать IPVS, там есть различные стратегии хэширования. Но у меня такой практики нет. Тут поле для экспериментов, можно iptables с модулем вероятности. Но это все теории. Надо проверять. Еще могу добавить что haproxy лучше собрать из последних стабильных сборок с ключами оптимизации типа native. На ubuntu 18.04 это увеличило TPS в 2.5 раза по сравнению с haproxy из репозитория. 3) Мы используем wal-архивацию. Отстающая реплика не очень хорошее решение в плане защиты от дурака. Если кто то что то дропнул и это уже долетело до отстающей реплики, у вас проблемы. PITR позволяет откатится практически не любое время. 4) Не совсем тут понял. Классика - патрони делает pg_basebackup, а затем догоняет по wal-ам. Но метод создания реплики можно задать в конфигурации. Восстановление из фулбэкапа с последующим накатыванием wal-ов это PITR и тут как бы патрони не причем.
просто огонь! Весь плейлист просмотрел без остановки. Спасибо огромное за труд! Жму руку!
Доброго времени суток.
Cпасибо за качественную контент,
у меня есть несколько вопросов по этой теме
1) как быть если приложения для чтения используются слейвы (синхронно) и количество слейвов несколько (3-4);
2) приложения не умеет равномерно сбалансировать селект запрос по slave (для этого я пользуюсь haproxy, это не претензия а хотел узнат естли другая боле простой или решения мене накладных расходов);
3) кроме slave серверов есть другие slave ы (асинхронная каскадная реплика) для бэкапа и отстающая реплика для экстренного востонавления если случился какой то удаления а слейвы уже все проиграли а бэкап недостаточно близко короче потеря данных при восстановлении из бэкапа нас не устраивает.
4) при добавлении slave в кластер patroni он от мастера скопируйте все данные но если у тебя большая БД то это долго и при ЧНН это очень заметно тормозит мастер и как я прочитал про patroni умеет востанавит из бэкапа (wal-g или pg_probackup) а потм догнать мастер с делту то что не хватает. Побывали ли ты этот?
Заранее спасибо!
1) Здесь не совсем вас понял, если речь идет о 3-4 синхронных репликах, то такой вариант не очень рекомендуется. Так как при этом сильно просядет tps. Но коенчно все зависит от задач.
2) Я же не говорю что не нужно использовать вообще haproxy. Любой инструмент хорош, если он вам подходит. Можно попробовать использовать IPVS, там есть различные стратегии хэширования. Но у меня такой практики нет. Тут поле для экспериментов, можно iptables с модулем вероятности. Но это все теории. Надо проверять. Еще могу добавить что haproxy лучше собрать из последних стабильных сборок с ключами оптимизации типа native. На ubuntu 18.04 это увеличило TPS в 2.5 раза по сравнению с haproxy из репозитория.
3) Мы используем wal-архивацию. Отстающая реплика не очень хорошее решение в плане защиты от дурака. Если кто то что то дропнул и это уже долетело до отстающей реплики, у вас проблемы. PITR позволяет откатится практически не любое время.
4) Не совсем тут понял. Классика - патрони делает pg_basebackup, а затем догоняет по wal-ам. Но метод создания реплики можно задать в конфигурации. Восстановление из фулбэкапа с последующим накатыванием wal-ов это PITR и тут как бы патрони не причем.