Введение

Для установки серверной пары High-availability Data Replication (HDR) поддерживается External Backup and Restore (EBR). EBR можно использовать для серверных хранилищ и для применения в выполняющихся системных инструментальных программах. EBR теперь поддерживается программой ontape, а также программой ON-Bar.

Программа ontape теперь может записывать резервные данные на стандартное устройство вывода (stdout), а не только на устройство хранения на магнитной ленте или в дисковый файл. Для процедуры восстановления данных ontape может считывать данные из устройства стандартного ввода (stdin), а не только из устройства хранения на магнитной ленте или из дискового файла. Этот процесс использует каналы (pipe) для резервного копирования и восстановления (предоставляемый операционной системой буферный механизм соединения отдельных программ с потоком данных).

В начало

Установка внешнего резервного копирования и восстановления для HDR

Программа ON-Bar обеспечивает только физическое восстановление с EBR, поэтому она может быть использована с HDR. В HDR физическое восстановление вторичного сервера следует после синхронизации с первичным путем прогона логического журнала; восстановление логического журнала из устройства хранения резервных данных не обязательно. Программа ontape тоже поддерживает EBR для HDR.

Преимущества

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

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

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

Описание

Внешнее резервное копирование данных на первичном сервере производится при помощи команд onmode -c block и onmode -c unblock, как описано в главе "Выполнение внешнего резервного копирования и восстановления" книги "Руководство IBM Informix по резервному копированию и восстановлению". Вы выбираете программу для выполнения внешнего резервного копирования или восстановления. Программа должна подходить для копирования и восстановления фрагментов, используемых Informix Dynamic Server, и может зависеть от того, расположены ли эти фрагменты на устройствах последовательного доступа, или хранятся в файлах в файловой системе. Обычным выбором является системная программа dd, предоставляемая системой UNIX.

Поскольку внешнее резервное копирование с первичного сервера используется для инициализации вторичного сервера, это копирование должно производиться на нулевом уровне. Резервная копия должна содержать все фрагменты всех dbspaces, так чтобы с этой копией можно было выполнить полное физическое восстановление вторичного сервера. Следовательно, нельзя выполнять внешнее копирование нулевого уровня первичного сервера за несколько шагов с использованием разных пар команд onmode -c block/unblock. Вся область памяти должна быть скопирована в одной паре команд onmode -c block/unblock.

Для восстановления внешней резервной копии на вторичном сервере сначала необходимо физически восстановить область памяти, используемую для выбранного внешнего метода. Для подготовки вторичного сервера к последовательному логическому восстановлению используйте команду onbar -r -p -e или ontape -p -e. Эти команды на самом деле не восстанавливают какие-либо данные, поскольку данные восстанавливаются внешним методом. Эти команды запускают серверные процессы и переводят сервер в режим физического восстановления. На данном этапе сервер находится в том же самом состоянии, как будто он был физически восстановлен обычным методом (например, onbar -r -p или ontape -p).

В этом состоянии вторичный сервер (пока стандартный сервер) теперь может быть переделан во вторичный сервер при помощи команды onmode -d secondary .... После этой команды вторичный сервер начинает выполнять логическое восстановление так же, как если бы физическое восстановление происходило обычным методом. С этого момента и далее нет отличий в поведении.

Пошаговая процедура

Для установки HDR с использованием EBR:

1. На первичном сервере создайте внешнюю резервную копию. Внешняя резервная копия всегда эквивалентна резервной копии нулевого уровня;
2. На первичном сервере используйте команду onmode -d для установки типа сервера в "первичный" и для указания имени связанного с ним вторичного сервера базы данных;
3. На вторичном сервере выполните физическое восстановление из внешней резервной копии, созданной на первом шаге. Не делайте логическое восстановление;
4. На вторичном сервере используйте команду onmode -d для установки типа сервера во "вторичный" и для указания связанного с ним первичного сервера;
5. Если записи логического журнала, записанные на первичном сервере базы данных, больше не находятся на диске первичного сервера, вторичный сервер базы данных запросит вас восстановить эти файлы с устройства хранения. После восстановления всех файлов логического журнала с ленты логическое восстановление продолжает использовать файлы логического журнала, находящиеся на диске первичного сервера.

На рисунке 1 отображены следующие шаги (шаги, выполняемые пользователем, отмечены символом *):

На первичном сервере:

1. * Выполнить onmode -c block для начала внешнего резервного копирования.
2. * Выполнить команду внешнего резервного копирования.
3. * Выполнить onmode -c unblock для завершения внешнего резервного копирования.
4. * Выполнить onmode -d primary secondary для установки сервера HDR первичным.

На вторичном сервере:

