Обслуживание системы

Резервное копирование программного кода и настроек системы

Внедрение АСР “Pyzzle.ISP” осуществляемое разработчиками подразумевает развертывание тестовой и рабочей инсталляции системы. Синхронизация программного кода осуществляется использование системы контроля версий Subversion™ (SVN).
Поскольку программный код тестовой инсталляции и код установленный на всех рабочих серверах полностью идентичен, то svn репозиторий так же выполнят функции резервной копии. Резервным копированием репозитория занимается разработчик системы.
Резервное копирование других рабочих файлов системы (например “сырых” файлов netflow, rrd-файлы с информацией о загрузке портов сетевых устройств, файлы различных документов созданные в ходе работы информационной системы) должно осуществляется различными средствами операционной системы. При отсутствии этих файлов работоспособность основных компонентов системы не будет нарушена.

Note

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

Резервное копирование базы данных

База данных информационной системы состоит из таблиц, которые можно разделить на два типа: постоянно изменяемые таблицы (например реквизиты абонентов, список оборудования), а так же таблицы данные в которые только добавляются (история платежей, различные логи и т.п.) Размер постоянно изменяемых таблиц достаточно мал, и резервное копирование этих таблиц может осуществляться в короткое время. Таблицы, данные в которые постоянно добавляются, занимают много места, но система может функционировать и без данных в этих таблицах. Встроенная в систему команда резевного копирования, позволяет гибко снимать дамп базы данных учитывая характер данных в таблицах, что позволяет делать backup достаточно часто (например каждый час) и при этом при развертывании базы из backup можно сначала быстро развернуть основные таблицы, запустить систему и потом дозагрузить оставшиеся данные уже на работающую систему.
Используя CLI-интерфейс можно осуществлять процедуру резервного копирования базы данных, а так же процедуру восстановления базы данных из резервной копии. Для этого в CLI-интерфейсе используется команда mysql_backup.
mysql_backup [--verbose] [--no-rmdir]
             [--ignore-low-priority]
             [--low-from-today] [--low-before-today] [--low-from-monday] [--low-before-monday]
             [--low-where <where_condition>]
             [--low-no-drop-table]
             [--low-table-only] [--table-only <table1>[,table2....]]
             (import|export) <server_id> [/path/to/backup/dir]
Необязательный параметр –verbose включает режим подробного вывода информации о ходе процесса резервного копирования.
Параметр –bz2 позволяет сразу же архивировать получаемые файлы.
Параметр –no-rmdir позволяет не удалять текущее содержимое каталога куда делается backup, используется если backup делать в несколько запуском скрипта.
Параметр –ignore-low-priority позволяет исключить из процесса копирования/восстановления “низкоприоритетные таблицы”. Низкоприоритетные таблицы указываются в конфигурационном файле billing.cfg в параметре db_backup_low_priority_tables (название таблиц перечисляется через запятую). В качестве низкоприоритетных перечисляются таблицы не влияющие на нормальное функционирование основных компонентов информационной системы - различные таблицы с протоколами действий (user_log, device_log, operator_log, payment_history), а так же история потребления трафика. Исключив эти таблицы, размер резервной копии резко сокращается, что в свою очередь позволит производить быстрое восстановление работоспособности, при необходимости.
Параметр –low-where позволяет задать SQL условие для фильтрации низкоприоритетрых таблиц. Это может использовать для уменьшения размера копии.
Параметры –low-from-today и –low-before-today являются стандартными вариантам использования low-where и позволяют получить в дампе, или данные только за сегодня, или данные за прошлые дни без текущего. Эта пара параметром может быть использована для реализации инкрементальных бекапов и при настройке репликации.
Параметры –low-from-monday и –low-before-monday являются стандартными вариантам использования low-where и позволяют получить в дампе, или все данные за текущую неделю, или данные за прошлые недели. Эта пара параметром может быть использована для реализации инкрементальных бекапов.
Параметр –table-only позволяет получить дамп определенных таблиц базы данных
Параметр –low-table-only позволяет получить дамп только низкоприоритетных таблиц
Параметр –low-no-drop-table в дампе низкоприоритетных таблиц не будет команды DROP и CREATE TABLE. это позволяет снимать дамп таблицы в несколько итераций и потом склеивать при восстановлении.
Для получения резервной копии базы данных используется параметр export. В этом случае система создать отдельные файлы для каждой таблицы системы. параметр <database_id> указывает какую базу данных использовать в качестве источника. (Параметры подключения к базе данных описываются в конфигурационном файле billing.cfg).
Результат резервного копирование будет записан в каталог указанный в параметрах команды (<save_dir>). Если этот параметр не указан, то система запишет результат в каталог по умолчанию, который задается в конфигурационном файле billing.cfg, параметр db_backup_dir_X, где вместо X указывается server_id для которого задается этот параметр. Значение параметра обрабатывается как шаблон для функции strftime() и поэтому в нем можно использовать специальные последовательности начинающиеся со знака процента (%). Например для создания резервных копий в отдельном каталоге каждый час, можно использовать следующее выражение:
db_backupdir_1=/opt/billing/db_backup/%Y%m%d.%H
Это значит, что будут создаваться каталоги в своем имени содержащие дату и час выполнения резервного копирования. Подробнее про допустимые значения шаблона можно узнать из документации к функции strftime() или команде date операционной системы. Если указать только час и день недели, то более старые срезы будут затираться свежими.
Для восстановления базы данных используется команда mysql_backup import, в параметрах нужно указать сервер куда будет производиться восстановление, а так же каталог откуда брать исходную копию.
В ходе восстановления сначала будут восстановлены обычные таблицы, а потом таблицы указанные в списке низкоприоритетных. Если же указать параметр –ignore-low-priority, то низкоприоритетные не будут восстанавливаться. Их можно будет восстановить вручную позже, после проверки что основная функциональность информационной системы восстановлена.

