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

Skip to end of metadata
Go to start of metadata
Вы просматриваете старую версию данной страницы. Смотрите текущую версию. Сравнить с текущим  |   просмотр истории страницы

Отказоустойчивость БД биллинга

В 99% случаев БД повреждается при отключении питания. Поэтому, в системных требованиях прописано обязательное наличие настроенного UPS для штатного завершения работы сервера.

Если UPS настроить в ближайшее время нет возможности воспользуйтесь статьёй Как повысить выживаемость БД при сбоях питания

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

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

Работа биллинга может быть остановлена по двум причинам:

  1. Повреждение БД. В данном случае требуется восстановить БД из последней успешной резервной копии. Возможные причины:
    • Некорректная перезагрузка сервера, в процессе которой работа сервера была остановлена до остановки работы СУБД: shutdown или reboot без предварительной остановки платформы /etc/init.d/apps stop
    • Внезапное завершение работы по причине прекращения электропитания; жесткая перезагрузка сервера - эти действия могут привести к повреждению файловой системы, остановке сервера во время записи в файл БД
    • Заполнение раздела с БД до 100%, невозможность завершить запись в файл БД.
    • Результат некорректных действий технического персонала с БД или при проведении технических работ на сервере.
  2. Остановка работы без повреждения БД. Безопасная остановка работы сервера, база не повреждается и может быть восстановлена в работу после устранения всех проблем. Возможные причины:
    • Нехватка свободного места на одном из разделов, в результате чего система мониторинга останавливает работу биллинга до момента очистки места (инструкция).

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

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

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

В открывшемся меню, доступные экземпляры БД будут разделены на три категории:

  1. Список баз в safemode (не поврежденных): базы остановленные системой мониторинга состояния сервера. Такие базы не повреждены, однако перед восстановлением следует освободить место по инструкции.
  2. Список повреждённых баз: такие базы невозможно восстановить автоматический и требует ручного анализа проблемы. Рекомендуется восстанавливаться из резервной копии.
  3. Список резервных копий: резервные копии, хранящиеся непосредственно на сервере в директории /app/asr_billing/mnt/backup. Копии, выгруженные на ftp в данный список не входят.

Для восстановление нужного экземпляра БД, нажмите кнопку "Восстановить" в соответствующей строке.

При нажатии кнопки "Восстановить", автоматический Вы будете перенаправлены на страницу, в которой отображается лог выполнения операции восстановления

Следующая строка в логе соответствует завершению процесса восстановления:

# /app/asr_billing/service restart: [ OK ]

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

Восстановление БД из консоли (автоматический)

Время выполнения инструкции: 5-20 минут, в зависимости размера БД различия версий - после даты создания выбранной резервной копии производилось обновление сервера, дополнительно запускается скрипт обновления структуры БД
  1. Посмотрите список доступных резервных копий
    /app/asr_billing/service backup_local_list

    Приблизительный вывод команды:

    /app/asr_billing backup_local_list
    backup_monthly_2019-03-31_02-50_asr_billing.tar.gz
    backup_weekly_2019-03-27_02-50_asr_billing.tar.gz
    backup_daily_2019-04-04_02-50_asr_billing.tar.gz
    
    # /app/asr_billing/service backup_local_list:              [  OK  ]
    Восстановление биллинга автоматический возможно только с резервных копий находящихся на локальном сервере. Если нужная резервная копия находится на FTP, Вы можете посмотреть список всех выгруженных копий и загрузить на локальный сервер:
    /app/asr_billing/service backup_ftp_list
    /app/asr_billing/service backup_download backup_2019-03-22_2019-03-22_16-19_asr_billing.tar.gz
  2. Запустите восстановление нужной копии. Начнется процесс остановки контейнера (если он запущен), распаковки архива, наложения на архивную базу патчей и тд:
    /app/asr_billing/service backup_restore backup_daily_2019-04-04_02-50_asr_billing.tar.gz

    Приблизительный вывод:

    /app/asr_billing backup_restore backup_daily_2019-04-04_02-50_asr_billing.tar.gz
    /app/asr_billing stop
    Stopping Felicitation Daemon:                              [ OK ]
    Stopping Jobs Daemon:                                      [  OK  ]
    ...
    Stopping app firewall:                                     [  OK  ]
    
    # /app/asr_billing/service stop:                           [  OK  ]
    
    
    Запускаем restore хук /usr/local/bin/restore_hook.sh
    Starting xinetd:                                           [  OK  ]
    Создаем бекап
    gbak -b -v -ig -g -e 169.254.30.50:/var/db/billing.gdb.stop /mnt/backup/billing.gdb.stop_2019-04-04_14-01.gbk.3960.tmp -user SYSDBA -password servicem
    ...
    Starting Message Daemon:                                   [  OK  ]
    Starting Paysystems Daemon:                                [  OK  ]
    Reloading Base Web Server:                                 [  OK  ]
    
    # /app/asr_billing/service start:                          [  OK  ]
    
    
    
    # /app/asr_billing/service backup_restore backup_daily_2019[  OK  ]2-50_asr_billing.tar.gz: 
    

    В зависимости от размера Вашей базы, восстановление может продолжаться 10-30 минут.

