Архивация таблиц списаний

[Rico-X]

Подтверждаю проблему, продолжаю пользоваться сторонним скриптом архивации, который отлично работает, хоть и умеет не все таблицы. Взяли бы за основу чужие наработки что-ли. Встроенный архиватор встает колом даже на маленькой тестовой базе.

[Magnum72]

Взял рассмотрение заявки 2015083110000023 под контроль. В ближайшее время специалист рассмотрит проблему по существу. Приношу извинения за задержку.

Оптимальный вариант:
Скрипт запускается (допустим) каждый час и копирует данные из рабочих в архивные таблицы, а первого числа скрипт кроме копирования, регистрирует архивы в UTM5.archives и производит удаление записей из рабочих таблиц.

Три пожелания:
1) Так как у нас ест собственные поля в таблицах, пусть скрипт берет текущую структуру рабочих таблиц
2) Так как мы дополнительно архивируем своим скриптом другие таблицы, то дать возможность передавать скрипту в качестве параметров название таблицы и столбец по которому считать.
3) Научится архивировать таблицы : messages, balance_history

[forgotten]

А откуда вообще такое ограничение как архивирование 1 раз в месяц?
Мы например архивируем раз в сутки. И всё прекрасно работает.

[Nik0n]

А откуда вообще такое ограничение как архивирование 1 раз в месяц?
Мы например архивируем раз в сутки. И всё прекрасно работает.

Можно уточнить. У Вас что на каждый день отдельная таблица или Вы добавляете данные в архивные таблицы и правите archives на актуальную дату recv_date ?

[forgotten]

А откуда вообще такое ограничение как архивирование 1 раз в месяц?
Мы например архивируем раз в сутки. И всё прекрасно работает.

Можно уточнить. У Вас что на каждый день отдельная таблица или Вы добавляете данные в архивные таблицы и правите archives на актуальную дату recv_date ?

Таблицы на месяц. Раз в сутки добавляем в них данные и обновляем дату в archives.

[maxxsoft]

Взял рассмотрение заявки 2015083110000023 под контроль. В ближайшее время специалист рассмотрит проблему по существу. Приношу извинения за задержку.

коллеги! есть новости по данному вопросу?

[Lex]

Взял рассмотрение заявки 2015083110000023 под контроль. В ближайшее время специалист рассмотрит проблему по существу. Приношу извинения за задержку.

коллеги! есть новости по данному вопросу?

Проблема зарегистрирована у разработчиков под номером 2684 и исправлена. Исправление войдёт в следующий апдейт, который в настоящий момент готовится к выпуску.

[Point]

А откуда вообще такое ограничение как архивирование 1 раз в месяц?
Мы например архивируем раз в сутки. И всё прекрасно работает.

Можно уточнить. У Вас что на каждый день отдельная таблица или Вы добавляете данные в архивные таблицы и правите archives на актуальную дату recv_date ?

Таблицы на месяц. Раз в сутки добавляем в них данные и обновляем дату в archives.

2 forgotten
А не поделитесь скриптом архивации?

[forgotten]

А откуда вообще такое ограничение как архивирование 1 раз в месяц?
Мы например архивируем раз в сутки. И всё прекрасно работает.

Можно уточнить. У Вас что на каждый день отдельная таблица или Вы добавляете данные в архивные таблицы и правите archives на актуальную дату recv_date ?

Таблицы на месяц. Раз в сутки добавляем в них данные и обновляем дату в archives.

2 forgotten
А не поделитесь скриптом архивации?

Он Вам не подойдет. Он написан для постгреса, там делается много всего специфического: создаются вьюшки, индексы, раздаются права, создание бекапа таблиц, копирование бекапов на удалённый сервер. Проще написать с нуля чем выпиливать из этого скрипта ненужное.

[Point]

Итак, обновление вышло, в итоге запуска ./db_archiver -a получили 12 архивных таблиц в этой же базе данных, id архива 56, и несмотря на ранее имеющиеся архивы (с 01.09.2012 по 01.09.2014) в отдельной базе UTM5H, данные архивы получились с 01.08.2007 по 01.09.2015

[Point]

2 serjk !
Можете поинтересоваться у писателей, каким образом утилита архивации вычисляет начало архива????
вызывает недоумение следующее:
первый запуск(21 сентября 2015) создался архив ID 56 дата 1175335578-1441047737(юникстайм)(31.03.2007 по 01.09.2015) допускаем, что ранее не производилась архивация всех необходимых в текущий момент таблиц.
второй запуск (5 октября 2015) создался архив ID 57 дата 1443078464_1443639723(юникстайм) это 12:07:44 24.09.2015 ?????? по 00:02:03 01.10.2015 откуда такая дата взялась????
Ради спортивного интереса запускаем из консоли ./db_arhiver -a
получаем 58-й архив с 1444044191 по 1444044191. почему с 5.10.2015 16:23:11 а не с 1 числа?