Note

Если инсталляция информационной системы подразумевает наличие slave-mysql серверов, то резервное копирование рекомендуется делать на них, чтобы процесс копирования не влиял на работоспособность системы (При копирование данных запись в таблицы базы данных может быть заблокирована).

Note

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

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

Параметры –low_where –low-no-drop-table –table_only команды mysql_backup позволяют гибко получать дамп части базы данных. Это может быть полезно для развертывания репликации, когда нужно получить дамп базы, и при этом желательно минимизировать время блокировки рабочей базы данных.
В информационной системе большую часть данных занимает архив трафика, история операций и платежей абонентов, которым соответствуют таблицы базы данных iptraff_history, payment_history, user_log. Данные в этих таблицах только накапливаются и не меняются со временем и у таблиц есть поле date соответствующее времени добавления записи. Поэтому возможно сначала спокойно сделать дамп данных до определенного момента в недавнем прошлом, этот процесс может занять длительное время, и при желании его можно сделать по частям (например по месяцам или неделям). После этого дамп всей базы данных (при условии что из перечисленных таблиц будут браться только свежие записи) не займет много времени.
В результате получение дампа базы данных необходимого для создания репликации можно сделать следующим образом:
  1. Определиться с архивными таблицами, в большинстве случаев параметра –low-table-only достаточно

  2. Получить дамп архивных данных и сохранить в отдельном каталоге.

    mysql_backup --low-table-only --low-before-today export 1 /path/to/special/dir

    В результате в каталоге /path/to/special/dir будут файлы с дампом выбранных таблиц с данными до сегодняшнего дня.

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

  4. Снять дамп базы данных, так чтобы в архивных таблицах были только данные не попавшие в дамп на шаге 2.

    mysql_backup --low-atfer-today --low-no-drop-table export 1 /path/to/another/dir
    Параметр –low-no-drop-table указывает, что для архивных таблиц не нужно записывать команды пересоздания таблицы. Если его не указать, то в обоих дампах архивных таблиц будут конструкции DROP TABLE, и после восстановления дампа в таблице будут либо только старые данные, либо только свежие.
    Дамп базы данных нужно производить в другой каталог относительно шага 2, т.к. имена файлов с дампами таблиц будут одинаковыми, и поэтому если указать один и тот же каталог, то новый дамп затрет архивные данные.
  5. Если дамп снят успешно (в процессе снятия дампа в базе не делались операции изменения данных, то есть позиция бинарного лога не изменилась после снятия дампа), то файлов дампа и значения позиции достаточно для развертывания репликации.

  6. При развертывании репликации нужно сначала загрузить дампы с архивными данными (шаг 2), а потом загрузить остальные таблицы и свежие данные (шаг 4).

Пример резервного копирования по crontab

Инкрементальное резевное копирование каждый час и полный дамп раз в неделю.

# shell файл для снятия дампа лог-таблиц до начала недели, так чтобы сохранялся текущий и прошлый срез:
cat > /opt/billing/bin/base_backup.sh << EOF
#!/bin/sh
rm -rf /var/backup/last_week_old # удаляем дамп прошлой недели
mv /var/backup/cur_week_old /var/backup/last_week_old # переименовываем прошлый дам, как дамп прошлой недели
cd /opt/billing
./cli mysql_backup_new --bz2 --low-table-only --low-no-drop-table --low-before-monday export 2 /var/backup/cur_week_old/ # снимаем полный дамп
EOF

chmod +x /opt/billing/bin/base_backup.sh

# в crontab добавлям записи чтобы по поделеьникам в полночь делать полный дамп, и каждый час делать дам новых данных с начала недели.
2 0 * * 1 /opt/billing/bin/base_backup.sh
45 * * * * cd /opt/billing; ./cli mysql_backup_new --bz2 --low-from-monday export 2

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

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

Ротация log-файлов

Информационная система может вести достаточно подробные log-файлы с различной отладочно-информационными данными о своих действиях. Эти данные могут быть использованы для поиска и локализации некорректности в работе, поиска узких мест в производительности системы и т.п. В случае если включено достаточно подробное протоколирование, то размер лог-файлов может очень сильно вырасти (до нескольких гигабайт в месяц, в зависимости от объема совершаемых операций).
Во избежании переполнения дисков серверов необходимо настроить ротацию этих файлов и автоматическое удаление, через определенное время. Реализовать это можно используя механизмы предоставляемые операционной системой.
Пример настройки logrotate для ежедневной ротации log-файлов, файл /etc/logrotate.d/billing (расположение файла может зависеть от дистрибутива операционной системы)
/opt/billing/log/*.log {
  daily
  rotate 30
  compress
}
Приведенный пример означает что новые лог-файлы делаются ежедневно, хранятся файлы за последние 30 дней, и старые файлы архивируются. Подробнее о параметрах настройки можно узнать из документации к программе logrotate.