стендбай сервер что это

Эволюция отказоустойчивости в PostgreSQL: фаза репликации

Мы продолжаем публиковать серию переводов Gulcin Yildirim, разработчика компании 2ndQuadrant, об отказоустойчивости PostgreSQL и сегодня предлагаем вашему вниманию второй пост из серии.

Gulcin приедет на PG Day’17 и лично ответит на вопросы участников, а также расскажет более подробно не только о репликации в PG, но и об автоматизации апгрейдов Постгреса в облаке и не только. Готовьте свои вопросы!

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

Если вы хотите проследить за процессом эволюции с самого начала, рекомендую вам прочитать первую статью серии: Эволюция отказоустойчивости в PostgreSQL.

Репликация в PostgreSQL

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

Посмотрим на базовую архитектуру. Как правило, отдельные сервера баз данных называются узлами. Вся группа серверов баз данных, задействованных в репликации, известна как кластер. Сервер БД, позволяющий пользователю вносить изменения называется основным (master) или первичным (primary), или может быть описан как источник изменений. Сервер БД, разрешающий доступ только в режиме чтения, называется Горячий резерв или Hot Standby (термин Hot Standby подробно объясняется в разделе Режимы Standby).

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

Давайте посмотрим, как PostgreSQL справлялся с репликацией на протяжении всего своего существования и каково текущее состояние отказоустойчивости в разрезе репликации.

История репликации в PostgreSQL

Когда-то (около 2000-2005 гг.) Постгрес поддерживал только отказоустойчивость/восстановление отдельного узла, что достигалось, в основном, с помощью WAL — журнала транзакций. Частично отказоустойчивость обеспечивается MVCC (системой управления параллельным доступом с помощью многоверсионности), но это по большей части оптимизация.

WAL (write ahead logging) был и остается основным методом обеспечения отказоустойчивости в PostgreSQL. Его суть в том, что у вас есть файлы WAL, в которые вы всё записываете, и, в случае отказа системы, можете воспроизвести их и всё восстановить. Этого было достаточно для архитектур, состоящих из одного узла, а для достижения отказоустойчивости множества узлов лучшим решением считается репликация.

Сообщество Postgres долгое время было уверено, что репликация внутри Постгреса ни к чему, и её можно выполнять внешними инструментами, поэтому появились такие инструменты, как Slony и Londiste. (Мы поговорим о триггерных решениях для репликации в следующих статьях этой серии).

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

Мы пройдемся по всем методам репликации в этой статье, но для начала давайте проследим хронологию событий истории репликации в PostgreSQL по основным релизам:

Физическая репликация

PostgreSQL решил ключевую проблему с необходимостью репликации так же, как и большинство реляционных баз данных: взял WAL и сделал возможным отправлять его по сети. Затем эти WAL файлы загружаются в отдельный инстанс Postgres, который работает в режиме чтения.

Резервный инстанс в режиме чтения просто применяет изменения (из WAL), а единственные операции записи приходят всё из того же журнала WAL. В целом, именно так работает механизм потоковой репликации. Изначально репликацией считалась исходная отправка всех файлов (log shipping), но позднее она превратилась в потоковую.

В log shipping мы отправляли целые файлы с помощью команды archive_command. Логика там была довольно простая: вы просто отправляете архив и куда-то его регистрируете — например, целый WAL файл на 16MБ — а затем применяете его где-то, запрашиваете следующий, применяете его и так далее. Позднее это было поставлено на поток через сеть, благодаря использованию протокола libpq в версии PostgreSQL 9.0.

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

Когда мы применяем к таблице VACUUM, также генерируются записи изменений.

Кроме того, физическая потоковая репликация записывает все изменения на уровне byte/block, так что сделать что-либо, кроме как воспроизвести их на реплике, практически невозможно.

Рис.1 показывает, как физическая репликация работает всего с двумя узлами. Клиент выполняет запросы на главном узле, изменения записываются в журнал транзакций (WAL) и копируются по сети в WAL на резервном узле. Процесс восстановления на узле в режиме ожидания читает изменения из WAL и применяет их к файлам данных, совсем как в случае аварийного восстановления. Если резервный узел находится в режиме hot standby, клиенты могут выполнять запросы на чтение, пока всё это происходит.

