Архивирование списаний

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

Сообщение Magnum72 »

gravis писал(а):
Magnum72 писал(а): бегин
ренаме discount_transactions_all в discount_transactions_all_хххх
смотрим автоинкремент ид у discount_transactions_all_хххх
креате табле discount_transactions_all с автоинкремент из discount_transactions_all_хххх
далее спокойно переносим маленький кусочек данных из discount_transactions_all_хххх в discount_transactions_all
тоже самое с discount_transactions_iptraffic_all
коммит

ЗЫ естесно данная операция должна быть строго ежемесячной
1. а что в это время делает биллинг, пытающийся записать данные в discount_transactions_* ?
2. сколько, на вашем примере, занимает эта операция?
ЗЫ сори коммит надо перенести на место после создания таблицы..
а перенс даыннх можно сделать в любой время хоть через неделю..
инкремент то мы сохранили в созданной таблице

jack7
Сообщения: 73
Зарегистрирован: Пн июн 06, 2005 10:56

Сообщение jack7 »

gravis писал(а): 1. а что в это время делает биллинг, пытающийся записать данные в discount_transactions_* ?
2. сколько, на вашем примере, занимает эта операция?
1) имхо, биллинг надо выключать на время такой операции
2) зависит от того сколько времени прошло от 1 числа текущего месяца, так как время копирования уйдет именно на данные появившиеся с 1 числа текущего месяца до дня когда запущена архивация

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

Сообщение Magnum72 »

jack7 писал(а):
gravis писал(а): 1. а что в это время делает биллинг, пытающийся записать данные в discount_transactions_* ?
2. сколько, на вашем примере, занимает эта операция?
1) имхо, биллинг надо выключать на время такой операции
2) зависит от того сколько времени прошло от 1 числа текущего месяца, так как время копирования уйдет именно на данные появившиеся с 1 числа текущего месяца до дня когда запущена архивация
при копировании данных таблица не лочится, она лочится при удалении данных, а так как удаляем из неактивной уже таблицы то биллингу пофиг...

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

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

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

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

Сообщение Magnum72 »

mikkey finn писал(а):имелось в виду время, которое требуется на переименование таблицы и создание новой. Если Это происходит достаточно долго, то что произойдет, если биллинг попытается записать туда что-либо.
Время на переименование таблицы это мгновение. Мускул в это время будет складывать запросы в очередь в памяти. можно до нажедность вообще ненадолго залочить таблицу на запись

Vadislaus
Сообщения: 39
Зарегистрирован: Чт окт 12, 2006 12:20

Сообщение Vadislaus »

Вопрос: "архивированные" таблицы не участвуют в работе UTM? во всяком случае штатными средствами?

Дело в следующем: Мне надо перенести базу с одного сервера на другой, есть вариант репликации, но под эту операцию я задумал еще и обновиться с 5-ки до 6-ки, плюс перейти на utf8.
Если я покоцаю таблицы discount_transactions_all и discount_transactions_iptraffic_all (а не заархивирую), то что я потеряю? Трафик за предыдущие периоды + ?отчет диалап и впн?????

Заранее спасибо.

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

Сообщение kirush »

После нескольких часов:
[root@accounter2 /usr/local]# fg
./optimize.sh
Delete transactions from discount_transactions_all....
DBD::mysql::st execute failed: Lock wait timeout exceeded; try restarting transaction at ./optimize.sh line 71.
DBD::mysql::st execute failed: Lock wait timeout exceeded; try restarting transaction at ./optimize.sh line 71.

Как быть?

Han_s
Сообщения: 21
Зарегистрирован: Чт июн 28, 2007 09:55

Сообщение Han_s »

проблемы со временем из за неверной настройки скл.

у меня за ~10 минут уже 2 гига перенес в другую табличку...

Pulse
Сообщения: 945
Зарегистрирован: Вт окт 03, 2006 12:58

Сообщение Pulse »

поделитесь настройками?:)

