PostgreSQL - это СУБД с одним узлом. Таблицы не разделены / разделены по горизонтали на более мелкие компоненты, так как все данные в любом случае обслуживаются с одного узла. В развертывании высокой доступности (HA) используется пара главный-подчиненный узел. Мастер отвечает за обработку записи / обновления данных. Зафиксированные данные асинхронно копируются в полностью независимый «ведомый» экземпляр. В случае отказа мастера клиенты приложения могут начать разговор с экземпляром ведомого устройства с предупреждением о том, что они не увидят данные, которые были недавно зафиксированы на главном сервере, но еще не скопированы на ведомое устройство. Обычно аварийное переключение между подчиненными, восстановление мастера и восстановление подчиненного управления обрабатываются вручную.
С другой стороны, YugaByte DB - это распределенная СУБД, созданная на основе Google Spanner , где развертывания HA начинаются с минимум 3 узлов. Таблицы горизонтально разделены / разделены на более мелкие компоненты, называемые «таблетками». Таблетки распределяются по всем доступным узлам равномерно. Каждый планшет становится устойчивым к сбоям благодаря автоматическому хранению 2 дополнительных копий на 2 дополнительных узлах, что в итоге дает 3 копии. Эти 3 копии известны как группа планшетов. Вместо управления репликацией на уровне всего экземпляра, включающей все данные (как это делает PostgreSQL), репликация YugaByte DB управляется на уровне отдельных групп планшетов с использованием протокола распределенного консенсуса , называемого Raft .
Плот (вместе с механизмом, называемым Leader Leases) гарантирует, что только 1 из 3 копий может быть лидером (ответственным за обслуживание операций записи / обновления и строго согласованного чтения) в любое время. Записи для данной строки обрабатываются соответствующим лидером планшета, который фиксирует данные локально, а также, по крайней мере, 1 подписчик, прежде чем подтвердить успешность клиентского приложения. Потеря узла приводит к потере лидеров планшета, размещенных на этом узле. Новые обновления на этих планшетах не могут быть обработаны до тех пор, пока новые лидеры планшетов не будут автоматически выбраны среди оставшихся подписчиков. Этот автоматический выбор обычно занимает несколько секунд и в первую очередь зависит от задержки в сети между узлами. После завершения выборов кластер готов принимать записи даже для планшетов, на которые повлиял сбой узла.
Дизайн Google Spanner, за которым следует БД YugaByte, требует фиксации данных на одну копию больше, чем PostgreSQL, что означает повышенную задержку записи по сравнению с PostgreSQL. Но, в свою очередь, извлекаются выгоды от встроенного ремонта (посредством автоматического выбора лидера) и отработки отказа (для нового лидера после выборов). Даже восстановление после сбоя (после того, как неисправный узел снова подключен к сети) выполняется автоматически. Этот вариант лучше использовать, если ожидается, что инфраструктура, в которой работает кластер БД, будет выходить из строя чаще, чем раньше.
Подробнее см. Мою запись на эту тему.