- Отказоустойчивость БД биллинга
- Возможные причины повреждения БД и остановки работы биллинга.
- Восстановление БД в web-интерфейсе
- Восстановление БД из консоли (автоматический)
- Восстановление БД из консоли (вручную)
- Восстановление демонстрационной БД
- Восстановление пустой БД
- Свободного места на диске критично мало
Отказоустойчивость БД биллинга
В 99% случаев БД повреждается при отключении питания. Поэтому, в системных требованиях прописано обязательное наличие настроенного UPS для штатного завершения работы сервера.
Если UPS настроить в ближайшее время нет возможности воспользуйтесь статьёй Как повысить выживаемость БД при сбоях питания
 | Восстановление баз данных, повреждённых в результате нарушения любых рекомендаций CarbonSoft по реализации отказоустойчивости сервера (UPS, параметры монтирования раздела БД, повреждение в результате тех. работ и т.д.), не входит в компетенцию компании. |
Возможные причины повреждения БД и остановки работы биллинга.
Работа биллинга может быть остановлена по двум причинам:
- Повреждение БД. В данном случае требуется восстановить БД из последней успешной резервной копии. Возможные причины:
- Некорректная перезагрузка сервера, в процессе которой работа сервера была остановлена до остановки работы СУБД: shutdown или reboot без предварительной остановки платформы /etc/init.d/apps stop
- Внезапное завершение работы по причине прекращения электропитания; жесткая перезагрузка сервера - эти действия могут привести к повреждению файловой системы, остановке сервера во время записи в файл БД
- Заполнение раздела с БД до 100%, невозможность завершить запись в файл БД.
- Результат некорректных действий технического персонала с БД или при проведении технических работ на сервере.
- Остановка работы без повреждения БД. Безопасная остановка работы сервера, база не повреждается и может быть восстановлена в работу после устранения всех проблем. Возможные причины:
- Нехватка свободного места на одном из разделов, в результате чего система мониторинга останавливает работу биллинга до момента очистки места (инструкция).
Восстановление БД в web-интерфейсе
 | Время выполнения инструкции: 1-15 минут, в зависимости размера БД различия версий - после даты создания выбранной резервной копии производилось обновление сервера, дополнительно запускается скрипт обновления структуры БД |
