Содержание


Управление кластерами Vertica в среде SaaS

Часть 2. Создание сценариев резервного копирования для кластеров Vertica

Comments

Серия контента:

Этот контент является частью # из серии # статей: Управление кластерами Vertica в среде SaaS

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Управление кластерами Vertica в среде SaaS

Следите за выходом новых статей этой серии.

NIOD — это продукт IBM® Unica® в комплексе Enterprise Marketing Management (EMM), предназначенный для клиентов, использующих среду SaaS на базе кластеров Hewlett-Packard® Vertica. Для создания сценария резервного копирования кластеров Vertica необходимо определить узлы исходного и целевого кластеров. Предполагается, что оба кластера включают три узла. Резервное копирование базы данных Vertica может выполняться на один или несколько хостов резервного копирования. Необходимо обеспечить SSH-авторизацию пользователя dbadmin без пароля для всех узлов исходного кластера и кластера резервного копирования. Созданные файл конфигурации и сценарий резервного копирования могут выполняться с использованием задания cron в соответствии со стратегией резервного копирования. Далее подробно описываются эти действия.

Определение узлов исходного кластера и кластера резервного копирования Vertica

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

Таблица 1. Сведения об исходном и целевом кластерах Vertica для резервного копирования
Тип кластераИмя узла кластераIP-адресИмя БДПользователь
Исходныйsource01.niod.unica.net10.10.10.1niunicl05dbadmin
source02.niod.unica.net10.10.10.2niunicl05dbadmin
source03.niod.unica.net10.10.10.3niunicl05dbadmin
Целевойbackup01.niod.unica.net10.10.10.4dbadmin
backup02.niod.unica.net10.10.10.5dbadmin
backup03.niod.unica.net10.10.10.6dbadmin

Настройка файла hosts

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

[root@source01 /]# vi /etc/hosts

Добавьте в файл hosts следующую запись:

#Vertica HB
10.10.10.1     source01.niod.unica.net
10.10.10.2     source02.niod.unica.net
10.10.10.3     source03.niod.unica.net

Примечание: повторите эти действия на двух других узлов, source02 и source03.

[root@backup01 /]# vi /etc/hosts

Добавьте в файл hosts следующую запись:

#Vertica HB
10.10.10.4     backup01.niod.unica.net
10.10.10.5     backup02.niod.unica.net
10.10.10.6     backup03.niod.unica.net

Примечание: повторите эти действия для двух других узлов, backup02 и backup03.

Проверка SSH-авторизации без пароля

Предположим, что исходный и целевой кластеры для резервного копирования включают три узла. Сценарий резервного копирования запускается с любого узла исходного кластера Vertica. У пользователя dbadmin должна быть возможность проходить SSH-авторизацию без пароля на всех узлах каждого из кластеров.

Проверка SSH-авторизации без пароля на каждом узле кластера

Проверьте возможность SSH-авторизации без пароля от узла source01 на узлы source02, source03, source01 и обратно. Выполните такую проверку от узла backup01 к узлам backup02, backup03, backup01 и обратно.

Например:

[dbadmin@source01 ~]$ ssh source02.niod.unica.net
[dbadmin@source02 ~]$ ssh source03.niod.unica.net
[dbadmin@source03 ~]$ ssh source01.niod.unica.net

Примечание: повторите такую проверку для узлов backup01, backup02 и backup03.

Проверка SSH-авторизации без пароля между узлами разных кластеров

source01 => backup01, backup02 и backup03 и обратно
source02 => backup01, backup02 и backup03 и обратно
source03 => backup01, backup02 и backup03 и обратно

Например:

[dbadmin@source01 ~]$ ssh backup01.niod.unica.net
[dbadmin@backup01 ~]$ ssh source01.niod.unica.net
[dbadmin@source01 ~]$ ssh backup02.niod.unica.net
[dbadmin@backup02 ~]$ ssh source01.niod.unica.net
[dbadmin@source01 ~]$ ssh backup03.niod.unica.net
[dbadmin@backup03 ~]$ ssh source01.niod.unica.net

