Архитектура PostgreSQL HA: выживание при отказе целого региона

Три региона базы данных PostgreSQL с возможностью записи. Один регион выходит из строя. Запись продолжается. Активно-активная многорегиональная PostgreSQL: три региона с возможностью записи в сети pgEdge Spock, с Patroni, etcd, HAProxy и PgBouncer для каждого участника, построенные послойно, а затем разрушенные тремя способами. Многомастерная репликация, отсутствие глобального основного сервера, разрешение конфликтов, локальное переключение при сбое и полная потеря региона. Один экран, никаких слайдов. Каждый регион принимает записи. Пользователь в Нью-Йорке фиксирует изменения в Вирджинии, пользователь в Мумбаи фиксирует изменения в Кейптауне, и оба получают локальную фиксацию, в то время как Spock переносит изменения в другие регионы. Затем я удаляю регион, и оставшиеся продолжают запись. Я строю это с одного сервера. Один узел в Вирджинии, затем во Франкфурте, затем в Кейптауне, и в этот момент это три острова, которые ничего не знают друг о друге. Spock превращает их в сеть. Затем каждый регион получает всё необходимое для выживания после потери машины: зонированные физические резервные серверы, Patroni, etcd с тремя участниками, HAProxy и PgBouncer на каждом участнике. Важно понимать, какой слой отвечает за какие решения. Spock реплицирует строки между регионами. Он не перемещает трафик приложений. Patroni определяет, кто является лидером внутри региона. Только etcd может предоставлять это лидерство. HAProxy использует API ролей Patroni: порт 5000 для сервера записи, 5001 для реплик. PgBouncer использует собственный локальный PostgreSQL для каждого участника. Глобальный DNS фактически направляет пользователей в работоспособный регион. Затем три действия: отключение активного узла в регионе, удаление кворума etcd и удаление всего региона из сети. РАЗДЕЛЫ 0:00 Три региона с возможностью записи, отсутствие глобального основного сервера 0:12 Наблюдение за тем, как регион выходит из строя, в то время как запись продолжается 0:24 План: построить, а затем сломать 0:38 Один сервер в Вирджинии и почему Франкфурт страдает 1:02 Второй активный регион: Франкфурт 1:26 Третий активный регион: Кейптаун 1:49 pgEdge Spock: логическая многомастерная сеть 2:25 Запись куда угодно, фиксация локально 2:53 Конфликты: последнее обновление побеждает и что оно не может исправить 3:17 Внутри региона: зонированные физические резервные серверы 3:46 Patroni решает, кто лидирует локально 4:15 Кворум etcd: ровно один лидер на регион 4:46 HAProxy и два порта (5000 / 5001) 5:13 Почему PgBouncer находится на каждом участнике, а не впереди 5:39 Полная архитектура 6:03 Обычный путь записи, конец к конец 6:31 Масштабирование чтения и задержка репликации, которую необходимо учитывать 6:55 Упражнение 1: отключение активного узла в регионе 7:33 Упражнение 2: потеря кворума etcd 8:04 Упражнение 3: потеря целого региона 8:36 Восстановление региона без нарушения сети 9:05 Плановое техническое обслуживание и обновления 9:38 Итоги ТОПОЛОГИЯ Вирджиния (США-Восток), Франкфурт-на-Майне (ЕС-Центр), Кейптаун (АФ-Юг) Каждый регион: 1 записываемый узел + 2 локальных резервных узла в отдельных зонах доступности Каждый регион: etcd из 3 узлов в 3 зонах, Patroni на каждом узле базы данных Каждый регион: HAProxy, охватывающий зоны, PgBouncer на каждом хосте базы данных Между регионами: pgEdge Spock, каждый узел подписан на каждый другой узел, в обоих направлениях Порты: 5000 к текущему узлу записи, 5001 для соответствующих реплик ЧЕТЫРЕ ВЕЩИ, КОТОРЫЕ ЛЮДИ ЗДЕСЬ ПОНИМАЮТ НЕПРАВИЛЬНО Spock не перемещает трафик приложений. Репликационная сеть не является отказоустойчивой. Если у вас нет глобального уровня трафика, выполняющего проверки работоспособности на уровне приложений, потеря региона все равно приведет к отключению ваших пользователей, даже если два других региона остаются доступными для записи. Слоты логической репликации должны быть готовы к отказоустойчивости на каждом кандидате на повышение роли. Постоянно проверяйте это. Если вы этого не делаете, совершенно обычное локальное переключение Patroni незаметно разрушает межрегиональную сеть, и вы узнаете об этом позже из-за расхождения. PgBouncer должен быть на каждом участнике, а не в виде одного общего пула перед кластером. HAProxy выбирает участника, соответствующего роли Patroni, затем пул этого участника взаимодействует со своим собственным Postgres. Один пул перед кластером переживает смену роли и передает вам соединения с узлом, который больше не является участником записи. Активно-активный режим не исключает конфликтующие операции записи. Spock разрешает поддерживаемые конфликты в соответствии со своей настроенной политикой, обычно по принципу «последнее обновление побеждает», и это зависит от правильной настройки временных меток коммитов. Конфликты, связанные с отсутствием обновления, существованием обновления и уникальностью вторичного узла, не разрешаются автоматически и требуют плана действий. ТАКЖЕ СТОИТ ОТМЕТИТЬ: Чтение реплик может происходить с задержкой, поэтому обеспечен...