Восстановление БД из консоли (вручную)

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

Резервное копирование и восстановление из бекапов при помощи WinSCP

В случае переноса данных системы на другой компьютер или переустановки системы с последующим восстановлением конфигурации и базы пользователей, необходимо сначала сделать полный бекап данных с работающей системы. Для того чтобы сделать полный бекап системы необходимо скопировать резервные копии самой базы пользователей и бекап конфигурационного файла системы. Это делается с помощью программы winscp, дистрибутив которой вы всегда можете найти в Интернете по адресу: http://winscp.net/ Программа бесплатна.

Процесс восстановления данных из бекапов можно разбить на два шага:

ШАГ 1: Копирование данных с сервера

Подключаемся к серверу на 33 или 22 порт, либо иной порт, в зависимости от Ваших настроек

Убедитесь что данные введены верно и нажимайте "Login", после подключения вы увидите окно, похожее на обычный файловый менеджер с двумя панелями, слева будет ваш локальный компьютер, справа - файловая система Carbon Billing, вас интересует каталог BACKUP на ней.

Путь такой: /app/asr_billing/mnt/backup/

Здесь хранятся ежедневные, ежемесячные и еженедельные бэкапы. Вы можете выбрать те, которые нужны Вам.

Примечание: Статистика копируется отдельно из папки: /app/collector/var/stat/raw/
Примечание: Восстановиться можно из локальных бэкапов, которые хранятся в /mnt/backup/app/asr_billing/backup/ Эти бэкапы не архивированные, поэтому при восстановлении из бэкапа пункт 1 ШАГа 2 нужно пропустить. Данные бэкапы делаются автоматически каждый день, если в разделе /mnt/backup/ достаточно места.

ШАГ 2: Восстановление из бэкапа

1. Подготовка

Восстанавливать БД можно из локального бэкапа (Дневной, Недельный, Месячный) либо из бэкапа, который копируется на FTP сервер. На FTP сервере бэкапы хранятся в архиве, поэтому после копирования на сервер с биллингом их нужно распаковать. Например имя бэкапа backup_daily_2016-30-21_02-53_asr_billing.tar.gz, тогда команда распаковки будет выглядеть вот так:
Перед выполнением операции, перейдите в директорию где лежит требуемая резервная копия. Допустим, требуется восстановить одну из локальных резервных копий. В таком, случае выполните следующую команду:

cd /app/asr_billing/mnt/backup/

Далее, извлеките резервную копию БД из архива:

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

2. Распаковка БД

При восстановлении из локального бэкапа имя будет содержать дату и время, так вы поймете какой из бэкапов последний и наиболее актуальный. Допустим, что имя бэкапа billing.gdb.gbk, тогда сделать нужно следующее:

chroot /app/asr_billing/
gbk2gdb.sh /mnt/backup/billing.gdb.gbk /var/db/billing_prepare.gdb
exit
Если в процессе распаковки БД возникло сообщение об ошибке "ERROR:database /var/db/billing_prepare.gdb already exists", значит файл с таким названием уже существует - он мог появится при предыдущих попытках восстановить БД. Старый файл billing_prepare.gdb удалите или переместите в другое место (например, на раздел /mnt/backup)
gbak:opened file /mnt/backup/billing.gdb.gbk
gbak: ERROR:database /var/db/billing_prepare.gdb already exists. To replace it, use the -REP switch
gbak:Exiting before completion due to errors

3. Остановка биллинга

/app/asr_billing/service stop
При появлении сообщения о переходе базы в safemode такого содержания:
error:

asr_billing in safe mode. Check logs. /app/base/var/log/watchdog.log and other log
You must fix the problem or get support from developer!

status: safemode from chroot /app/asr_billing /sbin/init start prevstate=stop OK

echo 'stop OK' >/app/asr_billing/var/lib/app.state

Переходите к пункту 4. В данном случае, биллинг уже является остановленным.

4. Сохранение текущей БД (опционально)

