<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
<channel>
    <title>Knowledgebase RSS (Комментарии для: Краткая инструкция по развертыванию кластера из центра сертификации, с дальнейшим формированием кластера из центра валидации)</title>
    <description></description>
    <link>https://kbp.aladdin-rd.ru//index.php?View=comment&amp;EntryID=506</link>
    
    
    
    <item>
        <title>nariman_05@mail.ru</title>
        <link>https://kbp.aladdin-rd.ru//index.php?View=comment&amp;EntryID=506#c40</link>
        <description>А нельзя ли сделать в связка haproxy + patroni + etcd? Это то, что касается баз, а приложение будет доступно на третьем сервере с балансировщиком?</description>
		<pubDate>Tue, 17 Jun 2025 08:55:17 +0300</pubDate>
		<category>Комментарий</category>
		<content:encoded><![CDATA[А нельзя ли сделать в связка haproxy + patroni + etcd? Это то, что касается баз, а приложение будет доступно на третьем сервере с балансировщиком?]]></content:encoded>
    </item>
    
    <item>
        <title>admin</title>
        <link>https://kbp.aladdin-rd.ru//index.php?View=comment&amp;EntryID=506#c41</link>
        <description>Данный вариант реализации тоже возможен наравне с другими вариантами. Мы, как вендор, к сожалению не можем проверить все возможные варианты реализации отказоустойчивого кластера на базе postgres, так как их может быть очень много.
Вариант который вы описали: 
patroni отвечает за выбор мастера;
etcd хранит состояние patroni;
pgbouncer управляет сессиями;

нами не проверялся, и поэтому не заявлен как официально поддерживаемый. 

Опять же, это не говорит о том, что вы не можете использовать те схемы отказоустойчивости, которые вам привычны и которые у вас уже реализованы.  Тем более что сценарий, который вы предлагаете, широко описан в сети, и в целом подробно документирован.</description>
		<pubDate>Wed, 18 Jun 2025 17:18:47 +0300</pubDate>
		<category>Комментарий</category>
		<content:encoded><![CDATA[Данный вариант реализации тоже возможен наравне с другими вариантами. Мы, как вендор, к сожалению не можем проверить все возможные варианты реализации отказоустойчивого кластера на базе postgres, так как их может быть очень много.<br />
Вариант который вы описали: <br />
patroni отвечает за выбор мастера;<br />
etcd хранит состояние patroni;<br />
pgbouncer управляет сессиями;<br />
<br />
нами не проверялся, и поэтому не заявлен как официально поддерживаемый. <br />
<br />
Опять же, это не говорит о том, что вы не можете использовать те схемы отказоустойчивости, которые вам привычны и которые у вас уже реализованы.  Тем более что сценарий, который вы предлагаете, широко описан в сети, и в целом подробно документирован.]]></content:encoded>
    </item>
    
    
</channel>
</rss>