Определение сведений о базе данных Vertica

Чтобы идентифицировать базу данных Vertica, для которой требуется выполнить резервное копирование, используйте инструментарий Vertica Admintools, запустив его с любого узла исходного кластера:

  • Авторизуйтесь на узле source01.niod.unica.net как пользователь dbadmin.
  • Запустите Admintools:
    [dbadmin@source01 bin]$ /opt/vertica/bin/admintools
  • Откроется окно Main Menu.
Рисунок 1. Окно Main Menu
The Main Menu window.
The Main Menu window.
  • Выберите View Database Cluster State
  • Нажмите OK.
Рисунок 2. Просмотр состояния кластера базы данных
The View Database window.
The View Database window.

Выбор пункта View Database Cluster State выводит имя базы данных Vertica и ее состояние для всех узлов. Убедитесь в том, что для базы данных указано состояние UP. Можно посмотреть более подробную информацию о базе данных:

  • В окне Main Menu выберите пункт Configuration Menu
  • Нажмите OK.
  • Выберите View Database
  • Нажмите OK.

Теперь можно выйти из Admintools.

Идентификация имени узла базы данных

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

source01:/opt/vertica/config $ /opt/vertica/bin/admintools -t node_map -d niunicl05
DATABASE   | NODENAME               | HOSTNAME
--------------------------------------------------------
niunicl05  | v_unicl05_node0001   | 10.10.10.1
niunicl05  | v_unicl05_node0002   | 10.10.10.2
niunicl05  | v_unicl05_node0003   | 10.10.10.3

Примечание: имя после флага -d — это имя базы данных.

Создание каталога резервного копирования на целевом хосте

Исходя из размера базы данных Vertica необходимо на соответствующих узлах целевого кластера создать каталоги резервного копирования. В данном примере на каждом хосте резервного копирования создаются каталоги /local/backup/niunicl05. Например:

[root@backup01]# mkdir /local/backup/niunicl05
[root@backup01]# chown -R dbadmin:dbadmin /local/backup/niunicl05

Примечание: повторите эти действия на двух других узлах целевого кластера резервного копирования, backup02 и backup03.

Создание файла конфигурации

В данном примере используется кластер из трех узлов. Сценарий резервного копирования может запускаться с любого узла исходного кластера Vertica. В данном случае узел source01.niod.unica.net используется как административный хост для создания и выполнения файла конфигурации и сценария резервного копирования. Файл конфигурации vbr.ini должен содержать dbName, username, dbNode, backupHost, BackupDir и другие настройки.

Создайте файл конфигурации на исходном узле в каталоге по умолчанию /opt/vertica/config. Например:

Имя файла 	: vbr.ini
Путь	:  /opt/vertica/config/vbr.ini 

Пример содержимого файла vbr.ini

[Misc]
snapshotName = fullbackup 
tempDir = /tmp 

[Database]
dbName = niunicl05 
dbUser = dbadmin 
dbPassword = xxxxx 

[Transmission] 
checksum = True
port_rsync = 50000 
bwlimit = 0 

[Mapping0] 
dbNode = v_unicl05_node0001 
backupHost = backup01.niod.unica.net 
backupDir = /local/backup/niunicl05 

[Mapping1] 
dbNode = v_unicl05_node0002 
backupHost = backup02.niod.unica.net 
backupDir = /local/backup/niunicl05 

[Mapping2] 
dbNode = v_unicl05_node0003 
backupHost = backup03.niod.unica.net
backupDir = /local/backup/niunicl05

где:

  • dbNode — имя каждого узла исходного кластера
  • backupHost — имя узла целевого кластера резервного копирования
  • backupDir — каталог резервного копирования на узле целевого кластера
  • dbName — имя исходной базы данных, например niunicl05
  • dbUser — администратор, один и тот же в исходном и целевом кластерах резервного копирования
  • dbPassword — пароль для исходной базы данных.

Создание сценария резервного копирования и его выполнение с использованием задания cron