AndrewE
Сообщения: 230
Зарегистрирован: Пн июл 17, 2006 07:38

Сообщение AndrewE »

Magnum72 писал(а):
Чего вы херней страдаете :)

бегин
ренаме discount_transactions_all в discount_transactions_all_хххх
смотрим автоинкремент ид у discount_transactions_all_хххх
креате табле discount_transactions_all с автоинкремент из discount_transactions_all_хххх
далее спокойно переносим маленький кусочек данных из discount_transactions_all_хххх в discount_transactions_all
тоже самое с discount_transactions_iptraffic_all
коммит

ЗЫ естесно данная операция должна быть строго ежемесячной
Пожалуйста по пунктам.

Как смотрим автоникремент?
Дальше как его устанавливаем для новой таблицы?
Ну и вопрос века:
"далее спокойно переносим маленький кусочек данных из"
что именно переносим?

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

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

AndrewE писал(а):
Magnum72 писал(а):
Чего вы херней страдаете :)

бегин
ренаме discount_transactions_all в discount_transactions_all_хххх
смотрим автоинкремент ид у discount_transactions_all_хххх
креате табле discount_transactions_all с автоинкремент из discount_transactions_all_хххх
далее спокойно переносим маленький кусочек данных из discount_transactions_all_хххх в discount_transactions_all
тоже самое с discount_transactions_iptraffic_all
коммит

ЗЫ естесно данная операция должна быть строго ежемесячной
Пожалуйста по пунктам.

Как смотрим автоникремент?
Говорят, что как-то так:

Код: Выделить всё

SELECT Auto_increment FROM information_schema.tables WHERE table_name='discount_transactions_iptraffic_all';
Дальше как его устанавливаем для новой таблицы?
Наверное, как-то так:
CREATE TABLE `discount_transactions_iptraffic_all` (
`id` int(11) NOT NULL default '0',
`account_id` int(11) default NULL,
`discount` double default NULL,
`discount_with_tax` double default NULL,
`service_id` int(11) default NULL,
`discount_period_id` int(11) default NULL,
`slink_id` int(11) default NULL,
`discount_date` int(11) default NULL,
`discount_date_hour` int(11) default NULL,
`discount_date_day` int(11) default NULL,
`discount_date_month` int(11) default NULL,
`t_class` int(11) default '0',
`base_cost` double default '0',
`ipid` int(11) default '0',
`bytes` bigint(20) default NULL,
`is_canceled` int(11) default '0',
`cancel_id` int(11) default '0',
KEY `first_dtr` (`discount_date`,`account_id`,`slink_id`),
KEY `my_dtr` (`discount_date`,`account_id`)
) ENGINE=MyISAM AUTO_INCREMENT=60726987 DEFAULT CHARSET=utf8
Ну и вопрос века:
"далее спокойно переносим маленький кусочек данных из"
что именно переносим?
С этим вопросом есть такая неувязка... Вообще есть запрос вида insert ... select ...
Он позволяет перетаскивать из таблицы в таблицу данные. У меня не опыта в выкручивании яиц таблицам с автоинкрементом и тестить лень. По идее - именно тот запрос который надо задать mysql-серверу.
В select в качестве критерия отбора надо задать время больше даты отсечения. То есть, если дата отсечения 1 дек 2008г 0:00:00, то соотв все записи, у которых discount_date > unix_timestamp('2008-12-01 00:00:00') надо переносить в свежесозданную таблицу.

PS: гуру от мускуля, поправьте, ежели что не так.

turik
Сообщения: 11
Зарегистрирован: Чт ноя 06, 2008 15:31

Сообщение turik »

Делал так.
rename table итд
далее
смотрим автоинкремент:

Код: Выделить всё

show create table discount_transactions_all_0811;
Далее новую создаем

Код: Выделить всё

create table discount_transactions_all like  discount_transactions_all_0811;
делаем ей автоинкремент

Код: Выделить всё

alter table discount_transactions_all AUTO_INCREMENT=195981061 ;
Ну и тоже самое для иптрафика