Примечание: Физическая репликация — это просто отправка файлов WAL по сети от основного узла к резервному. Файлы могут отправляться разными протоколами, например, scp, rsync, ftp… Разница между физической и физической потоковой репликацией заключается в том, что потоковая репликация использует внутренний протокол для отправки WAL файлов (процессы отправителя и получателя).

Режимы Standby

Несколько узлов обеспечивают высокий уровень доступности. По этой причине современные архитектуры обычно имеют резервные узлы. Существуют разные режимы резервных узлов (“теплый” и “горячий” резерв, warm & hot standby). Далее мы поясним основные различия между режимами резервных узлов и рассмотрим случай с мультимастер архитектурой.

Может быть активирован немедленно, но не может выполнять полезную работу до момента активации. Если мы непрерывно передаем последовательность WAL файлов на другую машину, на которую была загружена базовая резервная копия той же базы, то у нас система warm standby: в любой момент мы можем активировать вторую машину, и на ней будет почти актуальная копия базы данных. Warm standby не позволяет делать запросы в режиме чтения, что наглядно продемонстрировано на Рис.2.

Восстановление в режиме warm stanby происходит настолько быстро, что резервный сервер обычно становится полностью доступен через несколько мгновений после активации. Именно поэтому такой режим называется “теплой” (warm) резервной конфигурацией с высоким уровнем доступности.

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

Понятие «hot standby» также относится к способности сервера перейти от восстановления к нормальной работе, в то время как пользователи продолжают выполнять запросы и/или держат свои соединения открытыми. На Рис.3 видно, что этот резервный режим разрешает запросы на чтение.

Все узлы могут выполнять задачи по чтению/записи. (Мы рассмотрим мультимастер архитектуры в следующих статьях этой серии.)

Параметр WAL Level

Есть связь между настройкой параметра wal_level в файле postgresql.conf и тем, для чего подходит эта настройка. В таблице ниже показана эта связь в PostgreSQL версии 9.6.

Небольшое примечание: параметр wal_level определяет, сколько информации записывается в WAL. Значение по умолчанию — minimal, при котором записывается только информация, необходимая для восстановления после аварии или внезапного отключения. replica добавляет логирование, необходимое для архивирования WAL, а также информацию, необходимую для выполнения запросов на чтение на резервном сервере. И наконец logical добавляет информацию, необходимую для поддержки логического декодирования. Каждый уровень включает в себя информацию, записываемую на всех низких уровнях.

В версиях до 9.6 этот параметр также позволял значения archive и hot_standby. Они по-прежнему принимаются, но отображаются на уровень replica.

Failover и Switchover

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

Если основной узел умирает и не восстанавливается, происходит более серьезная смена ролей, известная как Failover. Эти две процедуры схожи во многих отношениях, но удобнее использовать разные термины для каждого события. (Знание понятий failover и switchover поможет нам разобраться с вопросами хронологии в следующей статье.)

Заключение

В этой статье мы обсудили репликацию в PostgreSQL и её важность для обеспечения отказоустойчивости и надежности. Мы рассмотрели физическую потоковую репликацию и поговорили о режимах standby в PostgreSQL. Также были упомянуты Failover и Switchover. Мы продолжим тему разговором о временных шкалах (timelines) в PostgreSQL в следующей статье.

Помимо выступления Gulcin, мы готовим для вас серию докладов о репликации и проблемах организации отказоустойчивости различных систем хранения данных от таких докладчиков как Света Смирнова, Colin Charles, Николай Мациевский и многих других. Голосуйте за наиболее актуальные для вас темы, мы обязательно учтем все пожелания при составлении финальной программы конференции!

Источник

Защита данных

(Data Guard, by Arup Nanda )

Аруп Нанда, Член-директор коллегии Oracle ACE

Источник: сайт корпорации Oracle, серия статей «Oracle Database 11g: The Top New Features for DBAs and Developers» («Oracle Database 11g: Новые возможности для администраторов и разработчиков»), статья 22 http://www.oracle.com/technetwork/articles/sql/11g-dataguard-083323.html

В этой статье показывается, как механизм Active Data Guard (Активная Защита Данных) делает инвестиции в резервную среду осмысленными (worthwhile), как в результате применяя архивированных журналов и преобразования физической резервной базы данных в резервную снаршот-базу данных выполняются запросы в реальном времени, как появляется хост новой улучшенной инфраструктуры.

