UTM5.archives

kirush · Сообщение **kirush** » Ср дек 02, 2009 03:55

mysql> SELECT *
-> FROM `archives`
-> ;

+----+------------+------------+------------------------------------------------------+------------+------------+
| id | archive_id | table_type | table_name                                           | start_date | end_date   |
+----+------------+------------+------------------------------------------------------+------------+------------+
|  1 |          1 |          1 | UTM5H.discount_transactions_all_1225573200           | 1183233600 | 1225573199 |
|  2 |          1 |          2 | UTM5H.discount_transactions_iptraffic_all_1225573200 | 1183233736 | 1225573199 |
|  3 |          2 |          1 | UTM5H.discount_transactions_all_1228078800           | 1057003558 | 1228078799 |
|  4 |          2 |          2 | UTM5H.discount_transactions_iptraffic_all_1228078800 | 1225573200 | 1228078799 |
|  5 |          3 |          1 | UTM5H.discount_transactions_all_1233435600           | 1228078800 | 1233435599 |
|  6 |          3 |          2 | UTM5H.discount_transactions_iptraffic_all_1233435600 | 1228078800 | 1233435599 |
|  7 |          4 |          1 | UTM5H.discount_transactions_all_1235854800           | 1233435600 | 1235854799 |
|  8 |          4 |          2 | UTM5H.discount_transactions_iptraffic_all_1235854800 | 1233435600 | 1235854799 |
|  9 |          5 |          1 | UTM5H.discount_transactions_all_1238529600           | 1235854800 | 1238529599 |
| 10 |          5 |          2 | UTM5H.discount_transactions_iptraffic_all_1238529600 | 1235854800 | 1238529599 |
| 11 |          6 |          1 | UTM5H.discount_transactions_all_1241121600           | 1238530439 | 1241121599 |
| 12 |          6 |          2 | UTM5H.discount_transactions_iptraffic_all_1241121600 | 1238530439 | 1241121599 |
| 13 |          1 |          5 | UTM5H.dhs_sessions_log_200904                        | 1057003834 | 1241118032 |
| 14 |          1 |          0 | UTM5H.messages_200904                                | 1240467122 | 1241121432 |
| 15 |          7 |          1 | UTM5H.discount_transactions_all_1243800000           | 1241121600 | 1243827001 |
| 16 |          7 |          2 | UTM5H.discount_transactions_iptraffic_all_1243800000 | 1241121600 | 1243827001 |
| 18 |          2 |          5 | UTM5H.dhs_sessions_log_200905                        | 1241132163 | 1243799974 |
| 19 |          2 |          0 | UTM5H.messages_200905                                | 1241121600 | 1243799501 |
| 20 |          8 |          1 | UTM5H.discount_transactions_all_1246392000           | 1243827002 | 1246391999 |
| 21 |          8 |          2 | UTM5H.discount_transactions_iptraffic_all_1246392000 | 1243800000 | 1246343404 |
| 22 |          9 |          1 | UTM5H.discount_transactions_all_1249070400           | 1246392000 | 1249070399 |
| 23 |          9 |          2 | UTM5H.discount_transactions_iptraffic_all_1249070400 | 1246394314 | 1249048418 |
| 24 |         10 |          1 | UTM5H.discount_transactions_all_20090821             | 1249070400 | 1250849328 |
| 25 |         10 |          2 | UTM5H.discount_transactions_iptraffic_all_20090821   | 1249070400 | 1250849328 |
| 26 |          3 |          5 | UTM5H.dhs_sessions_log_20090821                      | 1243800013 | 1250849325 |
| 27 |          1 |          6 | UTM5H.dhs_sessions_detail_20090821                   | 1243800013 | 1250849325 |
| 28 |         13 |          7 | UTM5H.payment_transactions_20090821                  | 1036627807 | 1250848972 |
| 29 |          4 |          5 | UTM5H.dhs_sessions_log_200909                        | 1250849568 | 1254340797 |
| 30 |          3 |          0 | UTM5H.messages_200909                                | 1243800001 | 1254340024 |
| 31 |         11 |          1 | UTM5H.discount_transactions_all_200909               | 1250849605 | 1254340799 |
| 32 |         11 |          2 | UTM5H.discount_transactions_iptraffic_all_200909     | 1250849605 | 1254340799 |
| 33 |          5 |          5 | UTM5H.dhs_sessions_log_200910                        | 1254340801 | 1257022745 |
| 34 |         12 |          0 | UTM5H.messages_200910                                | 1254340825 | 1257020946 |
| 35 |         12 |          1 | UTM5H.discount_transactions_all_200910               | 1254340808 | 1257022799 |
| 36 |         12 |          2 | UTM5H.discount_transactions_iptraffic_all_200910     | 1254340808 | 1257022799 |
| 37 |          6 |          5 | UTM5H.dhs_sessions_log_200911                        | 1257022819 | 1259614765 |
| 38 |         13 |          0 | UTM5H.messages_200911                                | 1257022805 | 1259612763 |
| 39 |         13 |          1 | UTM5H.discount_transactions_all_200911               | 1257022800 | 1259614799 |
| 40 |         13 |          2 | UTM5H.discount_transactions_iptraffic_all_200911     | 1257022800 | 1259614799 |
+----+------------+------------+------------------------------------------------------+------------+------------+

Подскажите как правильно расставить archive_id, а то то часть отчетов по ВПН, то часть отчётов по платежам пропадёт. Играюсь с цифрами, появляется то одна часть, то другая. Как восстановить правильную последовательность?