[Magnum72]

насколько я понял там следующая магия:

Из всех таблиц участвующих в архивировании выбираем максимальные даты, которые в дальнейшем и будут являться границами архива:

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

SELECT 
  MIN(u.begin),
  MAX(u._end) 
FROM
  (
  SELECT MIN(updated) AS BEGIN, MAX(updated) AS _end FROM dhcp_leases_log 
  UNION
  SELECT MIN(recv_date) AS BEGIN, MAX(recv_date) AS _end FROM dhs_sessions_log 
  UNION
  SELECT MIN(discount_date) AS BEGIN, MAX(discount_date) AS _end FROM discount_transactions_all 
  UNION
  SELECT MIN(discount_date) AS BEGIN, MAX(discount_date) AS _end FROM discount_transactions_iptraffic_all 
  UNION
  SELECT MIN(invoice_date) AS BEGIN, MAX(invoice_date) AS _end FROM invoices 
  UNION
  SELECT MIN(payment_enter_date) AS BEGIN, MAX(payment_enter_date) AS _end FROM payment_transactions 
  UNION
  SELECT MIN(recv_date) AS BEGIN, MAX(recv_date) AS _end FROM tel_sessions_log 
  UNION
  SELECT MIN(DATE) AS BEGIN, MAX(DATE) AS _end FROM user_log
  ) AS u;

[Magnum72]

Вообщем все что делает данный скрипт (предварительно создает копии структур таблиц подлежащих архивированию):

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

SQL SELECT query: SELECT max(archive_id) FROM archives;
SQL SELECT query: SHOW TABLES
SQL SELECT query: SELECT min(u.begin), max(u._end) FROM ( SELECT min(updated) AS begin,  max(updated) AS _end FROM dhcp_leases_log UNION  SELECT min(recv_date) AS begin,  max(recv_date) AS _end FROM dhs_sessions_log UNION  SELECT min(discount_date) AS begin,  max(discount_date) AS _end FROM discount_transactions_all UNION  SELECT min(discount_date) AS begin,  max(discount_date) AS _end FROM discount_transactions_iptraffic_all UNION  SELECT min(invoice_date) AS begin,  max(invoice_date) AS _end FROM invoices UNION  SELECT min(payment_enter_date) AS begin,  max(payment_enter_date) AS _end FROM payment_transactions UNION  SELECT min(recv_date) AS begin,  max(recv_date) AS _end FROM tel_sessions_log UNION  SELECT min(date) AS begin,  max(date) AS _end FROM user_log ) AS u;

SQL SELECT query: SHOW TABLE STATUS LIKE 'dhcp_leases_log'
SQL query: RENAME TABLES dhcp_leases_log TO dhcp_leases_log_1057003000_1444105323, dhcp_leases_log_tmp TO dhcp_leases_log;
SQL query: ALTER TABLE dhcp_leases_log AUTO_INCREMENT = 1;

SQL SELECT query: SHOW TABLE STATUS LIKE 'dhs_sessions_detail'
SQL query: RENAME TABLES dhs_sessions_detail TO dhs_sessions_detail_1057003000_1444105323, dhs_sessions_detail_tmp TO dhs_sessions_detail;
SQL query: ALTER TABLE dhs_sessions_detail AUTO_INCREMENT = 1;

SQL SELECT query: SHOW TABLE STATUS LIKE 'dhs_sessions_log'
SQL query: RENAME TABLES dhs_sessions_log TO dhs_sessions_log_1057003000_1444105323, dhs_sessions_log_tmp TO dhs_sessions_log;
SQL query: ALTER TABLE dhs_sessions_log AUTO_INCREMENT = 266563528;

SQL SELECT query: SHOW TABLE STATUS LIKE 'discount_transactions_all'
SQL query: RENAME TABLES discount_transactions_all TO discount_transactions_all_1057003000_1444105323, discount_transactions_all_tmp TO discount_transactions_all;
SQL query: ALTER TABLE discount_transactions_all AUTO_INCREMENT = 1911085126;

SQL SELECT query: SHOW TABLE STATUS LIKE 'discount_transactions_iptraffic_all'
SQL query: RENAME TABLES discount_transactions_iptraffic_all TO discount_transactions_iptraffic_all_1057003000_1444105323, discount_transactions_iptraffic_all_tmp TO discount_transactions_iptraffic_all;

SQL SELECT query: SHOW TABLE STATUS LIKE 'invoice_entry'
SQL query: RENAME TABLES invoice_entry TO invoice_entry_1057003000_1444105323, invoice_entry_tmp TO invoice_entry;
SQL query: ALTER TABLE invoice_entry AUTO_INCREMENT = 13318530;

