В процессе обновления до 006 повредил базу

Технические вопросы по UTM 5.0
Yurz
Сообщения: 19
Зарегистрирован: Чт июл 13, 2006 09:47

В процессе обновления до 006 повредил базу

Сообщение Yurz »

При обновлении биллинга до версии 006 (а точнее обновлении структры базы данных) завис процесс:

mysql -f UTM5 < /netup/utm5/UTM5_MYSQL_update.sql

Ждали почти час, потом сборсили. После повторного запуска процесс завершился.
Ядро стартануло, но выдало в дебаг
CRIT : Feb 04 16:15:28 UTM5 DBA: db verificator find critical error(s), see /netup/utm5/log/verificator.log for details
UTM5 Core started
В verificator.log примерно следующее:
-- ERROR link 5276, wrong tariff id
-- SQL DESC delete broken link (NOT RECOMMENDED)
-- UPDATE service_links SET is_deleted=1 WHERE id='5276';
-- UPDATE periodic_service_links SET is_deleted=1 WHERE id='5276';
-- UPDATE dialup_service_links SET is_deleted=1 WHERE id='5276';

-- ERROR link 5276, account tariff link id 3925, not equal discount period ids
-- SQL DESC delete broken link (NOT RECOMMENDED)
-- UPDATE service_links SET is_deleted=1 WHERE id='5276';
-- UPDATE periodic_service_links SET is_deleted=1 WHERE id='5276';
-- UPDATE dialup_service_links SET is_deleted=1 WHERE id='5276';

-- ERROR link 5649, tariff_link_id 4151 not exist
-- SQL DESC delete broken link (NOT RECOMMENDED)
-- UPDATE service_links SET is_deleted=1 WHERE id='5649';
-- UPDATE periodic_service_links SET is_deleted=1 WHERE id='5649';
-- UPDATE dialup_service_links SET is_deleted=1 WHERE id='5649';

-- ERROR link 5649, wrong tariff id
-- SQL DESC delete broken link (NOT RECOMMENDED)
-- UPDATE service_links SET is_deleted=1 WHERE id='5649';
-- UPDATE periodic_service_links SET is_deleted=1 WHERE id='5649';
-- UPDATE dialup_service_links SET is_deleted=1 WHERE id='5649';

-- ERROR link 5649, account tariff link id 4151, not equal discount period ids
-- SQL DESC delete broken link (NOT RECOMMENDED)
-- UPDATE service_links SET is_deleted=1 WHERE id='5649';
-- UPDATE periodic_service_links SET is_deleted=1 WHERE id='5649';
-- UPDATE dialup_service_links SET is_deleted=1 WHERE id='5649';

-- 22 errors
-- 0 warnings
-- affected tables: dialup_service_links iptraffic_service_links periodic_service_links service_links
-- RESTART utm5_core!
Впрочем, срочно нужно чтобы система заработала, поэтому все оставили как есть. Весь базовый функционал биллинга сохранился, возникли лишь проблеммы с отчетами, которые, я так полагаю связанны в свою очередь, с большой загрузкой машины. Но это заметили на четвертый день, так что просто откатить базу не получится.
top - 16:43:56 up 3 days, 3:20, 5 users, load average: 1.95, 3.08, 3.41
Tasks: 114 total, 1 running, 113 sleeping, 0 stopped, 0 zombie
Cpu(s): 20.5%us, 6.2%sy, 0.0%ni, 67.9%id, 5.2%wa, 0.1%hi, 0.0%si, 0.0%st
Mem: 4153512k total, 4005360k used, 148152k free, 1416k buffers
Swap: 15631224k total, 96k used, 15631128k free, 866240k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9279 mysql 18 0 129m 37m 5548 S 102 0.9 290:14.16 mysqld
Я конечно понимаю, что сами виноваты и надо было сразу откатить, но сейчас это уже невозможно. Вот собственно, возможно ли малой кровью восстановить поврежденную базу и заставить нормально работать? Заранее спасибо.

bear
Сообщения: 498
Зарегистрирован: Чт ноя 15, 2007 11:53

Сообщение bear »

дамп базы
заходим в мускул, смотрим таблицу service_links
ищем ID абонента по линк ид который написан в верификаторе
заходим в админку, ищем абона по ID, смотрим что у него с тарифами творится, сносим тарфиф/привязываем новый и так каждый слинк который написался в верификаторе
стоп ядра, старт ядра - смотрим верификатор

ежели не помогает, ниже метод НЕ РЕКОМЕНДОВАННЫЙ и выполняется на свой страх и риск

стоп ядра
дамп базы
очень аккуратно выполнить скуль запросами все что написалось в верификаторе
запуск, смотрим снова верификатор
повторить пока верификатор не будет девственно чист

да, и тюнинг мускула, уважаемый Магнум выкладывал свой пример, можно отталкиватся от него
Последний раз редактировалось bear Ср фев 04, 2009 11:50, всего редактировалось 1 раз.

JAO
Сообщения: 1153
Зарегистрирован: Вт дек 11, 2007 08:17

Сообщение JAO »

В этом скрипте есть одна операция, могущая отрабатывать часами, и даже на тюнингованном двухкорнике она минут двадцать занимает. Это добавление нового поля в таблицу discount_transactions_all.

Yurz
Сообщения: 19
Зарегистрирован: Чт июл 13, 2006 09:47

Сообщение Yurz »

