|
Ключ
Эта строка удалена.
Это слово было удалено. Это слово было добавлено.
Эта строка добавлена.
|
Изменения (89)
просмотр истории страницы... |
{anchor:failover} |
h21. Отказоустойчивость БД биллинга |
В 99% случаев БД повреждается при отключении питания. Поэтому, в [системных требованиях|http://docs.carbonsoft.ru/48693408] прописано обязательное наличие настроенного [UPS|http://docs.carbonsoft.ru/51380480] для штатного завершения работы сервера. |
... |
Если UPS настроить в ближайшее время нет возможности воспользуйтесь статьёй [Как повысить выживаемость БД при сбоях питания|http://docs.carbonsoft.ru/68845609] |
{info}Восстановление баз данных, повреждённых в результате нарушения любых рекомендаций CarbonSoft по реализации отказоустойчивости сервера (UPS, параметры монтирования раздела БД, повреждение в результате тех. работ и т.д.), не входит в компетенцию компании.{info} |
|
h1. Возможные причины повреждения БД и остановки работы биллинга. |
|
{info}Восстановление баз данных, повреждённых в результате нарушения любых рекомендаций CarbonSoft по реализации отказоустойчивости сервера (UPS, параметры монтирования раздела БД, повреждение в результате тех. работ и т.д.), не входит в компетенцию компании и не включено SLA.{info} h2. Возможные причины повреждения БД и остановки работы биллинга. |
Работа биллинга может быть остановлена по двум причинам: # Повреждение БД. В данном случае требуется восстановить БД из последней успешной резервной копии. Возможные причины: |
... |
#* Нехватка свободного места на одном из разделов, в результате чего система мониторинга останавливает работу биллинга до момента очистки места ([инструкция|#emptyspace]). |
h21. Восстановление БД в web-интерфейсе |
|
{tip}{*}Время выполнения инструкции*: 1-15 минут, в зависимости размера БД различия версий - после даты создания выбранной резервной копии производилось обновление сервера, дополнительно запускается скрипт обновления структуры БД{tip} |
При остановке работы биллинга по одной из вышеуказанных причин, Вы можете воспользоваться возможностью восстановления биллинга в web-интерфейсе. Для этого, нажмите на пиктограмму интерфейса управления абонентами. |
... |
!backup_web_4.png|border=1,width=1000! |
h1. Восстановление БД из консоли (автоматический) |
|
h2. Восстановление БД из консоли |
{tip}{*}Время выполнения инструкции*: 5-20 минут, в зависимости размера БД различия версий - после даты создания выбранной резервной копии производилось обновление сервера, дополнительно запускается скрипт обновления структуры БД{tip} |
|
# Посмотрите список доступных резервных копий {code}/app/asr_billing/service backup_local_list{code} Приблизительный вывод команды: {code}/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 ]{code} {info}Восстановление биллинга автоматический возможно только с резервных копий находящихся на локальном сервере. Если нужная резервная копия находится на FTP, Вы можете посмотреть список всех выгруженных копий и загрузить на локальный сервер: {code}/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{code}{info} # Запустите восстановление нужной копии. Начнется процесс остановки контейнера (если он запущен), распаковки архива, наложения на архивную базу патчей и тд: {code}/app/asr_billing/service backup_restore backup_daily_2019-04-04_02-50_asr_billing.tar.gz{code} Приблизительный вывод: {code}/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: {code} В зависимости от размера Вашей базы, восстановление может продолжаться 10-30 минут. h1. Восстановление БД из консоли (вручную) {tip}{*}Время выполнения инструкции*: 15-30 минут, в зависимости размера БД различия версий - после даты создания выбранной резервной копии производилось обновление сервера, дополнительно запускается скрипт обновления структуры БД{tip} |
{color:#000000}{*}Резервное копирование и восстановление из бекапов при помощи WinSCP{*}{color} |
... |
Процесс восстановления данных из бекапов можно разбить на два шага: |
*ШАГ 1: Копирование данных с сервера.* |
|
h2. ШАГ 1: Копирование данных с сервера |
Подключаемся к серверу на 33 или 22 порт, либо иной порт, в зависимости от Ваших настроек |
... |
*Примечание*: Восстановиться можно из локальных бэкапов, которые хранятся в /mnt/backup/app/asr_billing/backup/ Эти бэкапы не архивированные, поэтому при восстановлении из бэкапа пункт 1 ШАГа 2 нужно пропустить. Данные бэкапы делаются автоматически каждый день, если в разделе /mnt/backup/ достаточно места. |
*ШАГ 2: Восстановление из бэкапа.* |
h2. ШАГ 2: Восстановление из бэкапа |
|
# Подготовка |
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. Распаковка БД |
# Восстанавливаем БД из бэкапа. При восстановлении из локального бэкапа имя будет содержать дату и время, так вы поймете какой из бэкапов последний и наиболее актуальный. Допустим, что имя бэкапа billing.gdb.gbk, тогда сделать нужно следующее: |
{code} chroot /app/asr_billing/ |
... |
exit {code} |
# Останавливаем биллинг |
{note}Если в процессе распаковки БД возникло сообщение об ошибке "*ERROR:database /var/db/billing_prepare.gdb already exists*", значит файл с таким названием уже существует - он мог появится при предыдущих попытках восстановить БД. Старый файл billing_prepare.gdb удалите или переместите в другое место (например, на раздел /mnt/backup) {code}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{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} |
/app/asr_billing/service stop {code} |
... |
Переходите к пункту 4. В данном случае, биллинг уже является остановленным. {note} |
h3. 4. Сохранение текущей БД (опционально) |
# Проверяем, что в /app/asr_billing/var/db есть файл billing.gdb.stop (это файл текущей БД) |
Если он есть, то перемещаем его рядом (в этот же каталог) с указанием даты, например 2016-08-03 (позже можно будет удалить): {code} |
... |
{note}Если же файла нет, то приступайте к пункту 5 Если произошел reset сервера (например по причине сбоя электропитания), то с высокой вероятностью база данных испортится, и файл БД переместится в /app/asr_billing/var/db/bad/billing.corrupt\*{note} |
h3. 5. Перемещение файла БД на место остановленной базы |
# Превращаем восстановленный бэкап в полноценную БД |
{code} chroot /app/asr_billing/ |
... |
exit {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}chroot /app/asr_billing/ update_hook.sh --force{code} {warning}Обновление БД нужно запускать строго на остановленном биллинге\! Иначе это приведёт к разрушению базы.{warning} |
h3. 7. Восстановление платежей |
# Восстанавливаем финансовые операции, которые прошли после создания бэкапа, но до падения БД.\* |
Пример, нужно восстановить данные за сентябрь 2016 года после восстановления БД в этот день. {code} 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/ {code} {info} При восстановлении финансовых операций запись в [журнале платежей|http://http://docs.carbonsoft.ru/48693363] не появляется, т. е. в нем не отобразятся данные по платежам с момента сбоя базы данных до момента восстановления. {info} |
{warning}Скрипт предназначен для запуска только в процессе восстановления из резервной копии\! Не запускайте на работающей базе для исправления каких-либо ошибок проведения платежей.{warning} h3. 8. Исправление счетчиков |
# После восстановления всех финансовых операций, по-прежнему находясь в контейнере биллинга выполните следующую команду |
{code} |
python2.7 /usr/lib/python2.7/site-packages/python_tools/client_fix_scripts/fix_generators2.py |
{code} |
h3. 9. Запуск биллинга Выходим из контейнера командой {code}exit{code} |
# Запускаем биллинг |
{code} echo 'stop OK' > /app/asr_billing/var/lib/app.state /app/asr_billing/service restart {code} |
h3. 10. Проверка на наличине ошибок |
# Проверяем что все демоны стартовали и не растут ошибки |
Для этого 2 раза подряд запускаем проверку сервера: {code} |
... |
{code} Если в течение двух запусков проверки значения не меняются - все в порядке. |
Если растут значения "Критические ошибки в логе worker за последний час" - сразу обратитесь в техническую поддержку. |
Если растут значения "Критические ошибки в логе worker за последний час" - сразу составьте обращение в портале [HelpDesk|https://helpdesk.carbonsoft.ru/login.php]. |
Если растут значения "Ошибки в логе traf-reporter за последний час" - выполните команды {code} |
... |
{code} |
h2. Восстановление демонстрационной или пустой БД |
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} |
|
h21. Свободного места на диске критично мало {anchor:emptyspace} |
{tip}{*}Время выполнения инструкции*: 15-60 минут, в зависимости от скорости поиска данных для удаления или переноса, а так же времени на перенос данных{tip} |
|
Если после выполнения команды |
Заполнение дискового пространства вляется следствие работы операционной системы и программ, например программы Carbon Billing 5. Если не ослеживать этот процесс и не реагировать вовремя на предупреждения [системы мониторинга|CarbonBilling:Система мониторинга], она может остановить работу биллинга во избежание повреждения базы данных биллинга. Определить что причина именно в переполнении раздела можно так: # Выполните следующую команду: |
{code:title=Команда}/app/asr_billing/service start {code} |
Вы получаете достаточно объемный вывод, в конце которого содержится абзац следующего содержания: |
# Если Вы получаете достаточно объемный вывод, в конце которого написано про свободное место, значит причина именно в переполнении раздела: |
{code}Свободного места на диске критично мало. Для предотвращения необратимых проблем, биллинг переходит в safe-mode. |
Освободите свободное место на диске и запустите команду /app/asr_billing/service start {code} |
Порядок действий по восстановлению будет иной. В таком случае БД биллинга не повреждена, а остановлена для сохранности. Произведите следующие действия: |
|
*ШАГ 1. Очистка свободного пространства* |
В таком случае БД биллинга не повреждена, а остановлена для сохранности, необходимо освободить место на диске и запустить биллинг. |
|
Для определения проблемного раздела, Вы можете использовать утилиту *df*, отфильтровава вывод утилитой *grep*, чтобы видеть только физические разделы {code}[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{code} Определив проблемный раздел (занято более 85%), необходимо найти что занимает более всего пространства. Сделать это можно утилитой *du*, например: {code}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 итого{code} Определив пробленые каталоги и/или файлы, дальнейшие действия - по ситуации: - */mnt/vat*, */mnt/stat*. Наиболее частой проблемой является заполнение раздела */mnt/var* (либо */mnt/stat*), а именно каталога */mnt/var/app/collector/var/stat/binstat/*. Решение описано в [следующей статье|CarbonBilling:Добавление диска под статистику]. - */mnt/log*. При заполнении раздела */mnt/log*, наиболее верным решением будет выполнить команды head и tail на проблемный файл и приложить полученный вывод в новую, либо автоматический созданную по данной проблеме заявку на портале [HelpDesk|http://helpdesk.carbonsoft.ru/login.php] и сообщить о проблеме в техподдержку по телефону. Если явно больших файлов лога не обнаружено, вероятно у Вас просто слишком маленький раздел под логи. [Добавьте места|CarbonBilling:Добавление диска под логи]. - */mnt/backup*. Если забит раздел /mnt/backup - просто очистите старые бэкапы, исследовав структуру каталогов программой *du*. В случае если проблема с разделом восникает часто, вероятно Вам следует [добавить места под логи|CarbonBilling:Добавление диска под бэкапы] - */mnt/etc*. В случае заполнения раздела */mnt/etc* обратитесь в техподдержку. - */mnt/db*. Если Ваша аппаратная платформа соответствует нашим [системным требованиям|Системные требования], вероятност заполнения раздела в обозримом будущем крайне мала, так как под раздел выделяется не менее 100Гб места (при диске 1Тб и более). - */ (корневой раздел ОС)*. Убедитесь что раздел не занят результатом Ваших собственных действия, например при выполнении заданий добавленных в cron, либо в процессе работы на сервере в пользовательской директории (/root, /home). |
h2. Очистка свободного места на диске |
|
Удалить файлы Вы можете утилитой rm: {code}rm -f /mnt/log/app/collector/log/nf_collector.log{code} |
{tip}{*}Время выполнения инструкции*: 5-50 минут, в зависимости от скорости поиска данных для удаления или переноса, а так же времени на перенос данных{tip} |
|
Заполнение дискового пространства вляется обычным процессом работы ОС и ситуация при которой один из разделов запоняется до предела, в результате чего watchdog для сохранности останавливает биллинг является абсолютно нормальной. Тем не менее, работы по диагностике и решению проблемы требуют определенного уровня знаний от технического специалиста. Объем работы выполняемой теподдержкой Carbon Soft по диагностике и решению проблемы напрямую зависит от выбранного Вами [уровня технической поддержки|http://www.carbonsoft.ru/support/]. |
Мы описали это в достаточно объёмной статье [CarbonBilling:Мало места на диске]. Начине с заголовка "*Почему так получилось и как починить*", там описана краткая инструкция на примере раздела */mnt/log*, и дальше рассказано с каким данными что можно сделать. |
|
*ШАГ 2. Восстановление БД в работу* |
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 /app/asr_billing/service restart{code} |
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} |