При остановке работы биллинга по одной из вышеуказанных причин, Вы можете воспользоваться возможностью восстановления биллинга в web-интерфейсе.
Для этого, нажмите на пиктограмму интерфейса управления абонентами.
В открывшемся меню, доступные экземпляры БД будут разделены на три категории:
- Список баз в safemode (не поврежденных): базы остановленные системой мониторинга состояния сервера. Такие базы не повреждены, однако перед восстановлением следует освободить место по инструкции.
- Список повреждённых баз: такие базы невозможно восстановить автоматический и требует ручного анализа проблемы. Рекомендуется восстанавливаться из резервной копии.
- Список резервных копий: резервные копии, хранящиеся непосредственно на сервере в директории /app/asr_billing/mnt/backup. Копии, выгруженные на ftp в данный список не входят.
Для восстановление нужного экземпляра БД, нажмите кнопку "Восстановить" в соответствующей строке.
При нажатии кнопки "Восстановить", автоматический Вы будете перенаправлены на страницу, в которой отображается лог выполнения операции восстановления
Следующая строка в логе соответствует завершению процесса восстановления:
# /app/asr_billing/service restart: [ OK ]
После окончания процесса, нажмите на пиктограмму в виде стрелки в верхнем левом углу страницы, чтобы вернуться в интерфейс базовой системы.
Восстановление БД из консоли (автоматический)
| Время выполнения инструкции: 5-20 минут, в зависимости размера БД различия версий - после даты создания выбранной резервной копии производилось обновление сервера, дополнительно запускается скрипт обновления структуры БД |
- Посмотрите список доступных резервных копий
/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
- Запустите восстановление нужной копии. Начнется процесс остановки контейнера (если он запущен), распаковки архива, наложения на архивную базу патчей и тд:
/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. Подготовка
| ВАЖНО: Перед процедурой восстановления во избежание срабатывания автоматических тестов нужно отключить cron:
service crond stop |
Восстанавливать БД можно из локального бэкапа (Дневной, Недельный, Месячный) либо из бэкапа, который копируется на FTP сервер. На FTP сервере бэкапы хранятся в архиве, поэтому после копирования на сервер с биллингом их нужно распаковать. Например имя бэкапа backup_daily_2016-30-21_02-53_asr_billing.tar.gz, тогда команда распаковки будет выглядеть вот так:
Перед выполнением операции, перейдите в директорию где лежит требуемая резервная копия. Допустим, требуется восстановить одну из локальных резервных копий. В таком, случае выполните следующую команду:
cd /app/asr_billing/mnt/backup/
Далее, на всякий случай, выполните эту команду чтобы удалить старые неудачные копии БД:
rm -f /mnt/backup/app/asr_billing/backup/billing.gdb.gbk
Потом извлеките резервную копию БД из архива:
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
| Утилита tar напишет сообщение:
tar: Удаляется начальный `/' из имен объектов Это нормально, переходите к следующему шагу инструкции. |
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 |
| Также в процессе распаковки может возникнуть следующая ошибка:
[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 Возможная причина - отсутствие системных файлов БД Firebird. 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/ |
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
На всякий случай, проверяем, что БД трафика buff_traf.gdb на месте . Если её нет, берём пустую. Если есть остановленная БД трафика, сохраняем её в той же папке для архива.
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
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. Исправление счетчиков
После восстановления всех финансовых операций, по-прежнему находясь в контейнере биллинга выполните следующую команду
python2.7 /usr/lib/python2.7/site-packages/python_tools/client_fix_scripts/fix_generators2.py
9. Запуск биллинга
Выходим из контейнера командой
exit
Запускаем биллинг
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 за последний час" - сразу составьте обращение в портале HelpDesk.
Если растут значения "Ошибки в логе 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 минут |
- Останавливаем биллинг
/app/asr_billing/service stop
При необходимости сохраняем текущую БД mv /app/asr_billing/var/db/billing.gdb.stop /root/billing.gdb.stop-`date +%Y-%m-%d_%H%M` - Копируем в рабочий каталог демо БД
yes | cp -p /app/asr_billing/skelet/var/db/billing.gdb /app/asr_billing/var/db/billing.gdb.stop
- Уточняем текущее состояние биллинга для сервисного скрипта
echo 'stop OK' >/app/asr_billing/var/lib/app.state - Запускаем биллинг
/app/asr_billing/service start
Восстановление пустой БД
| Время выполнения инструкции: 1-10 минут |
- Останавливаем биллинг
/app/asr_billing/service stop
При необходимости сохраняем текущую БД mv /app/asr_billing/var/db/billing.gdb.stop /root/billing.gdb.stop-`date +%Y-%m-%d_%H%M` - Копируем в рабочий каталог пустую БД
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
- Уточняем текущее состояние биллинга для сервисного скрипта
echo 'stop OK' >/app/asr_billing/var/lib/app.state - Запускаем биллинг
/app/asr_billing/service start
Свободного места на диске критично мало
| Время выполнения инструкции: 15-60 минут, в зависимости от скорости поиска данных для удаления или переноса, а так же времени на перенос данных |
Заполнение дискового пространства вляется следствие работы операционной системы и программ, например программы Carbon Billing 5.
Если не ослеживать этот процесс и не реагировать вовремя на предупреждения системы мониторинга, она может остановить работу биллинга во избежание повреждения базы данных биллинга.
Определить что причина именно в переполнении раздела можно так:
- Выполните следующую команду:
Команда
/app/asr_billing/service start
- Если Вы получаете достаточно объемный вывод, в конце которого написано про свободное место, значит причина именно в переполнении раздела:
Свободного места на диске критично мало. Для предотвращения необратимых проблем, биллинг переходит в safe-mode. Освободите свободное место на диске и запустите команду /app/asr_billing/service start
В таком случае БД биллинга не повреждена, а остановлена для сохранности, необходимо освободить место на диске и запустить биллинг.
Очистка свободного места на диске
| Время выполнения инструкции: 5-50 минут, в зависимости от скорости поиска данных для удаления или переноса, а так же времени на перенос данных |
Мы описали это в достаточно объёмной статье Мало места на диске. Начине с заголовка "Почему так получилось и как починить", там описана краткая инструкция на примере раздела /mnt/log, и дальше рассказано с каким данными что можно сделать.
Восстановление БД в работу
| Время выполнения инструкции: 5-10 минут, в зависимости от разера БД |
Биллинг в safemode
- Зайтите в чрут биллинга
chroot /app/asr_billing
- Найдите последний по времени создания файл в папке /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
- Скопируйте данный файл в папку, где он должен располагаться для запуска биллинга и выставьте правильные права доступа к файлу
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
- На всякий случай, проверяем, что БД трафика buff_traf.gdb на месте. Если её нет, берём пустую:
[ ! -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 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