JAO писал(а):В этом скрипте есть одна операция, могущая отрабатывать часами, и даже на тюнингованном двухкорнике она минут двадцать занимает. Это добавление нового поля в таблицу discount_transactions_all.
У меня двухпроцессорный Xeon 3 герца с четырьмя гигами оперативки. Но может быть ничего и не зависало а я просто лоханулся :(

Yurz
Сообщения: 19
Зарегистрирован: Чт июл 13, 2006 09:47

Сообщение Yurz »

Bear спасибо. Испробую сперва первый вариант.

bear
Сообщения: 498
Зарегистрирован: Чт ноя 15, 2007 11:53

Сообщение bear »

Yurz писал(а):
JAO писал(а):В этом скрипте есть одна операция, могущая отрабатывать часами, и даже на тюнингованном двухкорнике она минут двадцать занимает. Это добавление нового поля в таблицу discount_transactions_all.
У меня двухпроцессорный Xeon 3 герца с четырьмя гигами оперативки. Но может быть ничего и не зависало а я просто лоханулся :(
у меня на 2х4ядра апдейт делался в районе 4х часов, как раз с добавлением поля в discount_transactions_all
так что скорей всего на этом завис и был...

JAO
Сообщения: 1153
Зарегистрирован: Вт дек 11, 2007 08:17

Сообщение JAO »

Эта операция не от количества ядер зависит, а от производительности дисковой подсистемы. Хоть шестнадцать ядер повесь, без толку. ALTER TABLE делается путем создания таблицы с новой структурой, простого переливания данных из старой таблицы в новую, затем идет переименование таблицы и удаление старой. Как видите, вся работа идет исключительно с файлами, и ничего тут не попишешь. И что самое нехорошее, новая таблица создается в одном каталоге со старой, и там не больно-то вывернешься с монтированием в оперативку. Плюс индексы, плюс переменная длина ряда в этой таблице. И получается веселуха.

mikkey finn
Сообщения: 1612
Зарегистрирован: Пт ноя 10, 2006 15:23

Сообщение mikkey finn »

архивацию надо сначала делать, а потом апгрейд базы. Со свистом происходит...

Аватара пользователя
Magnum72
Сообщения: 1947
Зарегистрирован: Чт сен 22, 2005 06:54
Контактная информация:

Сообщение Magnum72 »

JAO писал(а):В этом скрипте есть одна операция, могущая отрабатывать часами, и даже на тюнингованном двухкорнике она минут двадцать занимает. Это добавление нового поля в таблицу discount_transactions_all.
Причем после апдейта настоятельно рекомендую грохнуть поле Comment в этой таблице, и отчеты начнут строится быстрее

Yurz
Сообщения: 19
Зарегистрирован: Чт июл 13, 2006 09:47

Сообщение Yurz »

JAO писал(а):Эта операция не от количества ядер зависит, а от производительности дисковой подсистемы.
Да, винты у меня не ахти. Тем более один в рейде посыпался похоже. Три года это срок нехилый, надо готовить замену.

JAO
Сообщения: 1153
Зарегистрирован: Вт дек 11, 2007 08:17

Сообщение JAO »

Поле comment прибить весьма желательно. А я так и вовсе пошел самым страшным путем. Залил пустую структуру с индексами от версии 006, затем обновил с 003 до 006 старую базу, и сделал полный перелив всех таблиц из одной базы в другую с точностью до полей с одинаковыми именами. Посмотрим как оно работать будет. Пока же повторять данный трюк не рекомендую. Ядро по крайней мере запускается и данные через админку видно.

kirush
Сообщения: 699
Зарегистрирован: Пт фев 04, 2005 13:58

Сообщение kirush »

Magnum72 писал(а):
JAO писал(а):В этом скрипте есть одна операция, могущая отрабатывать часами, и даже на тюнингованном двухкорнике она минут двадцать занимает. Это добавление нового поля в таблицу discount_transactions_all.
Причем после апдейта настоятельно рекомендую грохнуть поле Comment в этой таблице, и отчеты начнут строится быстрее
Можно ли грохнуть её на рабочем биллинге?
Не понадобится ли рестарт?

JAO
Сообщения: 1153
Зарегистрирован: Вт дек 11, 2007 08:17

Сообщение JAO »

Насколько мне известно, нежелательно это делать, пока биллинг работает. Неизвестно, как он себя поведет во время преобразования таблицы, в которую он должен заносить данные. Именно поэтому рекомендуется сначала рассовать данные по архивам и сделать рабочие таблицы как можно меньше размером. Архивы можно и во время работы биллинга крутить как душе угодно, а вот телодвижения с основными таблицами могут плохо кончиться.

Yurz
Сообщения: 19
Зарегистрирован: Чт июл 13, 2006 09:47

Сообщение Yurz »

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

Мускуль при рестарте выдает:
Checking for corrupt, not cleanly closed and upgrade needing tables.
Стартует, но продолжает постоянно что-то чекать
491 pts/2 S 0:00 /bin/sh /usr/bin/mysqld_safe
552 pts/2 Sl 2:09 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-locking --port=3306 --socket=/var/run/mysqld/mysqld.sock
553 pts/2 S 0:00 logger -p daemon.err -t mysqld_safe -i -t mysqld
586 pts/2 S 0:00 /bin/bash /etc/mysql/debian-start
592 pts/2 S 0:00 /usr/bin/mysqlcheck --defaults-file=/etc/mysql/debian.cnf --all-databases --fast --silent
Что еще посоветуете?

Yurz
Сообщения: 19
Зарегистрирован: Чт июл 13, 2006 09:47

Сообщение Yurz »

Magnum72 писал(а):
JAO писал(а):В этом скрипте есть одна операция, могущая отрабатывать часами, и даже на тюнингованном двухкорнике она минут двадцать занимает. Это добавление нового поля в таблицу discount_transactions_all.
Причем после апдейта настоятельно рекомендую грохнуть поле Comment в этой таблице, и отчеты начнут строится быстрее
Грохнуть поле это в смысле удалить его или очистить содержимое?

Ответить