В Oracle Database 11g имеется так много расширенных технических возможностей опции Data Guard, что о них можно написать целую книгу. Но «нельзя объять необъятное» в небольшой статье. Поэтому здесь я расскажу только о тех фичах, которые считаю самыми интересными.

Упрощение создания Standby Database (резервной базы данных)

Давайте сначала создадим физическую резервную базу данных (physical standby database). В Oracle Database 11g этот процесс стал намного легче, используя только одну команду утилиты RMAN, которая всё нужное сделает. Ранее можно было использовать визард-интерфейс (wizard interface) опции Grid Control, чтобы построить Data Guard между двумя машинами. Но в этот момент нашего рассуждения механизм Oracle Enterprise Manager Grid Control 11g еще не доступен, а [встроенный] механизм Database Control не имеет визарда Data Guard. Но независимо от опыта использования команд языка SQL, установку среды Data Guard в Oracle Database 11g можно считать пустячным делом. Это настолько просто, что я покажу все нужные шаги прямо здесь.

Предположим, что имя основной (primary) базы данных prolin11 и она работает на сервере prolin1. Надо установить резервную (standby) базу данных на сервере prolin2. Имя экземпляра резервной базы данных должно быть pro11sb. Выполняем следующие действия:

Приведенные ниже две строки – это строки соединения RMAN с основным и резервным экземплярами:

Ну что, создание физической резервной базы данных облегчилось? Да, теперь это столь же просто как выполнение скрипта!

Опция Active Data Guard (Активная Защита Данных)

Одним из традиционных возражений на применение Data Guard с физической резервной базой данных является пассивность этой резервной базы. В Oracle Database 10g и ниже физическая резервная база данных могла открыться только_для_чтения (скажем, чтобы перенести на нее создание отчетов), но это было возможно только после остановки процесса восстановления. В прежних выпусках, если Data Guard — часть DR-решения, действительно нельзя позволить себе приостановить процесс восстановления для длительный период из-за опасности отставания. Таким образом, физическая резервная база данных была фактически бесполезна для любого применения только_для_чтения.

В Oracle Database 11g эта ситуация изменяется: можно открыть физическую резервную базу данных в режиме только_для_чтения и перезапустить процесс восстановления. Это означает, что можно продолжить обеспечение синхронизации с первичной базой, но одновременно можно также использовать резервную базу для производства отчетов. (Как и в предыдущих версиях можно также организовать резервное копирование, используя резервную базу.) Давайте посмотрим, как это делается.

Во-первых, отменим управляемое резервное восстановление:

Затем откроем базу данных в режиме только_для_чтения:

Вплоть до этой точки в pre-11g версиях процессы идентичны. А теперь, 11g-функция покажет свое преимущество: в то время, как резервная база данных открыта в режиме только_для_чтения, можно возобновить управляемый процесс восстановления.

Теперь резервная база переведена в режим управляемого восстановления с применением файлов системного журнала и в тоже время она открыта. Как в этом удостовериться? Довольно просто; проверим только максимальный порядковый номер журнала на первичной базе и сравним его с номером на резервной. На основной базе переключим файлы журнала и проверим максимальный порядковый номер файла журнала:

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

Также 79, то же самое значение, что и на первичной базе. Это доказывает, что накат журнала продолжается. Ну, можно сказать, это просто подтверждает применение журналов; но будут при этом видимы изменения, происходящие на основной базе это время? Давайте проверим. На первичной базе создадим таблицу:

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

Прекрасно! Таблица появилась в резервной базе и готова к запросам.

Помните, мы находились в состоянии Real Time Apply (RTA), в котором изменения, произошедшие на первичной базе немедленно появляются на резервной базе, если доступна сеть. Режим RTA не обязательно подразумевает Active Data Guard (ADG), но делает ADG еще более полезной, поскольку на резервной базе можно видеть последние изменения на базе первичной.

