Курс молодого бойца PostgreSQL

Замечания

pg_upgrade не поддерживает обновление баз данных, содержащих следующие ссылающиеся на OID системные типы данных reg*: regproc, regprocedure, regoper, regoperator, regconfig и regdictionary. (Обновление regtype возможно.)

Программа pg_upgrade сообщит обо всех актуальных для вашей инсталляции ошибках и потребностях перестроения или переиндексации базы; при этом будут созданы завершающие обновление скрипты, перестраивающие таблицы или индексы. Если вы попытаетесь автоматизировать обновление множества серверов, вы обнаружите, что для кластеров с одинаковыми схемами баз данных потребуются одинаковые действия после обновления; это объясняется тем, что эти действия диктуются схемой базы данных, а не данными пользователей.

Для проверки развёртывания новой версии создайте копию только схемы старого кластера, наполните этот кластер фиктивными данными, и попробуйте обновить его.

Если вы производите обновление кластера PostgreSQL версии до 9.2, в которой используется каталог только с файлами конфигурации, вы должны передать расположение собственно каталога с данными программе pg_upgrade, а расположение каталога конфигурации передать серверу, например -d /каталог-данных -o '-D /каталог-конфигурации'.

Если вы используете старый сервер версии до 9.1, работающий с нестандартным каталогом доменных сокетов Unix, либо его стандартное расположение отличается от принятого в новой версии, задайте в PGHOST расположение сокета старого сервера. (К Windows это не относится.)

Резервные серверы, принимающие журналы (см. Раздел 25.2), обновить таким способом нельзя, так как они должны допускать запись. Поэтому проще всего будет обновить ведущий сервер, а затем перестроить резервные, применив rsync. Вы можете запустить rsync, когда ведущий будет отключён, либо в ходе восстановления базовой копии (см. ), что приведёт к перезаписи старого резервного кластера.

Если вы хотите использовать режим ссылок на данные, но не хотите каких-либо изменений в старом кластере при запуске нового, сделайте копию старого кластера и обновите его в этом режиме. Чтобы получить рабочую копию старого кластера, воспользуйтесь командой rsync и создайте предварительную копию кластера при работающем сервере, а затем отключите старый сервер и ещё раз запустите rsync, чтобы привести эту копию в согласованное состояние. При этом вы можете исключить некоторые файлы, например postmaster.pid, как описано в

Если ваша файловая система поддерживает снимки файловой системы или копирование при записи, вы можете воспользоваться этим для создания копии старого кластера и табличных пространств; при этом важно, чтобы такие снимки и копии файлов создавались одномоментно или когда сервер баз данных отключён

Описание

pg_ctl — это утилита для начальной инициализации, запуска, остановки, повторного запуска и управления кластером баз данных PostgreSQL (postgres). Сервер можно стартовать в ручном режиме, но pg_ctl реализует задачи направления вывода в журнал и отсоединения от терминала и группы процессов, а также предоставляет удобный интерфейс остановки кластера.

Команда () создаёт кластер баз данных PostgreSQL, то есть коллекцию баз данных, которой будет управлять один экземпляр сервера. Эта команда вызывает программу . За подробностями обратитесь к initdb.

Команда запускает сервер. Процесс запускается в фоне, а стандартный ввод связывается с (или в Windows). По умолчанию в Unix-подобных системах вывод и ошибки сервера пишутся в устройство стандартного вывода (не ошибок) pg_ctl. Вывод pg_ctl следует перенаправить в файл или процесс, например, приложение ротации журналов rotatelogs; иначе будет писать вывод в управляющий терминал (в фоновом режиме) и останется в группе процессов оболочки. В Windows сообщения и ошибки сервера по умолчанию перенаправляются в терминал. Это поведение по умолчанию можно изменить и направить вывод сервера в файл, добавив ключ . Предпочтительными вариантами является использование или перенаправление вывода.

Команда останавливает сервер, работающий с указанным каталогом данных. Параметр позволяет выбрать один из трёх режимов остановки. Режим «Smart» ожидает отключения всех активных клиентов и завершения всех текущих процессов резервного копирования. Если сервер работает в режиме горячего резерва, восстановление и потоковая репликация будут прерваны, как только отключатся все клиенты. Режим «Fast» (выбираемый по умолчанию) не ожидает отключения клиентов и завершает все текущие процессы резервного копирования. Все активные транзакции откатываются, а клиенты принудительно отключаются, после чего сервер останавливается. Режим «Immediate» незамедлительно прерывает все серверные процессы, не выполняя процедуру штатной остановки. Этот вариант влечёт необходимость выполнить восстановление после сбоя при следующем запуске сервера.