Проверяем, что в /app/asr_billing/var/db есть файл billing.gdb.stop (это файл текущей БД)
Если он есть, то перемещаем его рядом (в этот же каталог) с указанием даты, например 2016-08-03 (позже можно будет удалить):

cd /app/asr_billing/var/db/
mv billing.gdb.stop blling.2016-08-03.gdb.stop
Если же файла нет, то приступайте к пункту 5
Если произошел reset сервера (например по причине сбоя электропитания), то с высокой вероятностью база данных испортится, и файл БД переместится в /app/asr_billing/var/db/bad/billing.corrupt*

5. Перемещение файла БД на место остановленной базы

Превращаем восстановленный бэкап в полноценную БД

chroot /app/asr_billing/
cd /var/db
mv ./billing_prepare.gdb ./billing.gdb.stop
chown firebird:firebird ./billing.gdb.stop
exit

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

Запускаем скрипт обновления БД

chroot /app/asr_billing/ update_hook.sh --force
Обновление БД нужно запускать строго на остановленном биллинге! Иначе это приведёт к разрушению базы.

7. Восстановление платежей

Восстанавливаем финансовые операции, которые прошли после создания бэкапа, но до падения БД.*
Пример, нужно восстановить данные за сентябрь 2016 года после восстановления БД в этот день.

chroot /app/asr_billing/
service xinetd restart
service admin_web_server restart
service billing_db restart
service nginx restart
/usr/local/bin/restore_pays.sh /var/db/raw.tmp/201609/pay/
При восстановлении финансовых операций запись в журнале платежей не появляется, т. е. в нем не отобразятся данные по платежам с момента сбоя базы данных до момента восстановления.
Скрипт предназначен для запуска только в процессе восстановления из резервной копии! Не запускайте на работающей базе для исправления каких-либо ошибок проведения платежей.

8. Исправление счетчиков

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

python /usr/lib/python2.7/site-packages/python_tools/client_fix_scripts/fix_generators2.py

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

Запускаем биллинг

echo 'stop OK' > /app/asr_billing/var/lib/app.state
/app/asr_billing/service restart

10. Проверка на наличине ошибок

Проверяем что все демоны стартовали и не растут ошибки
Для этого 2 раза подряд запускаем проверку сервера:

server_check

При этом могут быть записи вида:

- Критические ошибки в логе worker за последний час: 3 [СБОЙ]

или

- Ошибки в логе traf-reporter за последний час: 4 [СБОЙ]

Если в течение двух запусков проверки значения не меняются - все в порядке.
Если растут значения "Критические ошибки в логе worker за последний час" - сразу обратитесь в техническую поддержку.
Если растут значения "Ошибки в логе traf-reporter за последний час" - выполните команды

chroot /app/asr_billing/
yes | cp /skelet/var/db/buff_traf.gdb /var/db/
chown firebird:firebird /var/db/buff_traf.gdb
chmod g+w /var/db/buff_traf.gdb
/etc/init.d/radiusd_traf restart

Восстановление демонстрационной или пустой БД

Время выполнения инструкции: 1-10 минут

1. Останавливаем биллинг

/app/asr_billing/service stop

2. При необходимости сохраняем текущую БД

mv /app/asr_billing/var/db/billing.gdb.stop /root/

3. Копируем в рабочий каталог:
a) демо БД

yes | cp -p /app/asr_billing/skelet/var/db/billing.gdb /app/asr_billing/var/db/billing.gdb.stop

b) Или пустую БД

yes | cp -p /app/asr_billing/skelet/var/db/billing_system.gdb /app/asr_billing/var/db/billing.gdb.stop

А также обязательно пустую БД трафика

yes | cp -p /app/asr_billing/skelet/var/db/buff_traf.gdb /app/asr_billing/var/db/buff_traf.gdb.stop

4. Запускаем биллинг

/app/asr_billing/service start

Свободного места на диске критично мало

Время выполнения инструкции: 15-60 минут, в зависимости от скорости поиска данных для удаления или переноса, а так же времени на перенос данных

Если после выполнения команды

/app/asr_billing/service start 

Вы получаете достаточно объемный вывод, в конце которого содержится абзац следующего содержания:

Свободного места на диске критично мало. Для предотвращения необратимых проблем, биллинг переходит в safe-mode.
Освободите свободное место на диске и запустите команду /app/asr_billing/service start 

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

Очистка свободного пространства

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

Для определения проблемного раздела, Вы можете использовать утилиту df, отфильтровава вывод утилитой grep, чтобы видеть только физические разделы

