Кейс для тренировки мозга, пока вы окончательно не отупели с ИИ.
У вас есть три датацентра, между которыми распределён кластер PostgreSQL. В двух реплики, в третьем -- мастер. В JDBC URL перечислены все три адреса и стоит targetServerType=primary о котором я писал раньше: то есть драйвер всегда должен самостоятельно найти мастер.
Теперь вы теряете один ДЦ (или вы теряете мастер и одна из реплик перебалансировалась и становится мастером). Мастер у вас есть, и он доступен. Казалось бы, стандартный железобетонный механизм, какие могут возникнуть проблемы?
Подвох -- в переборе адресов и поиске мастера. В pgJDBC (и вероятно у других драйверов) connectTimeout не обновляется при переходе к следующему хосту.
И в итоге, если у вас вот такого рода подключение, pg-C оказался мастером, а pg-B недоступен то драйвер просто не дойдет до primary и не сможет подключиться к базе:
jdbc:postgresql://pg-A,pg-B,pg-C?targetServerType=primary&connectTimeout=10
> ДЦ A, реплика. Подключились, проверили роль. Потратили 50 мс. Идём дальше.
> ДЦ B, недоступен. Ждём подключения 9950 мс.
> ДЦ C, живой мастер. На TCP-подключение остаётся… (!) 1 мс. Буквально минимум, заданный в коде при исчерпании бюджета:
remaining <= 0 ? 1 : (int) Math.min(remaining, Integer.MAX_VALUE);
Драйвер до мастера доходит, он даже живой, но даёт ему настолько мало времени, что соединение может не установиться даже с исправным сервером. Получается, недоступная реплика перед мастером в списке адресов может сорвать подключение к живому мастеру.
И, если это накладывается у вас на массовую потерю PODов и рестарты вашего бэкенда, то некоторые PODы имеют шанс не стартовать из-за проб.
В очередной раз удивляюсь, какие неожиданные вещи могут происходить иногда в очень и очень обыденной функциональности. Морали у этой истории как и всегда не будет никакой. Оставляю на откуп читателя.