Вопросы по архивированию таблиц в UTM 5.3-003
Вопросы по архивированию таблиц в UTM 5.3-003
Прочитал вот это:
http://www.netup.ru/UTM5/documentation/ ... ic-5.3-003
В связи с чем возникли следующие вопросы:
1) это можно как-то запустить по крону, или отныне админ сам себе крон?
2) в какую базу данных складываются архивные таблицы?
3) будут ли документироваться дальнейшие изменения в структуре архива и способах архивации отдельных таблиц?
4) написание собственных скриптов архивации отменено полностью?
http://www.netup.ru/UTM5/documentation/ ... ic-5.3-003
В связи с чем возникли следующие вопросы:
1) это можно как-то запустить по крону, или отныне админ сам себе крон?
2) в какую базу данных складываются архивные таблицы?
3) будут ли документироваться дальнейшие изменения в структуре архива и способах архивации отдельных таблиц?
4) написание собственных скриптов архивации отменено полностью?
Собственно отвечу 
1. Можно запускать ручками из админки, но только через 28 дней после предыдущего запуска. либо запускаем бинарник db_arhiver -a с любой периодичностью.
2. в той же бд создаются новые архивные таблицы, ссылки на них в таблице arhives. я потом пробовал ручками перетаскивать их в другую базу, косяков не отмечено
3. хз
4. смотри ответ на п. 4

1. Можно запускать ручками из админки, но только через 28 дней после предыдущего запуска. либо запускаем бинарник db_arhiver -a с любой периодичностью.
2. в той же бд создаются новые архивные таблицы, ссылки на них в таблице arhives. я потом пробовал ручками перетаскивать их в другую базу, косяков не отмечено
3. хз
4. смотри ответ на п. 4
Там просто, по крайней мере в MySQL. Четыре запроса, один создает такую же по структуре таблицу в другой базе, второй пересыпает туда данные, третий правит таблицу archives и четвертый удаляет исходную таблицу. И так для каждой таблички в архиве. Код скрипта можно, в общем-то, сделать один раз. Даже если потом в архив будут добавляться новые таблицы с неизвестной структурой.
В пределах одного хоста таблицы быстрее просто переместить в другую базуJAO писал(а):Там просто, по крайней мере в MySQL. Четыре запроса, один создает такую же по структуре таблицу в другой базе, второй пересыпает туда данные, третий правит таблицу archives и четвертый удаляет исходную таблицу. И так для каждой таблички в архиве. Код скрипта можно, в общем-то, сделать один раз. Даже если потом в архив будут добавляться новые таблицы с неизвестной структурой.
UTM 5.3-003-update10 после архивации списаний, не отрабатывают отчеты за период находящийся в архиве.
Судя по коду таблица архива определяется как а не .
Может кто-то сталкивался с похожей проблемой ?
UPD
Проблема решилась восстановлением базы из дампа и повторным обновлением структуры и индексов.
Код: Выделить всё
Jan 24 04:36:16 ?Debug : be9e8700 DBConnection_mysql: <0x240fea0> SQL SELECT query: SELECT id,start_date,end_date,periodic_type,next_discount_period_id,canonical_len,custom_duration,discount_interval, invoice_month FROM discount_periods WHERE id='12949'
Jan 24 04:36:16 ?Debug : be9e8700 DBConnection_mysql: <0x240fea0> SQL SELECT query: 1 rows in 0.155 sec
Jan 24 04:36:16 ?Debug : be9e8700 UTM5 DBA: t_start: <1435833842>, t_end: <1435920242>
Jan 24 04:36:16 ?Debug : be9e8700 DBConnection_mysql: <0x240fea0> SQL SELECT query: SELECT archive_id,start_date,end_date FROM archives ORDER BY id
Jan 24 04:36:16 ?Debug : be9e8700 DBConnection_mysql: <0x240fea0> SQL SELECT query: 12 rows in 0.000 sec
Jan 24 04:36:16 ?Debug : be9e8700 UTM5 DBA: archive_table_name: <dhs_sessions_log>
Jan 24 04:36:16 ?Debug : be9e8700 DBConnection_mysql: <0x240fea0> SQL SELECT query: SELECT id,account_id,slink_id,recv_date,last_update_date,Framed_IP_Address,Framed_IP_Address6,Framed_IP_Address6_ext,NAS_Port,Acct_Session_Id,NAS_Port_Type,User_Name,Service_Type,Framed_Protocol,NAS_IP_Address,NAS_IP_Address_ext,NAS_IP_Address_type,NAS_Id,Acct_Status_Type,Acct_Input_Packets,Acct_Input_Octets,Acct_Output_Packets,Acct_Output_Octets,Acct_Session_Time,Called_Station_Id,Calling_Station_Id,Acct_Input_Gigawords,Acct_Output_Gigawords,Acct_Terminate_Cause, flags FROM dhs_sessions_log WHERE account_id='1967' AND last_update_date>='1435833842' AND last_update_date<='1435920242'
Jan 24 04:36:16 ?Debug : be9e8700 DBConnection_mysql: <0x240fea0> SQL SELECT query: 0 rows in 0.001 sec
Jan 24 04:36:16 ?Debug : be9e8700 DBConnection_mysql: <0x240fea0> SQL SELECT query: SELECT dhs_sess_id,recv_date,account_id,trange_id,duration,base_cost,sum_cost FROM dhs_sessions_detail WHERE disc_per_id='12949' AND account_id='1967'
Jan 24 04:36:16 ?Debug : be9e8700 DBConnection_mysql: <0x240fea0> SQL SELECT query: 0 rows in 0.001 sec
Код: Выделить всё
<dhs_sessions_log>
Код: Выделить всё
dhs_sessions_log_1212914090_1453589041
Может кто-то сталкивался с похожей проблемой ?
UPD
Проблема решилась восстановлением базы из дампа и повторным обновлением структуры и индексов.