[root@devel185 ~]# df -h | grep -wE '/|/mnt'
/dev/vda1       9,5G  3,5G  5,6G  39% /
/dev/vda9        71G  1,2G   67G   2% /mnt/backup
/dev/vda3        96G  4,0G   88G   5% /mnt/db
/dev/vda8       3,8G   46M  3,6G   2% /mnt/etc
/dev/vda7        96G  827M   91G   1% /mnt/log
/dev/vda2       711G  2,7G  673G   1% /mnt/var

Определив проблемный раздел (занято более 85%), необходимо найти что занимает более всего пространства. Сделать это можно утилитой du, например:

du -sch /mnt/var/app/*
915M    /mnt/var/app/asr_billing
478M    /mnt/var/app/asr_cabinet
80M     /mnt/var/app/asr_fiscal
77M     /mnt/var/app/auth
68M     /mnt/var/app/base
206M    /mnt/var/app/collector
214M    /mnt/var/app/monitoring
104M    /mnt/var/app/xge
2,1G    итого

Определив пробленые каталоги и/или файлы, дальнейшие действия - по ситуации:

  • /mnt/vat, /mnt/stat. Наиболее частой проблемой является заполнение раздела /mnt/var (либо /mnt/stat), а именно каталога /mnt/var/app/collector/var/stat/binstat/. Решение описано в следующей статье.
  • /mnt/log. При заполнении раздела /mnt/log, наиболее верным решением будет выполнить команды head и tail на проблемный файл и приложить полученный вывод в новую, либо автоматический созданную по данной проблеме заявку на портале HelpDesk и сообщить о проблеме в техподдержку по телефону.
    Если явно больших файлов лога не обнаружено, вероятно у Вас просто слишком маленький раздел под логи. Добавьте места.
  • /mnt/backup. Если забит раздел /mnt/backup - просто очистите старые бэкапы, исследовав структуру каталогов программой du. В случае если проблема с разделом восникает часто, вероятно Вам следует добавить места под логи
  • /mnt/etc. В случае заполнения раздела /mnt/etc обратитесь в техподдержку.
  • /mnt/db. Если Ваша аппаратная платформа соответствует нашим системным требованиям, вероятност заполнения раздела в обозримом будущем крайне мала, так как под раздел выделяется не менее 100Гб места (при диске 1Тб и более).
    • /mnt/db/app/asr_billing/db/notstopped - в папке сохраняются базы, поврежденные в результатате некорректного завершения работы сервера. Вы можете попробовать достать из них потерянные данные или восстановить целиком воспользовавшись услугами специалистов занимающихся восстановлением баз данных или информацией доступной в документации Firebird.
    • /mnt/db/app/asr_billing/db/safemode - в папке сохраняются базы, работа которых была завершена корректно, их можно восстановить в работу. В последствии содержимое папки можно очистить.
  • / (корневой раздел ОС). Проверьте что место не занять в результате установки стороннего ПО или выполнения каких-либо скриптов, например при выполнении заданий добавленных в cron, либо в процессе работы на сервере в пользовательской директории (/root, /home). Например, место на корневом разделе может быть занято в результате включенного мониторинга сервера с atop, данные которого записываются в папку /var/log/atop.

Удалить файлы Вы можете утилитой rm:

rm -f /mnt/log/app/collector/log/nf_collector.log

Заполнение дискового пространства вляется обычным процессом работы ОС и ситуация при которой один из разделов запоняется до предела, в результате чего watchdog для сохранности останавливает биллинг является абсолютно нормальной. Тем не менее, работы по диагностике и решению проблемы требуют определенного уровня знаний от технического специалиста. Объем работы выполняемой теподдержкой Carbon Soft по диагностике и решению проблемы напрямую зависит от выбранного Вами уровня технической поддержки.

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

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

Биллинг в safemode

1. Зайтите в чрут биллинга

chroot /app/asr_billing

2. Найдите последний по времени создания файл в папке /var/db/safemode, для этого выполните команду

ls -1trhd /var/db/safemode/* | tail -n 1
/var/db/safemode/billing.gdb.save_mode.2017-02-22_15-42-43.gdb

3. Скопируйте данный файл в папку, где он должен располагаться для запуска биллинга и выставьте правильные права доступа к файлу

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

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

exit
echo 'stop OK' >/app/asr_billing/var/lib/app.state
/app/asr_billing/service restart

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

Биллинг не находится в состоянии safemode, но при открытии карточки абонента выходит ошибка "Feedback", в расширенном описании ошибки написано следующее:

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)

Это означает, место кончилось на разделе /mnt/var.
Очистив место по инструкции выше, выполните перезапуск контейнера биллинга:

/app/asr_billing/service restart
Введите метки, чтобы добавить к этой странице:
Please wait 
Ищите метку? просто начните печатать.