SQL SELECT query: SHOW TABLE STATUS LIKE 'invoice_entry_details'
SQL query: RENAME TABLES invoice_entry_details TO invoice_entry_details_1057003000_1444105323, invoice_entry_details_tmp TO invoice_entry_details;
SQL query: ALTER TABLE invoice_entry_details AUTO_INCREMENT = 616663;

SQL SELECT query: SHOW TABLE STATUS LIKE 'invoices'
SQL query: RENAME TABLES invoices TO invoices_1057003000_1444105323, invoices_tmp TO invoices;
SQL query: ALTER TABLE invoices AUTO_INCREMENT = 8141062;

SQL SELECT query: SHOW TABLE STATUS LIKE 'payment_transactions'
SQL query: RENAME TABLES payment_transactions TO payment_transactions_1057003000_1444105323, payment_transactions_tmp TO payment_transactions;
SQL query: ALTER TABLE payment_transactions AUTO_INCREMENT = 13491029;

SQL SELECT query: SHOW TABLE STATUS LIKE 'tel_sessions_detail'
SQL query: RENAME TABLES tel_sessions_detail TO tel_sessions_detail_1057003000_1444105323, tel_sessions_detail_tmp TO tel_sessions_detail;
SQL query: ALTER TABLE tel_sessions_detail AUTO_INCREMENT = 5291788;

SQL SELECT query: SHOW TABLE STATUS LIKE 'tel_sessions_log'
SQL query: RENAME TABLES tel_sessions_log TO tel_sessions_log_1057003000_1444105323, tel_sessions_log_tmp TO tel_sessions_log;
SQL query: ALTER TABLE tel_sessions_log AUTO_INCREMENT = 8401099;

SQL SELECT query: SHOW TABLE STATUS LIKE 'user_log'
SQL query: RENAME TABLES user_log TO user_log_1057003000_1444105323, user_log_tmp TO user_log;
SQL query: ALTER TABLE user_log AUTO_INCREMENT = 23970381;

SQL query: INSERT INTO archives(archive_id,table_type,table_name,start_date,end_date) VALUES ('201508','9','dhcp_leases_log_1057003000_1444105323','1057003000','1444105323');
SQL query: INSERT INTO archives(archive_id,table_type,table_name,start_date,end_date) VALUES ('201508','6','dhs_sessions_detail_1057003000_1444105323','1057003000','1444105323');
SQL query: INSERT INTO archives(archive_id,table_type,table_name,start_date,end_date) VALUES ('201508','5','dhs_sessions_log_1057003000_1444105323','1057003000','1444105323');
SQL query: INSERT INTO archives(archive_id,table_type,table_name,start_date,end_date) VALUES ('201508','1','discount_transactions_all_1057003000_1444105323','1057003000','1444105323');
SQL query: INSERT INTO archives(archive_id,table_type,table_name,start_date,end_date) VALUES ('201508','2','discount_transactions_iptraffic_all_1057003000_1444105323','1057003000','1444105323');
SQL query: INSERT INTO archives(archive_id,table_type,table_name,start_date,end_date) VALUES ('201508','11','invoice_entry_1057003000_1444105323','1057003000','1444105323');
SQL query: INSERT INTO archives(archive_id,table_type,table_name,start_date,end_date) VALUES ('201508','12','invoice_entry_details_1057003000_1444105323','1057003000','1444105323');
SQL query: INSERT INTO archives(archive_id,table_type,table_name,start_date,end_date) VALUES ('201508','10','invoices_1057003000_1444105323','1057003000','1444105323');
SQL query: INSERT INTO archives(archive_id,table_type,table_name,start_date,end_date) VALUES ('201508','7','payment_transactions_1057003000_1444105323','1057003000','1444105323');
SQL query: INSERT INTO archives(archive_id,table_type,table_name,start_date,end_date) VALUES ('201508','4','tel_sessions_detail_1057003000_1444105323','1057003000','1444105323');
SQL query: INSERT INTO archives(archive_id,table_type,table_name,start_date,end_date) VALUES ('201508','3','tel_sessions_log_1057003000_1444105323','1057003000','1444105323');
SQL query: INSERT INTO archives(archive_id,table_type,table_name,start_date,end_date) VALUES ('201508','8','user_log_1057003000_1444105323','1057003000','1444105323');

[Magnum72]

Основные претензии:
1) Нельзя указать базу где хранить архивные таблицы
2) Нельзя в момент архивации определить диапазон дат за который делать архив, идентификатор и префикс архива
3) В момент архивации будут теряться данные, так как таблицы не лочатся.