Команда по сути производит остановку и последующий запуск сервера. Это позволяет изменить параметры командной строки либо применить изменения в файле конфигурации, не вступающие в силу без перезапуска сервера. Если в командной строке при запуске сервера указывались относительные пути, команда может не выполниться, если вызвать pg_ctl не в том каталоге, где производился предыдущий запуск.

Команда просто посылает процессу сервера сигнал SIGHUP, получив который он перечитывает свои файлы конфигурации (, и т. д.). Это позволяет применить изменения параметров в файле конфигурации, не требующие полного перезапуска сервера.

Команда проверяет, работает ли сервер в указанном каталоге данных. Если да, она выдаёт PID сервера и параметры командной строки, с которыми он был запущен. Если сервер не работает, pg_ctl возвращает код завершения 3. Если в параметрах не указан доступный каталог данных, pg_ctl возвращает код завершения 4.

Команда указывает серверу, работающему в режиме резерва с указанным каталогом данных, выйти из этого режима и начать операции чтения/записи.

Команда прокручивает файл журнала сервера. Подробнее о том, как использовать это с внешними средствами прокрутки журнала, рассказывается в Разделе 24.3.

Команда передаёт сигнал заданному процессу. Прежде все это полезно в Microsoft Windows, где отсутствует встроенная команда kill. Для получения списка имён поддерживаемых сигналов воспользуйтесь ключом .

Команда регистрирует сервер PostgreSQL в качестве системной службы в Microsoft Windows. Параметр позволяет выбрать тип запуска службы: «auto» (запускать службу автоматически при загрузке системы) или «demand» (запускать службу по требованию).

Установка PostgreSQL 11 в Windows 10

Для установки PostgreSQL перейдите на сайт https://www.postgresql.org и скачайте последнюю версию дистрибутива для Windows, на сегодняшний день это версия PostgreSQL 11 (в 11 версии PostgreSQL поддерживаются только 64-х битные редакции Windows). После загрузки запустите инсталлятор.

В процессе установки установите галочки на пунктах:

  • PostgreSQL Server – сам сервер СУБД
  • PgAdmin 4 – визуальный редактор SQL
  • Stack Builder – дополнительные инструменты для разработки (возможно вам они понадобятся в будущем)
  • Command Line Tools – инструменты командной строки

Установите пароль для пользователя postgres (он создается по умолчанию и имеет права суперпользователя).

По умолчание СУБД слушает на порту 5432, который нужно будет добавить в исключения в правилах фаерволла.

Нажимаете Далее, Далее, на этом установка PostgreSQL завершена.

Клонирование базы данных

Время от времени приходится создавать миграции для баз данных. Процесс разработки такой миграции полон боли и ошибок, а это значит, что я создаю их итерационно, проверяя каждую написанную команду. Я накатываю и откатываю миграцию много раз, убеждаясь что ничего не ломается.

Локальная база данных, на которой я тренируюсь, обычно заполнена вручную или восстановлена из дампа с прода. Т.к. я гоняю преобразование схемы много раз, то обязательно случается, что данные приходят в некорректное состояние. В таком случае я восстанавливаю базу из дампа, что может отнимать достаточно много времени.

В данном случае проще будет воспользоваться клонированием базы данных, а если что-то пойдёт не так, то восстановить из бэкапа. Благо это делается в пару строчек. Для копирования достаточно указать существующую в качестве шаблона.

Для восстановления удалим существующую и склонируем обратно.

Утилиты, помогающие с реализацией

Pacemaker

Pacemaker это open-source high availability менеджер ресурсов, который используется в кластерных системах с 2004 года. До 2007 года, был частью проекта Linux-HA, но затем превратился в отдельный проект.
Он реализует несколько API для управления ресурсами.

Особенности

  • Обнаружение и восстановление сбоев на уровне узлов и сервисов;
  • Независимость от подсистемы хранения: общий диск не требуется;
  • Независимость от типов ресурсов: все что может быть заскриптовано, может быть кластеризовано;
  • Поддержка STONITH (Shoot-The-Other-Node-In-The-Head) — лекарства от Split-Brain (появление одновременно двух master-узлов)
  • Поддержка кластеров любого размера;
  • Поддержка и кворумных и ресурсозависимых кластеров;
  • Поддержка практически любой избыточной конфигурации;
  • Автоматическая репликация конфига на все узлы кластера;
  • Возможность задания порядка запуска ресурсов, а также их совместимости на одном узле;
  • Поддержка расширенных типов ресурсов: клонов (запущен на множестве узлов) и с дополнительными состояниями (master/slave и т.п.);
  • Единый кластерный шелл (crm), унифицированный, скриптующийся.