JAO · Сообщение **JAO** » Ср дек 02, 2009 08:01

Для всей группы архивных таблиц за какой-то промежуток времени обязателен одинаковый archive_id и разный table_type, желателен одинаковый start_date и end_date. Это идеальный вариант. Если такое не выйдет совершенно, значит в этот archive_id не надо включать таблицу этого типа или же порубить ее руками на части под нужный диапазон времени. У вас разные границы по времени, поэтому игры такие и наблюдаются скорее всего.

Вот, к примеру, у dhs_sessions_log за ноябрь 2009 года archive_id должен быть 13, а не 6. Если ядро строит временные диапазоны и связывает их с archive_id, то вы рискуете отчет ВПН за ноябрь вообще не увидеть, либо ядро будет с ума сходить от такого расчета времени и показывать всякую чушь.

UPDATE archives SET archive_id=13 WHERE id=37;
UPDATE archives SET archive_id=12 WHERE id=33;
UPDATE archives SET archive_id=11 WHERE id=30;
UPDATE archives SET archive_id=11 WHERE id=29;

Ход мысли ясен? А то, что у вас под id 28, что вы заворачивали в архив в августе (как раз с платежами связано), рекомендую разбить по месяцам вручную, создав разные таблицы (см. CREATE TABLE ... LIKE и INSERT INTO ... SELECT FROM) и дописать в archives ссылки. Можно и на одну таблицу прилепить несколько ссылок с разными start_date и end_date (главное чтоб внутри таблицы были записи с таким временем), работать должно, но это некрасиво и не для того архивация придумана.

kirush · Сообщение **kirush** » Ср дек 02, 2009 08:47

JAO, как всегда Ваш ответ развернут и понятен. Спасибо.
То что под id=25-28 было сделано сотрудниками Netup

, после этого как раз начались всплывать глюки, начал уже менять archive_id, играться...
Была не понятно логика формирования archive_id

Витька

А я когда архивацию настраивал, поступил проще. Точнее, сам того не подозревая, при выборе способа задания archive_id я обезопасил себя от подобных проблем

У меня все archive_id представляют собой шестизначное число в формате годмесяц, то есть 200801, 200912 и т.д. Никто не же не ограничивает нас в том, как этот id задавать. Зато теперь я могу быть уверен, что для одного месяца он совпадёт у всех архивных таблиц того периода.

JAO · Сообщение **JAO** » Ср дек 02, 2009 09:12

Самое главное, чтобы start_date и end_date были уникальными для каждого archive_id, то есть чтобы периоды не пересекались. Тогда не будет заскоков. Еще один момент, не знаю правда, насколько он нужен, но на всякий случай. Я выравниваю эти значения по границе суток.

kirush · Сообщение **kirush** » Ср дек 02, 2009 09:51

JAO писал(а): Ход мысли ясен? А то, что у вас под id 28, что вы заворачивали в архив в августе (как раз с платежами связано), рекомендую разбить по месяцам вручную, создав разные таблицы (см. CREATE TABLE ... LIKE и INSERT INTO ... SELECT FROM) и дописать в archives ссылки. Можно и на одну таблицу прилепить несколько ссылок с разными start_date и end_date (главное чтоб внутри таблицы были записи с таким временем), работать должно, но это некрасиво и не для того архивация придумана.

28 | 13 | 7 | UTM5H.payment_transactions_20090821 | 1036627807 | 1250848972
Делаю следующим способом:

create table payment_transactions_125573199 like payment_transactions_20090821;

теперь хочу из payment_transactions_20090821 выдрать всё с 118233600 по 125573199
как правильно сделать, чтобы в новую таблицу (payment_transactions_125573199) всё запихалось с ID=1, а в старой (payment_transactions_20090821) удалить всё что перенесено, и заново запустить нумерацию ID начиная с 1.
(выборка будет делаться по полю: payment_enter_date)

JAO · Сообщение **JAO** » Ср дек 02, 2009 15:08

А не надо ему Id ломать, пусть накручивает своим чередом. Если не нужен primary key в архиве, можно его прибить через ALTER TABLE, маленько место сэкономите. Дальше надо сделать:

1) INSERT INTO payment_transactions_125573199 SELECT * FROM payment_transactions_20090821 WHERE payment_enter_date>=118233600 AND payment_enter_date<=125573199
2) DELETE FROM payment_transactions_20090821 WHERE payment_enter_date>=118233600 AND payment_enter_date<=125573199
3) OPTIMIZE TABLE payment_transactions_20090821 (это есть толк если MyISAM либо InnoDB с file_per_table=1)
4) INSERT INTO archives (archive_id,table_type,table_name,table_name,start_date,end_date) VALUES (<ваш id>,7,'payment_transactions_125573199',118233600,125573199)

И так по кругу для каждого куска данных. Если таблица payment_transactions_20090821 еще подцеплена к архиву, то еще нужно подправить запись в archives для payment_transactions_20090821, вытаскивая новый start_date и end_date вот так:

SELECT MIN(payment_enter_date),MAX(payment_enter_date) FROM payment_transactions_20090821

Полученные два значения вставляются в archives через UPDATE соответствующей записи. Если же эта таблица выведена из архива, то подправлять ее запись в archives не надо (логично). Тогда создаем следующую таблицу и проделываем действия, расписанные выше, пока все не расползется по требуемым периодам.

Вообще же архивные таблицы лучше перегнать в MyISAM, потому что транзакции там не нужны совершенно, запись в них не идет, и MySQL с ними быстрее работает.

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