5. * Выполнить команду внешнего восстановления.
6. * Выполнить onbar -r -e- p для запуска ON-Bar, или ontape -p -e для запуска ontape.
7. ON-Bar (или ontape) запускает вторичный сервер HDR.
8. Вторичный сервер обращается к дискам и проверяет их, затем переходит в фазу логического восстановления.
9. * Выполнить onmode -d secondary primary для установки сервера HDR вторичным.
10. Вторичный сервер соединяется с первичным.
11. Просматривается текущий логический журнал.

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

Одна из прогрессивных технологий хранения, которая может быть использована с помощью EBR, основывается на концепции применения зеркалирования дисков хранения на аппаратном уровне или на уровне операционной системы для создания копии всех частей базы данных, используемых Informix Dynamic Server. Зеркалирование полезно не только как резервирование в "горячем" режиме во время нормального функционирования, но также и для внешнего резервирования. Зеркалирование дисков может быть разделено (прекращено) на аппаратном уровне или уровне операционной системы. Во время такого разделения зеркалирования данные на дисках должны быть непротиворечивы, что гарантирует применение команды onmode -c block. Обычно разделение зеркалирования занимает от пары секунд до одной-двух минут, не больше. После завершения разделения Informix Dynamic Server может продолжить нормальное функционирование без зеркалирования после выполнения команды onmode -c unblock.

Следовательно, с точки зрения сервера Informix Dynamic Server и всех его активных пользователей, полная операция резервирования заканчивается во время разделения зеркалирования. Этот процесс работает как для объемов данных в несколько гигабайт, так и для терабайт. Позднее, в то время как Informix Dynamic Server продолжает нормальное функционирование, данные из зеркальных дисков могут быть скопированы в другое место (например, для установки HDR) или на более медленные устройства хранения, например, магнитные ленты. Этот процесс обычно занимает значительное время, но, поскольку он не влияет на нормальную работу Informix Dynamic Server, он не является критической по времени операцией.

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

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

В начало

Резервирование и восстановление с stdio при помощи программы ontape

Программа ontape может записывать данные на stdout (во время резервного копирования) и читать данные с stdin (во время восстановления). Это настраивается при помощи существующих параметров ontape в файле ONCONFIG.

Преимущества

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

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

Настройка

Вы можете настроить ontape на чтение данных с stdin или записи данных на stdout при помощи следующих конфигурационных параметров для ontape (указанных в файле ONCONFIG):

• TAPEDEV: Назначение, в которое программа ontape производит запись данных во время резервного копирования, и источник, из которого ontape читает данные во время восстановления. Для stdout используется значение STDIO.
• TAPEBLK: Размер блока, который использует ontape при записи или чтении из TAPEDEV. Для STDIO размер блока не используется при записи на stdout или чтения с stdin, поскольку они не имеют размера блока. Однако это значение все равно используется для передачи данных от сервера к ontape (архивирование) или от ontape к серверу (восстановление). Следовательно, корректное значение необходимо.
• TAPESIZE: Объем устройства резервного хранения настраивается в TAPEDEV. Для STDIO этот параметр несущественен, поскольку границы по объему для stdout или stdin не существует. Считается, что их емкость бесконечна.

Резервное копирование всех областей памяти

Для создания резервной копии всех областей памяти экземпляра сервера используется команда ontape -s [ -L level ], где level равен 0, 1, или 2. При использовании ontape невозможно отдельно выполнить резервное копирование каждой области памяти. Кроме того, обычно временные области памяти не резервируются.

Если TAPEDEV настроен на STDIO, резервные данные копируются непосредственно на stdout, следовательно, поток данных нужно перенаправить, в противном случае данные будут отображаться на экране.

Если при использовании программы ontape во время копирования на stdout возникает ошибка, резервное копирование прерывается, и уже записанные данные использовать для восстановления нельзя. Поэтому проверьте, имеется ли достаточно свободного места для копирования данных перед запуском ontape. Например, если выходные данные программы ontape перенаправляются в файл, файловая система должна иметь достаточно свободного места для полной резервной копии. В качестве оценки ожидаемого объема данных используйте результат выполнения команды onstat –d, отображающей размеры областей памяти. Из раздела Chunk отображаемой информации вычтите значение свободных столбцов для получения хорошей оценки объема данных при выполнении резервного копирования на нулевом уровне. Размер резервного копирования первого или второго уровней оценить труднее, поскольку будут резервироваться только необходимые страницы (измененные после последнего резервирования более низкого уровня). Максимальный размер при резервировании на первом и втором уровне будет таким же, как и при резервировании на нулевом уровне.

Примеры:

Следующая команда создает архив нулевого уровня всех областей памяти:

ontape -s -L 0 > /home/level_0_archive

Stdout в команде ontape перенаправляется в файл level_0_archive, расположенный в каталоге /home. Файл должен существовать, либо выполняющий команду пользователь должен быть способен его создать. Если файл уже существует, пользователь должен иметь права на запись в него.