Corosync

Corosync (Corosync Cluster Engine) — проект с открытым исходным кодом, реализующий систему группового общения для отказоустойчивых кластеров. Является развитием проекта OpenAIS и опубликован в соответствии с модифицированной лицензией BSD.

Особенности

Проект предоставляет четыре набора API для языка Си:

  • «Закрытая группа процессов» (англ. Closed Process Group — CPG) — модель взаимодействия, реализующая виртуальную синхронизацию, которая гарантирует, что процессы на узлах кластера получат одинаковые сообщения в одинаковом порядке.
  • «Простой менеджер доступности» (англ. Simple Availability Manager — SAM), отслеживающий состояния приложений и позволяющий их перезапускать после сбоя.
  • «База данных конфигурации» (англ. Configuration database — confdb) в оперативной памяти, позволяющая получать конфигурацию и статистику Corosync, менять конфигурацию и получать уведомления об её изменениях.
  • «Кворум» (англ. quorum) — система, оповещающая приложения о том, достигнут кворум (необходимое минимальное количество активных узлов кластера) или нет.

Программное обеспечение предназначено для работы в сетях UDP/IP и InfiniBand.

Однопользовательский режим

Для запуска сервера в однопользовательском режиме используется, например, команда

Необходимо указать корректный путь к каталогу хранения данных в параметре , или установить переменную окружения . Также замените имя базы данных на необходимое.

Обычно перевод строки в однопользовательском режиме сервер воспринимает как завершение ввода команды; точка с запятой не имеет для него такого значения, как для psql. Поэтому, чтобы ввести команду, занимающую несколько строк, необходимо добавлять в конце каждой строки, кроме последней, обратную косую черту. Обратная косая черта и следующий за ней символ перевода строки автоматически убираются из вводимой команды. Заметьте, что это происходит даже внутри строковой константы или комментария.

Но если применить аргумент командной строки , одиночный символ перевода строки не будет завершать ввод команды; это будет делать последовательность «точка с запятой, перевод строки, перевод строки». То есть для завершения команды нужно ввести точку с запятой, и сразу за ней пустую строку. Просто точка с запятой, дополненная переводом строки, в этом режиме не имеет специального значения. Внутри строковых констант и комментариев такая завершающая последовательность воспринимается в том же ключе.

Вне зависимости от режима ввода, символ точки с запятой, введённый не прямо перед или в составе последовательности завершения команды, воспринимается как разделитель команд. После ввода завершающей последовательности введённые с разделителями несколько операторов будут выполняться в одной транзакции.

Для завершения сеанса введите символ конца файла (EOF, обычно это сочетание Control+D). Если вы вводили текст после окончания ввода последней команды, символ EOF будет воспринят как символ завершения команды, и для выхода потребуется ещё один EOF.