А запрос с инсертом и селектом вполне себе норм

Код: Выделить всё

insert into discount_transactions_all select * from discount_transactions_all_0811 where discount_date>=unix_timestamp('2008-12-01 00:00:00');
Чистим лишниее из архивной таблицы:

Код: Выделить всё

delete from discount_transactions_all_0811 where discount_date>=unix_timestamp('2008-12-01 00:00:00');
Данные сверял до и после манипуляций, все ок.

Аватара пользователя
MaxDM
Сообщения: 313
Зарегистрирован: Пн апр 03, 2006 10:26
Контактная информация:

Сообщение MaxDM »

UTM 5.2.1-006
PostgreSQL 8.2.7

Сделал архивирование списаний до 2008 года:

Код: Выделить всё

create table discount_transactions_all_2007 as select * from discount_transactions_all where discount_date < unix_timestamp&#40;'2008-01-01 00&#58;00&#58;00'&#41;;
create table discount_transactions_iptraffic_all_2007 as select * from discount_transactions_iptraffic_all where discount_date < unix_timestamp&#40;'2008-01-01 00&#58;00&#58;00'&#41;;
delete from discount_transactions_all where discount_date < unix_timestamp&#40;'2008-01-01 00&#58;00&#58;00'&#41;;
delete from discount_transactions_iptraffic_all where discount_date < unix_timestamp&#40;'2008-01-01 00&#58;00&#58;00'&#41;;
insert into archives &#40;archive_id, table_type, table_name, start_date, end_date&#41; values&#40;1, 1, 'discount_transactions_all_2007', 0, unix_timestamp&#40;'2008-01-01 00&#58;00&#58;00'&#41;&#41;;
insert into archives &#40;archive_id, table_type, table_name, start_date, end_date&#41; values&#40;1, 2, 'discount_transactions_iptraffic_all_2007', 0, unix_timestamp&#40;'2008-01-01 00&#58;00&#58;00'&#41;&#41;;
После этого ядро запускается и грузит проц на 100%, ЛК не открывается, админка не открывается.

turik
Сообщения: 11
Зарегистрирован: Чт ноя 06, 2008 15:31

Сообщение turik »

У меня archive_id в archives, на каждую запись разные, да и может start_date сделать более осязаемым чем 0.
А так не вижу причин чтобы оно сломалось.
юзаем мускл но разницы быть вроде не должно.

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

Сообщение Magnum72 »

MaxDM писал(а):UTM 5.2.1-006
PostgreSQL 8.2.7

Сделал архивирование списаний до 2008 года:

Код: Выделить всё

create table discount_transactions_all_2007 as select * from discount_transactions_all where discount_date < unix_timestamp&#40;'2008-01-01 00&#58;00&#58;00'&#41;;
create table discount_transactions_iptraffic_all_2007 as select * from discount_transactions_iptraffic_all where discount_date < unix_timestamp&#40;'2008-01-01 00&#58;00&#58;00'&#41;;
delete from discount_transactions_all where discount_date < unix_timestamp&#40;'2008-01-01 00&#58;00&#58;00'&#41;;
delete from discount_transactions_iptraffic_all where discount_date < unix_timestamp&#40;'2008-01-01 00&#58;00&#58;00'&#41;;
insert into archives &#40;archive_id, table_type, table_name, start_date, end_date&#41; values&#40;1, 1, 'discount_transactions_all_2007', 0, unix_timestamp&#40;'2008-01-01 00&#58;00&#58;00'&#41;&#41;;
insert into archives &#40;archive_id, table_type, table_name, start_date, end_date&#41; values&#40;1, 2, 'discount_transactions_iptraffic_all_2007', 0, unix_timestamp&#40;'2008-01-01 00&#58;00&#58;00'&#41;&#41;;
После этого ядро запускается и грузит проц на 100%, ЛК не открывается, админка не открывается.
Вы вообще вышенаписанное читаете? Все наоборот сделали, я зря логику приводил чтоли?

Ответить