После создания файла конфигурации необходимо настроить сценарий резервного копирования run_full_backup.sh. Этот сценарий, содержащий команды резервного копирования, выполняется утилитой vbr.py с использованием файла конфигурации vbr.ini. Задание cron для выполнения резервного копирования необходимо настроить в соответствии со стратегией резервного копирования.

Изменение значения параметра SnapShotRetentionTime

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

Error msg: Cannot acquire read lock on .ctlg file, vertica server might be locking it.

По умолчанию значение SnapShotRetentionTime равно 3600 (один час). Значение SnapShotRetentionTime рекомендуется увеличить. Далее описывается, как увеличить это значение до одного дня.

Используйте Vertica Admintools для изменения значения параметра SnapShotRetentionTime, выполнив следующие действия:

  • Авторизуйтесь на узле source01.niod.unica.net как пользователь dbadmin.
  • Запустите Vertica Admintools:
    [dbadmin@source01 bin]$ /opt/vertica/bin/admintools
  • Откроется окно Main Menu.
  • Выберите Connect to Database.
  • Нажмите OK.
  • Введите пароль для этой базы данных.
  • Получите текущее значение параметра SnapShotRetentionTime:
    niunicl05=> select get_config_parameter('SnapshotRetentionTime');
     get_config_parameter 
    ---------------------- 
     3600
    (1 row)
  • Измените значение параметра SnapShotRetentionTime:
    niunicl05=> select set_config_parameter('SnapshotRetentionTime', 86400);
        set_config_parameter
    ---------------------------- 
     Parameter set successfully
  • Проверьте внесение изменений:
    niunicl05=> select get_config_parameter('SnapshotRetentionTime');
     get_config_parameter
    ----------------------
    86400
  • Выйдите из режима командной строки:
    niunicl05=>\q
  • Выйдите из Admintools.

Создание сценария резервного копирования

Теперь необходимо создать сценарий резервного копирования run_full_backup.sh с командами резервного копирования, выполняемый утилитой Vertica vbr.py с использованием файла конфигурации vbr.ini.

Примечание: Приведенный далее пример сценария резервного копирования содержит некоторые условия. Сначала сценарий проверяет, не выполняется ли какая-либо операция резервного копирования. Если нет, то запускается резервное копирование. Сценарий записывает в файл журнала full_backup.log данные о запуске и завершении резервного копирования с отметками времени. Сценарий также проверяет размер файла журнала и сжимает его. В случае неудачного резервного копирования отправляется предупреждение по электронной почте.

Резервное копирование запускается с узла source01.niod.unica.netvia пользователем dbadmin. Сценарий резервного копирования создается на этом хосте в каталоге /home/dbadmin.

[dbadmin@source01 ~]$ pwd 
/home/dbadmin             
dbadmin@source01 ~]$ vi run_full_backup.sh

Пример содержимого сценария резервного копирования

IS_RUNNING=`ps -ef|grep vbr.py |wc -l` 
#If backup's not running, IS_RUNNING will be set to 1 
if [ $IS_RUNNING -gt 1 ]; then 
	echo "Backup already running on  `hostname` on `date`"  >> /home/dbadmin/full_backup.log 
	exit 
fi 
echo "Starting backup on `hostname` on `date`" >> /home/dbadmin/full_backup.log 
/opt/vertica/bin/vbr.py --task backup --config-file=/opt/vertica/config/vbr.ini >> /home/dbadmin/full_backup.log
RETVAL=$? 
# If status is 0, backup ran successfully 
if [ $RETVAL -ne 0 ] 
then 
        echo "Backup failed on `hostname`" | mailx -s "Vertica backup failed" amolbarsagade@in.ibm.com 
fi 
echo "End of backup run on `hostname` on `date`" >> /home/dbadmin/full_backup.log 
filesize=`stat -c %s /home/dbadmin/full_backup.log` 
if [ $filesize -gt 2097152 ]; then 
	rm -rf /home/dbadmin/full_backup.log.old.gz 
	mv /home/dbadmin/full_backup.log /home/dbadmin/full_backup.log.old 
	gzip /home/dbadmin/full_backup.log.old 