Однако, внимательный читатель может быть обеспокоен проблемами безопасности. База данных находится в режиме только_для_чтения, следовательно, ничто не может быть в нее записано. Но если параметр audit_trail будет установлен в значение DB на первичной базе (значение по умолчанию в Oracle Database 11g), то оно же будет таким же на резервной базе, но данные audit_trail не могут быть записаны в базу данных — она же только_для_чтения. Так куда поступают эти данные?

Найдем строку, которая беззвучно присутствует в журнале регистрации событий (alert log):

AUDIT_TRAIL initialization parameter is changed to OS, as DB is NOT compatible for database opened with read-only access

[Параметр инициализации AUDIT_TRAIL изменяется на OS, поскольку значение DB НЕ совместимо для базы данных, открытой только_для_чтения]

Ага! Сбор аудит-данных (audit trails) не останавливается; он автоматически переводится в файлы OS, когда база данных открыта. Когда активируется резервная база данных, данные audit_trail автоматически удаляются из DB.

Snapshot Standby
(Резервная снапшот- база данных)

Вот типичный сценарий: Предположим, что новое приложение развертывается на базе данных, и вы задаетесь вопросом, какое воздействие оно окажет на производительность базы данных. В Oracle Database 11g имеется усовершенствованный инструмент (Database Replay ), который захватывает SQL-предложения и воспроизводит их, но есть один нюанс: чтобы увидеть производительность, надо их выполнить. Эти запросы приходят из системы тестирования, но их воспроизведение на производственной системе не целесообразно. Во-первых, приложение на ней может не развернуться; а во-вторых, даже если приложение все-таки развернуто, нельзя позволить себе запустить приложение, производящее изменения в чужих таблицах. Так, что же нужно сделать, чтобы определить воздействие приложения?

Правильный ответ дает Oracle Database 11g, в которой физическая резервная база данных (physical standby database) может быть временно преобразована в резервную снапшот- базу данных (Snapshot Standby Database). В этом режиме можно выполнить приложение, которое изменяет множество таблиц, и определить его эффективность. Как только выявлено воздействие приложения, можно восстановить резервную базу данных в ее нормальное состояние. Это выполняется с использованием точки восстановления в базе данных, применяя Flashback-функциональность базы данных, чтобы восстановить ретроспективное состояние в определенной точке, а затем отменить все изменения. Давайте видеть, как это делается.

Во-первых, запустим восстановление на резервном устройстве, если это уже не происходит:

Ждем, пока восстановление не использует несколько файлов системного журнала. Затем остановим восстановление.

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

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

Теперь, когда формальности выполнены, можно преобразовать эту резервную базу данных в спапшот-резервную базу, используя простую команду:

Теперь перезапустим базу данных:

Теперь база данных открыта для операций чтения-записи:

Теперь закрываем базу, затем открываем ее в режиме mount и стартуем процесс «managed recovery» (управляемое восстановление):

Старт процесса управляемого восстановления:

Теперь резервная база данных вернулась в режим управляемого восстановления (managed recovery mode). Само собой разумеется, что когда база была в режиме снапшот, архивные журналы, полученные от первичной базы данных, к ней не применялись. Теперь они будут задействованы, но это может занять некоторое время прежде, чем резервная база полностью нагонит первичную.

Снапшот-резервная база данных позволяет использовать резервную базу данных для точного предсказания последствий изменений в производственной базе прежде, чем изменения были сделаны. Но и не только это. Есть и другое преимущество. Помните, мы использовали RTA, когда изменения в первичной базе данных немедленно появляются на резервной базе, если, конечно, доступна сеть? Ну, а если кто-то сделает ошибку на основной базе данных, например, выполнив массовое обновление или изменение некоего кода? В предыдущих версиях мы сознательно использовали задержку [обновления] резервной базы данных, чтобы задержать распространение таких ошибок на резервную базу. Но такая задержка также означает, что резервная база не может быть одномоментно активирована или использоваться в качестве активной копии производственной базы.

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

Преобразование физической резервной базы в логическую
(Conversion from Physical to Logical Standby)

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

Теперь логическая резервная база данных полностью готова к эксплуатации! Но как только физическая резервная база преобразовывается в логическую, обратное преобразование в физическую невозможно, если только не воспользоваться специальной фразой («keep identity»), описанный в разделе ниже.

Rolling Upgrade
(Накатываемые обновления)