Кластеры SQL

  1. Несколько экземпляров- нод кластера СУБД, каждая из которых использует одну Систему Хранения Данных (СХД).
    Достоинства: простая реализация
    Недостатки: СХД — единственная точка отказа. Пока СХД не будет кластеризована своими инструментами, СУБД-кластер нельзя назвать полностью отказоустойчивым именно по этой причине.
  2. Синхронная репликация. Когда несколько нод кластера имеют собственную систему хранения данных (локальные диски, или у каждого свой NAS). Система может работать в режиме «Актив — Актив» (когда каждая нода может принимать подключения от клиентов и проводить транзакции с базами), и «Актив-Пассив» (когда одна из нод кластера принимает транзакции и осуществляет работу с базами данных, при этом «пассивная» нода переходит в состояние «активной» при неисправности первой ноды, или по запросу администратора). Вне зависимости от режима работы, каждая транзакция гарантированно реплицируется на все ноды кластера, что влияет на гарантированно надежный способ репликации над кластера. Осуществляется это просто: клиент отправляет запрос базе данных >> активная нода принимает запрос, отправляет копию запроса на остальные ноды кластера и после этого сама выполняет запрос >> остальные ноды кластера, получив запрос, выполняют его и только после его выполнения и записи изменений в базу данных отправляют активной ноде кластера сообщение об успешном завершении транзакции >> активная нода кластера, убедившись, что все запросы на всех нодах (в том числе и сама) выполнены успешно, отправляет клиенту сообщение об успешном выполнении запроса. Такая схема вынуждает клиента ждать, пока все ноды кластера получат запросы и их обработают. Если одна из нод «тормозит» — то весь кластер будет работать медленно. Поэтому такой способ кластеризации хоть и самый надежных в плане синхронности базы данных всех реплик, но еще самый медленный.
    Достоинства: самый надежный способ репликации, исключена рассинхронизация нод.
    Недостатки: низкая производительность, падение пассивной ноды вызывает «лаг» — прекращение транзакций, пока кластер по таймауту не поймет, что нода кластера упала. Высокие требования к сетевой скорости между нодами кластера.
  3. Асинхронная репликация. Когда несколько нод кластера имеют собственную систему хранения данных (локальные диски, или у каждого свой NAS). Система может работать в режиме «Актив-Пассив», когда одна из нод кластера принимает транзакции и осуществляет работу с базами данных, при этом «пассивная» нода переходит в состояние «активной» при неисправности первой ноды, или по запросу администратора). В отличие от синхронной репликации, асинхронная репликация не гарантирует полную идентичность баз данных на всех нодах кластера. Объясняется это просто:: клиент отправляет запрос базе данных >> активная нода принимает запрос, отправляет копию запроса на остальные ноды кластера и после этого сама выполняет запрос >> как только активная нода сама выполнила запрос, она отправляет клиенту сообщение об успешном выполнении запроса (не дожидаясь сообщений об успешном выполнении транзакции от остальных нод кластера). На этом этапе клиент уже выполнил транзакции, и шлет новые в очередь активной ноды СУБД. Однако остальные ноды кластера на данный момент могут не выполнить транзакции! Конечно, получив запрос, пассивные ноды выполняют его и сообщают активной ноде о результатах выполнения, однако для клиента СУБД эта информация уже не важна, т.к. он получил ответ об успешной записи в базу данных намного раньше. Асинхронная репликация потому и называется, что пассивные ноды несколько «отстают» от активной. Их базы данных могут быть рассинхронизированными на момент падения активной ноды. В момент выхода из строя активной ноды, есть вероятность потерь данных (небольшой ее части, но потери есть).
    Достоинства: высокая производительность, падение пассивной ноды не отражается на работе, меньшие требования к скорости сети между нодами (пассивную ноду можно подключить через интернет для синхронизации по узкому каналу, когда на конечную производительность клиентов это не повлияет)
    Недостатки: нет гарантий рассинхронизации нод кластера (в момент падения активной ноды, вторая нода может не успеть ссинхронизировать последние изменения баз данных с активной ноды до ее падения).

18.1.3. Управление параметрами через SQL

В PostgreSQL есть три SQL-команды, задающие для параметров значения по умолчанию. Уже упомянутая команда ALTER SYSTEM даёт возможность изменять глобальные значения средствами SQL; она функционально равнозначна редактированию postgresql.conf. Кроме того, есть ещё две команды, которые позволяют задавать значения по умолчанию на уровне баз данных и ролей:

  • Команда ALTER DATABASE позволяет переопределить глобальные параметры на уровне базы данных.

  • Команда ALTER ROLE позволяет переопределить для конкретного пользователя как глобальные, так и локальные для базы данных параметры.

Значения, установленные командами ALTER DATABASE и ALTER ROLE, применяются только при новом подключении к базе данных. Они переопределяют значения, полученные из файлов конфигурации или командной строки сервера, и применяются по умолчанию в рамках сеанса. Заметьте, что некоторые параметры невозможно изменить после запуска сервера, поэтому их нельзя установить этими командами (или командами, перечисленными ниже).

Когда клиент подключён к базе данных, он может воспользоваться двумя дополнительными командами SQL (и равнозначными функциями), которые предоставляет PostgreSQL для управления параметрами конфигурации:

  • Команда SHOW позволяет узнать текущее значение всех параметров. Соответствующая ей функция — .

  • Команда SET позволяет изменить текущее значение параметров, которые действуют локально в рамках сеанса; на другие сеансы она не влияет. Соответствующая ей функция — .

Кроме того, просмотреть и изменить значения параметров для текущего сеанса можно в системном представлении pg_settings:

Работа с данными и полями таблиц

Удаление одинаковых строк

Если так получилось, что в таблице нет первичного ключа (primary key), то наверняка среди записей найдутся дубликаты. Если для такой таблицы, особенно большого размера, необходимо поставить ограничения (constraint) для проверки целостности, то удалим следующие элементы:

  • дублирующиеся строки,
  • ситуации, когда одна или более колонок дублируются (если эти колонки предполагается использовать в качестве первичного ключа).