fi

Сохраните этот файл и задайте для него права доступа 755. Например:
$ chmod 755 run_full_backup.sh

Создание задания cron для выполнения сценария резервного копирования

Новое задание cron mycron.txt создается в каталоге /home/dbadmin и планируется в соответствии со стратегией резервного копирования.

  • Авторизуйтесь как пользователь dbadmin.
  • Проверьте наличие существующих заданий cron для пользователя dbadmin.
    [dbadmin@source01 ~]$ crontab -l
    no crontab for dbadmin
  • Создайте новое задание cron.
    [dbadmin@source01 ~]$ vi mycron.txt
  • Добавьте расписание резервного копирования для выполнения этого задания cron в соответствии с вашей стратегией резервного копирования. Например:
    40 7 * * Fri,Tue /home/dbadmin/run_full_backup.sh
  • Определите и проверьте задание cron.
    [dbadmin@source01 ~]$ crontab mycron.txt 
    [dbadmin@source01 ~]$ crontab -l 
    40 7 * * Fri,Tue /home/dbadmin/run_full_backup.sh

Примечание: В данном случае для задания cron задано выполнение в 7:40 по пятницам и вторникам. В соответствии с этим графиком задание cron выполняет команды из файла run_full_backup.sh. Задание создает каталог журнала /home/dbadmin/full_backup.log и отслеживает выполнение резервного копирования.

Резервное копирование без задания cron

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

nohup /opt/vertica/bin/vbr.py --task backup --config-file=/opt/vertica/config/vbr.ini > /home/dbadmin/full_backup.log

Мониторинг резервного копирования

После запуска резервного копирования с использованием сценария резервного копирования можно отслеживать этот процесс разными способами.

Мониторинг процесса vbr.py

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

source01:/home/dbadmin $ ps -ef | grep vbr.py

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

Мониторинг файла журнала full_backup.log

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

        source01:/home/dbadmin $ vi full_backup.log

Сведения из этого файла:

Starting backup on source01.niod.unica.net on Fri Apr 17 07:40:04 GMT 2015
All child processes terminated successfully.
Committing changes on all backup sites...
backup done!
End of backup run on source01.niod.unica.net on Fri Apr 17 23:56:02 GMT 2015

Мониторинг каталогов на хостах резервного копирования

Вы также можете отслеживать каталоги резервного копирования, созданные на хостах резервного копирования, такие как /local/backup/niunicl05. Например:

backup01:/local/backup/niunicl05 $ ls -la
drwxrwxr-x 4 dbadmin dbadmin 4096 Apr 17 09:33 v_unicl05_node0001

backup02:/local/backup/niunicl05 $ ls -la
drwxrwxr-x 4 dbadmin dbadmin 4096 Apr 17 09:33 v_unicl05_node0002

backup03:/local/backup/niunicl05 $ ls -la
drwxrwxr-x 4 dbadmin dbadmin 4096 Apr 17 09:33 v_unicl05_node0003

Заключение

Статья включает пошаговые инструкции по конфигурированию и выполнению сценариев резервного копирования для кластера базы данных Vertica, помогая понять значение файла конфигурации и сценария резервного копирования. Сценарий резервного копирования может выполняться по расписанию с использованием задания cron, и можно применить некоторые условия для мониторинга процесса резервного копирования. Пользователи IBM NIOD в средах SaaS получают преимущества, используя этот новый сценарий для управления резервным копированием кластеров базы данных Vertica.

Благодарности

Автор выражает благодарность Марьяне Ивкович (Marjana Ivkovic, mivkovic@us.ibm.com), руководителю группы архитекторов приложений EMM SaaS Ops, за поддержку и ценные технические рекомендации, оказавшие помощь в подготовке этой статьи.


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=1032697
ArticleTitle=Управление кластерами Vertica в среде SaaS: Часть 2. Создание сценариев резервного копирования для кластеров Vertica
publish-date=06012016