Кулешов разгоняет IT | AI

Кейс для тренировки мозга, пока вы окончательно не отупели с ИИ. У вас есть три датацентра, между которыми распределён кластер 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ы имеют шанс не стартовать из-за проб. В очередной раз удивляюсь, какие неожиданные вещи могут происходить иногда в очень и очень обыденной функциональности. Морали у этой истории как и всегда не будет никакой. Оставляю на откуп читателя.