Архивация таблиц списаний
Lex писал(а):Взял рассмотрение заявки 2015083110000023 под контроль. В ближайшее время специалист рассмотрит проблему по существу. Приношу извинения за задержку.
Оптимальный вариант:
Скрипт запускается (допустим) каждый час и копирует данные из рабочих в архивные таблицы, а первого числа скрипт кроме копирования, регистрирует архивы в UTM5.archives и производит удаление записей из рабочих таблиц.
Три пожелания:
1) Так как у нас ест собственные поля в таблицах, пусть скрипт берет текущую структуру рабочих таблиц
2) Так как мы дополнительно архивируем своим скриптом другие таблицы, то дать возможность передавать скрипту в качестве параметров название таблицы и столбец по которому считать.
3) Научится архивировать таблицы : messages, balance_history
-
- Сообщения: 77
- Зарегистрирован: Пн сен 14, 2009 13:53
- Откуда: Екатеринбург
- Контактная информация:
Можно уточнить. У Вас что на каждый день отдельная таблица или Вы добавляете данные в архивные таблицы и правите archives на актуальную дату recv_date ?forgotten писал(а):А откуда вообще такое ограничение как архивирование 1 раз в месяц?
Мы например архивируем раз в сутки. И всё прекрасно работает.
Таблицы на месяц. Раз в сутки добавляем в них данные и обновляем дату в archives.Nik0n писал(а):Можно уточнить. У Вас что на каждый день отдельная таблица или Вы добавляете данные в архивные таблицы и правите archives на актуальную дату recv_date ?forgotten писал(а):А откуда вообще такое ограничение как архивирование 1 раз в месяц?
Мы например архивируем раз в сутки. И всё прекрасно работает.
- Lex
- NetUP Team
- Сообщения: 623
- Зарегистрирован: Ср мар 09, 2005 12:12
- Откуда: НетАП
- Контактная информация:
Проблема зарегистрирована у разработчиков под номером 2684 и исправлена. Исправление войдёт в следующий апдейт, который в настоящий момент готовится к выпуску.maxxsoft писал(а):коллеги! есть новости по данному вопросу?Lex писал(а):Взял рассмотрение заявки 2015083110000023 под контроль. В ближайшее время специалист рассмотрит проблему по существу. Приношу извинения за задержку.
2 forgottenforgotten писал(а):Таблицы на месяц. Раз в сутки добавляем в них данные и обновляем дату в archives.Nik0n писал(а):Можно уточнить. У Вас что на каждый день отдельная таблица или Вы добавляете данные в архивные таблицы и правите archives на актуальную дату recv_date ?forgotten писал(а):А откуда вообще такое ограничение как архивирование 1 раз в месяц?
Мы например архивируем раз в сутки. И всё прекрасно работает.
А не поделитесь скриптом архивации?
Он Вам не подойдет. Он написан для постгреса, там делается много всего специфического: создаются вьюшки, индексы, раздаются права, создание бекапа таблиц, копирование бекапов на удалённый сервер. Проще написать с нуля чем выпиливать из этого скрипта ненужное.Point писал(а):2 forgottenforgotten писал(а):Таблицы на месяц. Раз в сутки добавляем в них данные и обновляем дату в archives.Nik0n писал(а):Можно уточнить. У Вас что на каждый день отдельная таблица или Вы добавляете данные в архивные таблицы и правите archives на актуальную дату recv_date ?forgotten писал(а):А откуда вообще такое ограничение как архивирование 1 раз в месяц?
Мы например архивируем раз в сутки. И всё прекрасно работает.
А не поделитесь скриптом архивации?
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 числа?
Можете поинтересоваться у писателей, каким образом утилита архивации вычисляет начало архива????
вызывает недоумение следующее:
первый запуск(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 числа?
насколько я понял там следующая магия:
Из всех таблиц участвующих в архивировании выбираем максимальные даты, которые в дальнейшем и будут являться границами архива:
Из всех таблиц участвующих в архивировании выбираем максимальные даты, которые в дальнейшем и будут являться границами архива:
Код: Выделить всё
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: 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');
Основные претензии:
1) Нельзя указать базу где хранить архивные таблицы
2) Нельзя в момент архивации определить диапазон дат за который делать архив, идентификатор и префикс архива
3) В момент архивации будут теряться данные, так как таблицы не лочатся.
У нас например идентификатор архива это 201509 (год и месяц), он же префикс, т. е. архив имеет вид UTM5H.user_log_201509. Согласитесь это гораздо удобнее чем dhs_sessions_detail_1057003000_1444105323
1) Нельзя указать базу где хранить архивные таблицы
2) Нельзя в момент архивации определить диапазон дат за который делать архив, идентификатор и префикс архива
3) В момент архивации будут теряться данные, так как таблицы не лочатся.
У нас например идентификатор архива это 201509 (год и месяц), он же префикс, т. е. архив имеет вид UTM5H.user_log_201509. Согласитесь это гораздо удобнее чем dhs_sessions_detail_1057003000_1444105323
-
- Сообщения: 25
- Зарегистрирован: Сб авг 02, 2014 07:38
- Откуда: Красноярский край
- Контактная информация:
Господа, пишу свой скрипт для архивирования таблиц для версии биллинга от 5.3-002 методом переноса данных в архивные таблицы, а не методом копирования таблиц (как в официальной утилите к 5.3-003).
И если с простыми несвязанными таблицами все понятно, то вот со связанными таблицами чуть сложнее.
Возможно ли архивировать так сказать "на лету" таблицы tel_sessions_log, tel_sessions_detail, dhs_sessions_log, dhs_sessions_detail, invoices, invoice_entry, invoice_entry_details вот такими наборами запросов:
Я правильно понимаю логику связанности этих таблиц?
Подойдут такие наборы запросов для архивирования этих таблиц на лету, конечно же в рамках некой транзакции.
Какие еще подводные камни могут быть при таком способе архивирования?
Обещаю поделиться с сообществом своей поделкой для архивирования.
И если с простыми несвязанными таблицами все понятно, то вот со связанными таблицами чуть сложнее.
Возможно ли архивировать так сказать "на лету" таблицы 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 (
SELECT id
FROM tel_sessions_log_<postfix>
)
DELETE FROM tel_sessions_detail WHERE `id` IN (
SELECT id
FROM tel_sessions_detail_<postfix>
)
INSERT INTO archives(archive_id, table_type, table_name, start_date, end_date)
VALUES(<archive_id>, 3, 'tel_sessions_log_<postfix>', <start_date_ts>, <end_date_ts>)
INSERT INTO archives(archive_id, table_type, table_name, start_date, end_date)
VALUES(<archive_id>, 4, 'tel_sessions_detail_<postfix>', <start_date_ts>, <end_date_ts>)
Код: Выделить всё
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 (
SELECT id
FROM invoices_<postfix>
)
DELETE FROM invoice_entry WHERE `id` IN (
SELECT id
FROM invoice_entry_<postfix>
)
INSERT INTO invoice_entry_details_<postfix>
SELECT *
FROM invoice_entry_details
WHERE `entry_id` IN (
SELECT id
FROM invoice_entry_<postfix>
)
DELETE FROM invoice_entry_details WHERE `id` IN (
SELECT id
FROM invoice_entry_details_<postfix>
)
INSERT INTO archives(archive_id, table_type, table_name, start_date, end_date)
VALUES(archive_id, 10, 'invoices_<postfix>', <start_date_ts>, <end_date_ts>)
INSERT INTO archives(archive_id, table_type, table_name, start_date, end_date)
VALUES(archive_id, 11, 'invoice_entry_<postfix>', <start_date_ts>, <end_date_ts>)
INSERT INTO archives(archive_id, table_type, table_name, start_date, end_date)
VALUES(archive_id, 12, 'invoice_entry_details_<postfix>', <start_date_ts>, <end_date_ts>)
Подойдут такие наборы запросов для архивирования этих таблиц на лету, конечно же в рамках некой транзакции.
Какие еще подводные камни могут быть при таком способе архивирования?
Обещаю поделиться с сообществом своей поделкой для архивирования.