Эта команда работает аналогично тому, когда параметр равен TAPEDEV /home/level_0_archive, только в данном случае он рассматривается как устройство на магнитной ленте, то есть, при записи файла или чтении из него будут действовать TAPEBLK и TAPESIZE.

При использовании stdout TAPESIZE не применяется. Следовательно, программа ontape не будет запрашивать новое устройство после вывода объема данных, указанного в TAPESIZE. OS направляет поток данных в файл. Если в OS возникает ошибка (например, заполнение файловой системы), ontape прекратит свою работу после получения из OS информации об ошибке.

Следующая команда выполнит резервное копирование первого уровня (предположим, что резервное копирование нулевого уровня уже было выполнено):

ontape -s -L 1 | compress -c > /home/compressed/level_1_archive

Stdout в команде ontape перенаправляется в канал. Системная программа compress читает данные из этого канала, предоставленные командой ontape, и сжимает их перед записью в свое собственное устройство stdout. Затем данные перенаправляются в файл level_1_archive, расположенный в каталоге /home/compressed. Опять же, файл должен существовать и быть доступным по записи для данного пользователя, либо пользователь должен иметь права для его создания.

Канал в этой команде дает возможность программе ontape посылать данные прямо в программу compress (через системную память, используемую OS для реализации канала). Не требуется промежуточный временный файл (вместе со связанным с ним дисковым доступом). Только сжатые данные в конечном итоге записываются в файловую систему (на диск).

Что касается TAPEBLK и TAPESIZE, действуют те же правила, что и в предыдущем примере.

На следующем рисунке показано, как программа ontape выполняет резервное копирование в stdout:

Резервное копирование файлов логических журналов

Для резервного копирования файлов логических журналов существует две основные команды ontape: ontape -a (автоматическое резервирование журнала) и ontape -c (последовательное резервирование журнала). Новая функциональная возможность не поддерживает резервного копирования журналов, а только резервное копирование областей хранения. Следовательно, STDIO как значение конфигурационного параметра LTAPEDEV не имеет большого смысла. Если LTAPEDEV настроен на STDIO, команда ontape ожидает файл STDIO в локальном рабочем каталоге (из которого была запущена ontape). После подтверждения ontape запишет резервные данные логического журнала в этот файл с именем STDIO.

Восстановление

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

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

На следующем рисунке показано, как программа ontape выполняет восстановление с stdin:

Нормальный процесс восстановления (без настройки STDIO) значительно более интерактивен, чем резервное копирование. Если указан STDIO, программа ontape не может быть настолько же интерактивной, поскольку stdin больше не подключен к клавиатуре пользователя, что приводит к нескольким отличиям от нормальной операции:

• Восстановление журнала:

  Нормальное восстановление запрашивает пользователя о восстановлении логического журнала. Пользователь может ответить "да" или "нет". При использовании STDIO такой запрос не происходит и восстановление логического журнала не выполняется.

  Восстановление журнала может быть выполнено перед восстановлением при использовании нового параметра ontape -S и с настройкой нужных файлов и устройств в LTAPEDEV. После восстановления журналов может быть использована новая функция восстановления.

• Информация о восстановлении:

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

• Восстановление архивов уровня 1 или 2:

  Во время стандартного восстановления после восстановления из архива нулевого уровня программа ontape отображает пользователю запрос на восстановление из архивов 1-го и 2-го уровня. При восстановлении с stdin этот запрос пропускается. Вместо этого входящий поток сканируется на наличие дополнительных данных. Если найдены данные архива первого уровня, они восстанавливаются. Если эти данные были определены несоответствующими (то есть, не являются данными резервной копии) программа ontape остановится и завершит работу. Если это происходит, тогда, вероятнее всего, восстановление бесполезно.

• Только физическое восстановление:

  Команда ontape -p используется для выполнения только физического восстановления. Если для TAPEDEV указан STDIO, ontape будет читать данные областей хранения для восстановления с stdin и записывать их в соответствующее место на диске.

  Примеры:

  cat /home/level_0_archive | ontape -p

  
  

  uncompress -c /home/compressed/level_0_archive | ontape -p

  
  

  cat /home/level_0_archive /home/level_1_archive | ontape -p

  
  

  Последняя команда будет восстанавливать резервную копию 0-го уровня, а затем – 1-го уровня (предположим, что они будут извлекаться таким же способом, что и из копии 0-го уровня).