У нас например идентификатор архива это 201509 (год и месяц), он же префикс, т. е. архив имеет вид UTM5H.user_log_201509. Согласитесь это гораздо удобнее чем dhs_sessions_detail_1057003000_1444105323

[cyb3r_ang31]

Господа, пишу свой скрипт для архивирования таблиц для версии биллинга от 5.3-002 методом переноса данных в архивные таблицы, а не методом копирования таблиц (как в официальной утилите к 5.3-003).
И если с простыми несвязанными таблицами все понятно, то вот со связанными таблицами чуть сложнее.

Возможно ли архивировать так сказать "на лету" таблицы tel_sessions_log, tel_sessions_detail, dhs_sessions_log, dhs_sessions_detail, invoices, invoice_entry, invoice_entry_details вот такими наборами запросов:

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

CREATE TABLE IF NOT EXISTS tel_sessions_log_<postfix> LIKE tel_sessions_log
CREATE TABLE IF NOT EXISTS tel_sessions_detail_<postfix> LIKE tel_sessions_detail
INSERT INTO tel_sessions_log_<postfix> 
            SELECT * 
            FROM tel_sessions_log 
            WHERE `recv_date` >= <start_date_ts> 
            AND `recv_date` <= <end_date_ts>                                                              
DELETE FROM tel_sessions_log                                                                                                                           
            WHERE `recv_date` >= <start_date_ts> 
            AND `recv_date` <= <end_date_ts>                                                               
INSERT INTO tel_sessios_detail_<postfix>                                                                                                                  
            SELECT * 
            FROM tel_sessions_detail 
            WHERE `dhs_sess_id` IN &#40;
                       SELECT id
                       FROM tel_sessions_log_<postfix> 
            &#41;
DELETE FROM tel_sessions_detail WHERE `id` IN &#40;
            SELECT id
            FROM tel_sessions_detail_<postfix>
&#41;
INSERT INTO archives&#40;archive_id, table_type, table_name, start_date, end_date&#41; 
                           VALUES&#40;<archive_id>, 3, 'tel_sessions_log_<postfix>', <start_date_ts>, <end_date_ts>&#41;
INSERT INTO archives&#40;archive_id, table_type, table_name, start_date, end_date&#41; 
                           VALUES&#40;<archive_id>, 4, 'tel_sessions_detail_<postfix>', <start_date_ts>, <end_date_ts>&#41;

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

CREATE TABLE IF NOT EXISTS invoices_<postfix> LIKE invoices
CREATE TABLE IF NOT EXISTS invoice_entry_<postfix> LIKE invoice_entry
CREATE TABLE IF NOT EXISTS invoice_entry_details_<postfix> LIKE invoice_entry_details
INSERT INTO invoices_<postfix>
            SELECT * 
            FROM invoices 
            WHERE `invoice_date` >= <start_date_ts> 
            AND `invoice_date` <= <end_date_ts>
DELETE FROM invoices 
            WHERE `invoice_date` >= <start_date_ts> 
            AND `invoice_date` <= <end_date_ts>
INSERT INTO invoice_entry_<postfix> 
            SELECT * 
            FROM invoice_entry 
            WHERE `invoice_id` IN &#40;
                      SELECT id
                      FROM invoices_<postfix> 
             &#41;
DELETE FROM invoice_entry WHERE `id` IN &#40;
            SELECT id
            FROM invoice_entry_<postfix>
&#41;
INSERT INTO invoice_entry_details_<postfix> 
             SELECT * 
             FROM invoice_entry_details 
             WHERE `entry_id` IN &#40;
                         SELECT id
                         FROM invoice_entry_<postfix> 
             &#41;
DELETE FROM invoice_entry_details WHERE `id` IN &#40;
             SELECT id
             FROM invoice_entry_details_<postfix>
&#41;
INSERT INTO archives&#40;archive_id, table_type, table_name, start_date, end_date&#41; 
                           VALUES&#40;archive_id, 10, 'invoices_<postfix>', <start_date_ts>, <end_date_ts>&#41;
INSERT INTO archives&#40;archive_id, table_type, table_name, start_date, end_date&#41; 
                           VALUES&#40;archive_id, 11, 'invoice_entry_<postfix>', <start_date_ts>, <end_date_ts>&#41;
INSERT INTO archives&#40;archive_id, table_type, table_name, start_date, end_date&#41; 
                           VALUES&#40;archive_id, 12, 'invoice_entry_details_<postfix>', <start_date_ts>, <end_date_ts>&#41;

Я правильно понимаю логику связанности этих таблиц?
Подойдут такие наборы запросов для архивирования этих таблиц на лету, конечно же в рамках некой транзакции.
Какие еще подводные камни могут быть при таком способе архивирования?

Обещаю поделиться с сообществом своей поделкой для архивирования.