Не секрет, что одной из болевых точек в деятельности администратора базы данных является необходимость прерывать работу базы данных на разумные по длительности периоды времени, чтобы выполнить обновления. В Oracle Database 11g это стало значительно легче при наличии резервной базы данных какого-либо типа посредством использования процесса накатывания обновлений:

Если имеется логическая резервная база, все довольно просто, поскольку такая резервная база непосредственно применяет SQL-предложения, поступающие из первичной базы, и обновление может легко быть на ней сделано. Можно остановить восстановление, обновить резервную базу, затем продолжать восстановление, чтобы нагнать первичную, а затем переключить между собой резервную и первичную базы. Затем сделать обновление на базе данных, которая была первичной, а стала резервной логической, и, наконец, обратно поменять роли этих баз так, чтобы первичной снова стала обновленная исходная первичная база. А обновленная резервная база, побыв некоторое время первичной базой, снова резервной.

Однако из-за простоты использования и управления многие резервные базы данных строятся как физические. Если резервная база не логическая, а физическая, то с незначительными различиями перечисленные выше действия в большинстве своем остаются теми же самыми: нужно временно преобразовать резервную базу в логическую, а затем преобразовать её обратно в физическую. Здесь ключевое слово «временно» — не навсегда! Поэтому надо воспользоваться командой конвертации с новой фразой «keep identity» («сохранение идентификационных данных»), как показано ниже:

Другие усовершенствования
(Other Improvements)

Есть ещё несколько существенных усовершенствований функциональности Data Guard, например:

Сжатие redo-журналов
(Redo Compression)

В Oracle Database 11g можно сжать поток redo-файлов, который идет на резервный сервер через SQL*Net, если установить параметр компрессии в значение true. Это работает только для журнальных файлов, которые посылаются для ликвидации разрыва связи. Вот команда, которую можно использовать, чтобы включить сжатие в нашем примере

Сетевой тайм-аут
Net Timeout

Механизм Data Guard отправляет redo-данные на резервный сервер, где соединяется с экземпляром базы данных. Если этот экземпляр вовремя не отвечает, служба передачи журналов ждёт в течение заданного времени ожидания, а затем отказывается от соединения. Значение тайм-аута может быть установлено в Oracle Database параметром net_timeout. В режиме максимальной защищенности (maximum protection) служба передачи журналов повторит попытку 20 раз перед отказом.

Но сначала необходимо узнать, как много в настоящий момент имеется задержанных к передаче журналов. Новое представление v$redo_dest_resp_histogram показывает это время как гистограмму:

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

Возвращаясь к нашему примеру отметим в значении параметра элемент «net_timeout=20».

Динамически Изменяемые Параметры
(Dynamically Alterable Parameters)

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

Это установит значение параметра apply_servers равным 2, что может быть сделано без остановки резервной базы.

Таблица Событий SQL Apply
SQL Apply Event Table

В Oracle Database 10g события, связанные с SQL Apply? записываются в аварийный журнал, что не очень эффективно, так как можно написать скрипты, которые проверят предупреждения и создадут отчеты. В Oracle Database 11g события по умолчанию записываются в новую таблицу LOGSTDBY$EVENTS в схеме SYSTEM. Вот пример запроса:

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

Это можно сделать динамически, и теперь события попадут и в таблицу, и в журнал регистрации событий (alert log – также аварийный журнал базы данных). После выполнения этой команды можно проверить журнал событий; предлагается альтернатива выбора наименьшего из этих двух строк и возможно большего количества событий Apply SQL:

Заключение

Во-первых, было показано, как тривиально можно создать физическую резервную базу данных из активной основной базы данных. Кроме того, показано, как легко можно преобразовать эту физическую резервную базу в логическую. Самое большое преимущество заключается в том, что резервная база может теперь продуктивно использоваться, обеспечивая некоторые бизнес-действия. Опция Active Data Guard позволяет открывать резервные базы данных для выполнения запросов с одновременным применением архивных журналов. Резервная база данных типа снапшот позволяет выполнять на базе производственные задачи с последующим возвратом к некой точке в прошлом, с которой возобновляется нормальный процесс управляемого восстановления. Эти две возможности позволяют повысить эффективность задействования резервного сервера, что должно быть существенным поводом для применения продвинутых опций Oracle Database 11g R2.

Источник