• Комбинирование физического и логического восстановления:

  При стандартном восстановлении команда ontape -r используется для физического и логического восстановления за один проход. Поскольку новая функциональная возможность восстановления не поддерживает логическое восстановление, оно будет пропущено при использовании stdin. Отличием от команды для физического восстановления ontape -p является то, что сервер будет переведен в однопользовательский режим. Для физического и логического восстановления выполните две отдельные команды: ontape -p с использованием STDIO, которая следует за командой ontape -l, использующей нормальный режим.

  Для физического восстановления с STDIO все необходимые данные должны быть частью входного потока для ontape, и эти данные должны быть расположены в правильном порядке. Это означает, что первыми в потоке должны располагаться данные архива уровня 0. После них должны располагаться необязательные данные архивов уровня 1 и/или уровня 2. Логическое восстановление пропускается, и сервер переходит в однопользовательский режим.

  Пример:

  cat /home/level_0_archive [ /home/level_1_archive ] | ontape -r

  
  

Комбинирование резервного копирования и восстановления

Огромнейшим преимуществом данной возможности является использование ее для одновременного выполнения резервного копирования и восстановления: например, для клонирования сервера или для установки HDR. Если единственной целью резервного копирования является дублирование сервера, используйте новый параметр -F программы ontape. Резервное копирование становится скрытым от регулярного запланированного резервирования и не влияет на инкрементные архивы уровня 1 и уровня 2. Дополнительная информация находится в следующем разделе.

Пример:

ontape -s -L 0 -F | ( rsh secondary hostname ontape -p )

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

Новый параметр командной строки -F программы ontape

Параметр командной строки –F является новым для ontape. Он был введен для поддержки конфигурации STDIO. Если STDIO не используется, -F игнорируется.

Сервер базы данных записывает информацию о резервных копированиях внутренне, главным образом в зарезервированных корневых страницах (см. результат работы команды oncheck -pr). Эта информация используется сервером для определения корректности конкретного запроса на выполнение резервного копирования (например, может ли быть выполнено резервное копирование уровня 1, завершено ли резервное копирование уровня 0) и для определения данных, которые нужно архивировать (например, для архивирования уровня 1 нужны данные, изменившиеся только после последнего архивирования уровня 0). Эта информация является критичной для корректного резервного копирования данных, для того чтобы их можно было восстановить в целостную систему.

Однако при использовании конфигурации STDIO могут существовать ситуации, когда резервное копирование было выполнено, но архив не является постоянным и, следовательно, не восстанавливается. При комбинировании резервного копирования и восстановления в одной операции, как в приведенном выше примере, выполняется резервное копирование, но восстановление не может быть выполнено впоследствии, поскольку операция выполнялась через канал для немедленного восстановления на другой системе. Такой архив не сохраняется на устройстве постоянного хранения аналогичном магнитной ленте. Выполнение такой комбинированной команды backup-restore между нормальными запланированными операциями резервирования (включая уровень 0, уровень 1 и, возможно, уровень 2) нарушает логику плана. Следующее резервирование уровня 1 после комбинированной команды backup-restore будет пытаться использовать временный архив в качестве базового архива уровня 0 вместо последнего реального архива уровня 0. Возникнет промежуток пропущенных данных между последним реальным резервированием нулевого уровня и комбинированной командой backup-restore.

Для решения этой проблемы используйте параметр -F. Результатом действия параметра -F совместно с конфигурацией STDIO является то, что информация о резервном копировании не будет записываться внутри сервера в корневые резервные страницы. Следовательно, это архивирование не будет влиять на нормальный план создания резервных копий, и последующие резервные копирования уровня 1 и уровня 2 будут сохранять корректные данные относительно реального архива уровня 0.

Значение и эффект параметра -F программы ontape отличается от значения параметра -F программы ON-Bar. Их нельзя смешивать.

В начало

Заключение

На первый взгляд две эти новые функциональные возможности резервного копирования и восстановления в IBM Informix Dynamic Server, Version 10.0 предназначены не более чем для облегчения использования программ ON-Bar и ontape. Но при более пристальном рассмотрении обнаруживается, что эти функции предлагают много новых, улучшенных и быстрых способов управления данными для резервного копирования и восстановления, привлекая множество системных функций или программ, которые не использовались с Informix Dynamic Server. Это дает этим двум функциям довольно мощный потенциал не только в этой новой версией Informix Dynamic Server, но и в будущих версиях с использованием новых внешних методов и программ.

Ресурсы

• Оригинал статьи New backup and restore features in IBM Informix Dynamic Server, Version 10.0.
  
  
• Примите участие в форуме.
  
  
• " Руководство по резервному копированию и восстановлению в IBM Informix " доступно на Web-странице Informix Library для версии 10.0 и Informix Information Center.
  
  
• Центр технических ресурсов developerWorks Informix: Найдите дополнительные ресурсы для разработчиков Informix.
  
  

Об авторе

Оценить эту статью

Комментарии

В начало

Содержание

• Введение
• Установка внешнего резервного копирования и восстановления для HDR
• Резервирование и восстановление с stdio при помощи программы ontape
• Заключение
• Ресурсы
• Об авторе
• Комментарии