Восстановление БД биллинга из резервной копии.

Ключ
Эта строка удалена.
Это слово было удалено. Это слово было добавлено.
Эта строка добавлена.

Изменения (52)

просмотр истории страницы
...
Если UPS настроить в ближайшее время нет возможности воспользуйтесь статьёй [Как повысить выживаемость БД при сбоях питания|http://docs.carbonsoft.ru/68845609]

{info}Восстановление баз данных, повреждённых в результате нарушения любых рекомендаций CarbonSoft по реализации отказоустойчивости сервера (UPS, параметры монтирования раздела БД, повреждение в результате тех. работ и т.д.), не входит в компетенцию компании.{info}

{info}Восстановление баз данных, повреждённых в результате нарушения любых рекомендаций CarbonSoft по реализации отказоустойчивости сервера (UPS, параметры монтирования раздела БД, повреждение в результате тех. работ и т.д.), не входит в компетенцию компании и не включено SLA.{info}

h1. Возможные причины повреждения БД и остановки работы биллинга.

...
h1. Восстановление БД в web-интерфейсе

{tip}{*}Время выполнения инструкции*: 1-15 минут, в зависимости размера БД различия версий - после даты создания выбранной резервной копии производилось обновление сервера, дополнительно запускается скрипт обновления структуры БД{tip}

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

{tip}{*}Время выполнения инструкции*: 5-20 минут, в зависимости размера БД различия версий - после даты создания выбранной резервной копии производилось обновление сервера, дополнительно запускается скрипт обновления структуры БД{tip}

# Посмотрите список доступных резервных копий
...


# /app/asr_billing/service backup_restore backup_daily_2019[ OK ]2-50_asr_billing.tar.gz:
{code}
В зависимости от размера Вашей базы, восстановление может продолжаться 10-30 минут.

h1. Восстановление БД из консоли (вручную)
{tip}{*}Время выполнения инструкции*: 15-30 минут, в зависимости размера БД различия версий - после даты создания выбранной резервной копии производилось обновление сервера, дополнительно запускается скрипт обновления структуры БД{tip}

{color:#000000}{*}Резервное копирование и восстановление из бекапов при помощи WinSCP{*}{color}
...
h3. 1. Подготовка

{note}
Перед процедурой восстановления во избежание срабатывания автоматических тестов нужно отключить cron:
{code}
service crond stop
{code}
{note}
Восстанавливать БД можно из локального бэкапа (Дневной, Недельный, Месячный) либо из бэкапа, который копируется на FTP сервер. На FTP сервере бэкапы хранятся в архиве, поэтому после копирования на сервер с биллингом их нужно распаковать. Например имя бэкапа backup_daily_2016-30-21_02-53_asr_billing.tar.gz, тогда команда распаковки будет выглядеть вот так:
Перед выполнением операции, перейдите в директорию где лежит требуемая резервная копия. Допустим, требуется восстановить одну из локальных резервных копий. В таком, случае выполните следующую команду:
{code}cd /app/asr_billing/mnt/backup/{code}
Далее, извлеките резервную копию БД из архива:
Далее, на всякий случай, выполните эту команду чтобы удалить старые неудачные копии БД:
{code}
rm -f /mnt/backup/app/asr_billing/backup/billing.gdb.gbk
{code}
Потом извлеките резервную копию БД из архива:
{code}
tar xzf backup_daily_2016-30-21_02-53_asr_billing.tar.gz /app/asr_billing/var/backup_data/billing.gdb.gbk -O > /mnt/backup/app/asr_billing/backup/billing.gdb.gbk
{code}
{info}
Утилита *tar* напишет сообщение:
{code}tar: Удаляется начальный `/' из имен объектов{code}
Это нормально, переходите к следующему шагу инструкции.
{info}

h3. 2. Распаковка БД
...
gbak:Exiting before completion due to errors{code}{note}

{note}Также в процессе распаковки может возникнуть следующая ошибка:

{code}
[root@carbon (asr_billing) /]# gbk2gdb.sh /mnt/backup/billing.gdb.gbk /var/db/billing_prepare.gdb

gbak:opened file /mnt/backup/billing.gdb.gbk
gbak:transportable backup -- data in XDR format
gbak: ERROR:cannot attach to password database
gbak: ERROR:failed to create database /var/db/billing_prepare.gdb
gbak:Exiting before completion due to errors
{code}

Возможная причина - отсутствие системных файлов БД Firebird.
Скопируйте их из /app/asr_billing/skelet/
{code}
cp -R /app/asr_billing/skelet/var/lib/firebird/system/ /app/asr_billing/var/lib/firebird/
cp -R /app/asr_billing/skelet/var/lib/firebird/data/ /app/asr_billing/var/lib/firebird/
{code}
{note}


h3. 3. Остановка биллинга
{code}
...
{code}

На всякий случай, проверяем, что БД трафика {{buff_traf.gdb}} на месте . Если её нет, берём пустую. Если есть остановленная БД трафика, сохраняем её в той же папке для архива.
{code}
chroot /app/asr_billing/
[ -s /var/db/buff_traf.gdb.stop ] && ( mv /var/db/buff_traf.gdb.stop /var/db/buff_traf.gdb.stop.`date +%s`)
[ ! -s /var/db/buff_traf.gdb ] && ( yes | cp /skelet/var/db/buff_traf.gdb /var/db/buff_traf.gdb && chown firebird:firebird /var/db/buff_traf.gdb && chmod g+w /var/db/buff_traf.gdb )
exit
{code}

h3. 6. Обновление БД до версии биллинга

...
После восстановления всех финансовых операций, по-прежнему находясь в контейнере биллинга выполните следующую команду
{code}
python2.7 /usr/lib/python2.7/site-packages/python_tools/client_fix_scripts/fix_generators2.py
{code}

h3. 9. Запуск биллинга

Выходим из контейнера командой
{code}exit{code}
Запускаем биллинг
{code}
...
{code}
Если в течение двух запусков проверки значения не меняются - все в порядке.
Если растут значения "Критические ошибки в логе worker за последний час" - сразу обратитесь в техническую поддержку.
Если растут значения "Критические ошибки в логе worker за последний час" - сразу составьте обращение в портале [HelpDesk|https://helpdesk.carbonsoft.ru/login.php].
Если растут значения "Ошибки в логе traf-reporter за последний час" - выполните команды
{code}
...
{code}

h1. Восстановление демонстрационной или пустой БД
{tip}{*}Время выполнения инструкции*: 1-10 минут{tip}

*1.* # Останавливаем биллинг
{code}
/app/asr_billing/service stop
{code}
{info:title=При необходимости сохраняем текущую БД}
{code}mv /app/asr_billing/var/db/billing.gdb.stop /root/billing.gdb.stop-`date +%Y-%m-%d_%H%M`{code}
{info}
*2.* При необходимости сохраняем текущую БД
# Копируем в рабочий каталог демо БД
{code}
mv /app/asr_billing/var/db/billing.gdb.stop /root/
yes | cp -p /app/asr_billing/skelet/var/db/billing.gdb /app/asr_billing/var/db/billing.gdb.stop
{code}
# Уточняем текущее состояние биллинга для сервисного скрипта
{code}echo 'stop OK' >/app/asr_billing/var/lib/app.state{code}
# Запускаем биллинг
{code}
/app/asr_billing/service start
{code}

*3.* Копируем в рабочий каталог:
*a)* демо БД
h1. Восстановление пустой БД
{excerpt}
{tip}{*}Время выполнения инструкции*: 1-10 минут{tip}

# Останавливаем биллинг
{code}
yes | cp -p /app/asr_billing/skelet/var/db/billing.gdb /app/asr_billing/var/db/billing.gdb.stop
/app/asr_billing/service stop
{code}
*b)* Или пустую БД
{info:title=При необходимости сохраняем текущую БД}
{code}mv /app/asr_billing/var/db/billing.gdb.stop /root/billing.gdb.stop-`date +%Y-%m-%d_%H%M`{code}
{info}
# Копируем в рабочий каталог пустую БД
{code}
yes | cp -p /app/asr_billing/skelet/var/db/billing_system.gdb /app/asr_billing/var/db/billing.gdb.stop
{code}
# А также обязательно пустую БД трафика
{code}
yes | cp -p /app/asr_billing/skelet/var/db/buff_traf.gdb /app/asr_billing/var/db/buff_traf.gdb.stop
{code}


# Уточняем текущее состояние биллинга для сервисного скрипта
{code}echo 'stop OK' >/app/asr_billing/var/lib/app.state{code}
*4.* # Запускаем биллинг
{code}
/app/asr_billing/service start
{code}
{excerpt}

h1. Свободного места на диске критично мало {anchor:emptyspace}
{tip}{*}Время выполнения инструкции*: 15-60 минут, в зависимости от скорости поиска данных для удаления или переноса, а так же времени на перенос данных{tip}

Заполнение дискового пространства вляется следствие работы операционной системы и программ, например программы Carbon Billing 5.
Если не ослеживать этот процесс и не реагировать вовремя на предупреждения [системы мониторинга|CarbonBilling:Система мониторинга], она может остановить работу биллинга во избежание повреждения базы данных биллинга.

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

h2. Очистка свободного пространства
h2. Очистка свободного места на диске

{tip}{*}Время выполнения инструкции*: 5-50 минут, в зависимости от скорости поиска данных для удаления или переноса, а так же времени на перенос данных{tip}

Мы описали это в достаточно объёмной статье [CarbonBilling:Мало места на диске]. Начине с заголовка "*Почему так получилось и как починить*", там описана краткая инструкция на примере раздела */mnt/log*, и дальше рассказано с каким данными что можно сделать.

h2. Восстановление БД в работу

{tip}{*}Время выполнения инструкции*: 5-10 минут, в зависимости от разера БД{tip}

h3. Биллинг в safemode

*1.* # Зайтите в чрут биллинга
{code}chroot /app/asr_billing{code}
*2.* # Найдите последний по времени создания файл в папке /var/db/safemode, для этого выполните команду
{code}ls -1trhd /var/db/safemode/* | tail -n 1
/var/db/safemode/billing.gdb.save_mode.2017-02-22_15-42-43.gdb{code}
*3.* # Скопируйте данный файл в папку, где он должен располагаться для запуска биллинга и выставьте правильные права доступа к файлу
{code}mv /var/db/safemode/billing.gdb.save_mode.2017-02-22_15-42-43.gdb /var/db/billing.gdb.stop
chown firebird:firebird /var/db/billing.gdb.stop{code}
# На всякий случай, проверяем, что БД трафика {{buff_traf.gdb}} на месте. Если её нет, берём пустую:
{code}
[ ! -s /var/db/buff_traf.gdb ] && ( yes | cp /skelet/var/db/buff_traf.gdb /var/db/buff_traf.gdb && chown firebird:firebird /var/db/buff_traf.gdb && chmod g+w /var/db/buff_traf.gdb )
{code}
*4.* # Выйдите из чрута и снова выполните запуск биллинга
{code}exit
echo 'stop OK' >/app/asr_billing/var/lib/app.state
...

h3. Биллинг не в safemode, при открытии абонента - ошибка Feedback

Биллинг не находится в состоянии safemode, но при открытии карточки абонента выходит ошибка "Feedback", в расширенном описании ошибки написано следующее:
{code}DatabaseError: ('Error while commiting transaction:\n- SQLCODE: -902\n- I/O error for file "/mnt/var/tmp_root/fb_table_IY4dTZ"\n- Error while trying to write to file\n- No space left on device', -902, 335544344){code}
Это означает, место кончилось на разделе */mnt/var*.
Очистив место по инструкции выше, выполните перезапуск контейнера биллинга:
{code}/app/asr_billing/service restart{code}