Рассмотрим таблицу с данными покупателей, где задублирована целая строка (вторая по счёту).

Удалить все дубликаты поможет следующий запрос:

Уникальное для каждой записи поле по умолчанию скрыто, но оно есть в каждой таблице.

Последний запрос требователен к ресурсам, поэтому будьте аккуратны при его выполнении на рабочем проекте.

Системный инженер

«Т—Ж», Москва

tproger.ru

Вакансии на tproger.ru

Теперь рассмотрим случай, когда повторяются значения полей.

Если допустимо удаление дубликатов без сохранения всех данных, выполним такой запрос:

Если данные важны, то сначала нужно найти записи с дубликатами:

Перед удалением такие записи можно перенести во временную таблицу или заменить в них значение на другое.

Общая форма запроса на удаление описанных выше записей выглядит следующим образом:

Безопасное изменение типа поля

Может возникнуть вопрос о включении в этот список такой задачи. Ведь в PostgreSQL изменить тип поля очень просто с помощью команды . Давайте для примера снова рассмотрим таблицу с покупателями.

Для поля используется строковый тип данных . Это ошибка, так как в этом поле предполагается хранить идентификаторы покупателей, которые имеют целочисленный формат . Использование неоправданно. Попробуем исправить это недоразумение с помощью команды :

Но в результате выполнения получим ошибку:

Это значит, что нельзя просто так взять и изменить тип поля при наличии данных в таблице. Так как использовался тип , СУБД не может определить принадлежность значения к . Хотя данные соответствуют именно этому типу. Для того, чтобы уточнить этот момент, в сообщении об ошибке предлагается использовать выражение , чтобы корректно преобразовать наши данные в :

В результате всё прошло без ошибок:

Обратите внимание, что при использовании кроме конкретного выражения возможно использование функций, других полей и операторов. Например, преобразуем поле обратно в , но с преобразованием формата данных:

Например, преобразуем поле обратно в , но с преобразованием формата данных:

В результате таблица примет следующий вид:

Поиск «потерянных» значений

Будьте внимательны при использовании последовательностей (sequence) в качестве первичного ключа (primary key): при назначении некоторые элементы последовательности случайно пропускаются, в результате работы с таблицей некоторые записи удаляются. Такие значения можно использовать снова, но найти их в больших таблицах сложно.

Рассмотрим два варианта поиска.

Первый способ
Выполним следующий запрос, чтобы найти начало интервала с «потерянным» значением:

В результате получим значения: , и .

Если нужно найти не только первое вхождение, а все пропущенные значения, используем следующий (ресурсоёмкий!) запрос:

В результате видим следующий результат: , и .

Второй способ
Получаем имя последовательности, связанной с :

И находим все пропущенные идентификаторы:

Подсчёт количества строк в таблице

Количество строк вычисляется стандартной функцией , но её можно использовать с дополнительными условиями.

Общее количество строк в таблице:

Количество строк при условии, что указанное поле не содержит :

Количество уникальных строк по указанному полю:

Использование транзакций

Транзакция объединяет последовательность действий в одну операцию. Её особенность в том, что при ошибке в выполнении транзакции ни один из результатов действий не сохранится в базе данных.

Начнём транзакцию с помощью команды .

Для того, чтобы откатить все операции, расположенные после , используем команду .

А чтобы применить — команду .

Просмотр и завершение исполняемых запросов

Для того, чтобы получить информацию о запросах, выполним следующую команду:

Для того, чтобы остановить конкретный запрос, выполним следующую команду, с указанием id процесса (pid):

Для того, чтобы прекратить работу запроса, выполним:

Почему мы перешли с Redis на PostgreSQL

  1. Высокая скорость ответа, т.к. всё хранится в памяти;
  2. Удобство бэкапа и репликации.
  1. Нет настоящих транзакций. Мы пытались имитировать их на уровне нашего приложения. К сожалению, это не всегда хорошо работало и требовало написания очень сложного кода.
  2. Объём данных ограничен количеством памяти. При увеличении количества данных память будет расти, и, в конце концов, мы упрёмся в характеристики выбранного инстанса, что в AWS требует остановки нашего сервиса для изменения типа инстанса.
  3. Необходимо постоянно поддерживать уровень низкого latency, т.к. у нас очень большое количество запросов. Оптимальный для нас уровень задержки — 17-20 ms. При уровне 30-40 ms мы получаем долгие ответы на запросы нашего приложения и деградацию сервиса. К сожалению, у нас это случилось в сентябре 2018 года, когда один из инстансов с Redis почему-то получил latency в 2 раза больше обычного. Для решения проблемы мы остановили сервис в середине рабочего дня для внепланового maintenance и заменили проблемный инстанс Redis.
  4. Легко получить неконсинстентность данных даже при незначительных ошибках в коде и потом потратить много времени на написание кода для исправления этих данных.

статье моего коллеги

1С Сервер на PostgreSQL

Я перечислю некоторые факты относительно реализации PostgreSQL в качестве СУБД для 1С Сервера:

Да, это работает, и pgsql бесплатен.
Для 1С Сервера публикуется специальный пропатченный релиз PostgreSQL. Его использование обязательно для 1С Сервера

Уже пропатченный pgsql распространяется самим 1С, при этом релизы сильно отстают от актуальных версий postgreSQL.
Пропатченный postgreSQL можно скачать как для Windows-платформы, так и для Linux.
Важно! Кластеризация пропатченного PostgreSQL для 1С Сервера будет работать только в случае установки PostgreSQL на Linux! Для 1С Сервера единственный рабочий способ кластеризации pgsql — это Streaming Replication, который в пропатченной версии работает только на Linux-версии pgsql 9.1
Скорость работы postgreSQL на Windows в сочетании с 1С Сервером намного ниже, по сравнению с PostgreSQL на Линукс-платформе.

Замечания

В случаях, когда происходит обращение к случайным единичным строкам таблицы, фактический порядок данных в этой таблице не важен. Но если обращения к одним данным происходят чаще, чем к другим, и есть индекс, который собирает их вместе, применение команды может быть полезным. Например, когда из таблицы запрашивается диапазон индексированных значений, либо одно индексированное значение, которому соответствуют несколько строк, может помочь, так как страница таблицы, найденная по индексу для первой искомой строки, скорее всего, будет содержать и все остальные искомые строки. Таким образом, кластеризация помогает соптимизировать обращения к диску и ускорить запросы.

может переупорядочить таблицу, выполнив либо сканирование указанного индекса, либо (для индексов-B-деревьев) последовательное сканирование, а затем сортировку. Наилучший по скорости вариант будет выбран, исходя из имеющейся статистической информации и параметров планировщика.

Когда выбирается сканирование индекса, создаётся временная таблица, содержащая данные целевой таблицы по порядку индекса. Также создаются копии всех индексов таблицы. Таким образом, для этой операции требуется объём дискового пространства не меньше, чем размер таблицы и индексов в сумме.

В случае выбора последовательного сканирования и сортировки создаётся ещё и временный файл для сортировки, так что пиковым требованием будет удвоенный размер таблицы плюс размер индексов. Этот метод часто быстрее, чем сканирование по индексу, но если требование к дисковому пространству неприемлемо, можно отключить его выбор, временно установив в .

Перед кластеризацией рекомендуется установить в достаточно большое значение (но не больше, чем объём ОЗУ, который вы хотите выделить для операции ).

Так как планировщик записывает статистику, связанную с порядком таблиц, для вновь кластеризуемых таблиц рекомендуется запускать ANALYZE. В противном случае планировщик может ошибиться с выбором плана запроса.

Выводы

В современном мире практически любой информационный ресурс, который испытывает рост посещаемости и повышенную нагрузку, сталкивается с проблемой отказа важного оборудования. И пока нет ничего проще и надежнее, чем резервировать важные узлы, например СУБД

Это требует сильных избыточных аппаратных ресурсов, но показатели надежности возрастают многократно. Это обусловлено тем, что вероятность отказа обоих узлов одновременно на порядок ниже, чем вероятность отказа одного из них.

В данном примере было разобрано построение отказоустойчивого (Active/Passive) кластера, главный ресурс которого это сервер PostgreSQL и непосредственно хранилище данных, а синхронизация и правила миграции определялись с помощью Pacemaker и Corosync.
На месте ресурсов могут быть не только хранилища и PostgreSQL. Возможны и многие другие реализации различных кластеров. Например, можно аналогично сделать отказоустойчивый кластер с Apache или Nginx, что делает решение гибким. Сама процедура не очень сложная, и с актуальной (на момент написания) версией PostgreSQL работает исправно.

Результат проделанной работы можно использовать для построения кластеров иного типа (в которых будет более двух узлов), предварительно определив правила миграции ресурсов.

Ссылка на основную публикацию