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

[mikkey finn]

у меня база в mysql, поэтому для постгресса не озадачивался. Мне это просто не надо...

[MaxDM]

у меня база в mysql, поэтому для постгресса не озадачивался. Мне это просто не надо...

Жаль. Щас резервный сервак в ремонте, привезут - обязательно попробую на постгресе. Потом расскажу что и как.

[mikkey finn]

http://www.java2s.com/Code/PostgreSQL/T ... atable.htm вот это сначала почитать, но не факт, что будет эффект как на Mysql. Это разный софт, принцип разный получается.

[gravis]

Таблицы ренеймить и создавать надо одной транзакцией

Есть идеи почему транзакции не работают?
Таблицы переименовываются до использования COMMIT :-/
Аналогично работает через perl. ENGINE у таблиц InnoDB.

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

mysql> show tables;
+------------------------------------------------+
| Tables_in_UTM5_TEST                            |
+------------------------------------------------+
| discount_transactions_all_1228064400           |
| discount_transactions_iptraffic_all_1228064400 |
+------------------------------------------------+
2 rows in set (0.00 sec)

mysql> SET autocommit=0;
Query OK, 0 rows affected (0.00 sec)

mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)

mysql> rename table discount_transactions_all_1228064400 to discount_transactions_all;
Query OK, 0 rows affected (0.00 sec)

mysql> rename table discount_transactions_iptraffic_all_1228064400 to discount_transactions_iptraffic_all;
Query OK, 0 rows affected (0.00 sec)

mysql> show tables;
+-------------------------------------+
| Tables_in_UTM5_TEST                 |
+-------------------------------------+
| discount_transactions_all           |
| discount_transactions_iptraffic_all |
+-------------------------------------+
2 rows in set (0.00 sec)

mysql> COMMIT;
Query OK, 0 rows affected (0.00 sec)

[Magnum72]

Таблицы ренеймить и создавать надо одной транзакцией

Есть идеи почему транзакции не работают?
Таблицы переименовываются до использования COMMIT :-/
Аналогично работает через perl. ENGINE у таблиц InnoDB.

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

mysql> show tables;
+------------------------------------------------+
| Tables_in_UTM5_TEST                            |
+------------------------------------------------+
| discount_transactions_all_1228064400           |
| discount_transactions_iptraffic_all_1228064400 |
+------------------------------------------------+
2 rows in set (0.00 sec)

mysql> SET autocommit=0;
Query OK, 0 rows affected (0.00 sec)

mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)

mysql> rename table discount_transactions_all_1228064400 to discount_transactions_all;
Query OK, 0 rows affected (0.00 sec)

mysql> rename table discount_transactions_iptraffic_all_1228064400 to discount_transactions_iptraffic_all;
Query OK, 0 rows affected (0.00 sec)

mysql> show tables;
+-------------------------------------+
| Tables_in_UTM5_TEST                 |
+-------------------------------------+
| discount_transactions_all           |
| discount_transactions_iptraffic_all |
+-------------------------------------+
2 rows in set (0.00 sec)

mysql> COMMIT;
Query OK, 0 rows affected (0.00 sec)

Таблицы залочить надо еще помоему.

[gravis]

Таблицы залочить надо еще помоему.

http://dev.mysql.com/doc/refman/5.0/en/ ... table.html говорит:

When you execute RENAME, you cannot have any locked tables or active transactions.

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

[freebeer]

Вопрос по скрипту и логике архивации.

Сначала переименовываются таблицы, затем создаются новые и биллинг продолжает писать в новые таблицы. Тем временем происходит перенос данных. Соответственно возникает фрагментация новой таблицы, так как старые записи вносятся параллельно с новыми. Так ли это (и сильно ли это будет влиять на производительность при innodb_file_per_table)? И если так - может быть создавать после переименования промежуточную таблицу с постфиксом current, переносить записи за текущий месяц, после чего вновь делать rename в уже окончательный вариант?

[lancelot]

по мотивам Магнума получилось примерно так:

#!/usr/bin/perl -w
use DBI;
use strict;
my $dbh; my $sth; my $ts; my @res; my $tmp;
# Обязательно сменить
my $dbuser='';
my $dbpass='';
my $dbhost='';
# Дальше лучше не менять
$dbh=DBI->connect("DBI:mysql:UTM5:$dbhost", $dbuser, $dbpass, {RaiseError=>1})
or die "\nConnection failed...\nError: $DBI::errstr\n";
$sth=$dbh->prepare("select unix_timestamp(concat(year(now()),'-',month(now()),'-01 00:00:00'))");
$sth->execute();
$ts=($sth->fetchrow_array)[0];
$dbh->do("rename table discount_transactions_all to discount_transactions_all_$ts");
$dbh->do("rename table discount_transactions_iptraffic_all to discount_transactions_iptraffic_all_$ts");
$sth=$dbh->prepare("show create table discount_transactions_iptraffic_all_$ts");
$sth->execute();
if (@res=$sth->fetchrow_array) {
$tmp= $res[1];
$tmp=~ s/discount_transactions_iptraffic_all_$ts/discount_transactions_iptraffic_all/g;
};
$dbh->do($tmp);
$sth=$dbh->prepare("show create table discount_transactions_all_$ts");
$sth->execute();
if (@res=$sth->fetchrow_array) {
$tmp= $res[1];
$tmp=~ s/discount_transactions_all_$ts/discount_transactions_all/g;
};
$dbh->do($tmp);
$dbh->do("insert into discount_transactions_all select * from discount_transactions_all_$ts where discount_date>=$ts");
$dbh->do("insert into discount_transactions_iptraffic_all select * from discount_transactions_iptraffic_all_$ts where discount_date>=$ts");
$dbh->do("delete from discount_transactions_all_$ts where discount_date>=$ts");
$dbh->do("delete from discount_transactions_iptraffic_all_$ts where discount_date>=$ts");
$sth=$dbh->prepare("select max(archive_id) from archives");
$sth->execute();
$tmp=($sth->fetchrow_array)[0];
$tmp+=1;
$dbh->do("insert into archives(archive_id,table_type,table_name,start_date,end_date) SELECT $tmp,1,".$dbh->quote("discount_transactions_all_$ts").",min(discount_date),max(discount_date) from discount_transactions_all_$ts");
$dbh->do("insert into archives(archive_id,table_type,table_name,start_date,end_date) SELECT $tmp,2,".$dbh->quote("discount_transactions_iptraffic_all_$ts").",min(discount_date),max(discount_date) from discount_transactions_iptraffic_all_$ts");

Комменты по багам приветствуются.

UPD: Исправлены баги. Спасиба Магнуму за комменты.

можно ли получить коментарий по данной операции архивирования.
зачем все это?

у меня таблицы в INNODB
discount_transactions_all
discount_transactions_iptraffic_all

скрипт отработал нормально... все работает как и прежде

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

так вот не понятно какие плюсы мы после этого получаем
и как собственно потом работать с этими архивными таблицами

[freebeer]

lancelot, http://www.netup.ru/articles.php?n=31

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

[lancelot]

1) Видел я эту статью и причем тут сам билинг и нетап, если этот скрипт написали сообща ребята соображающие в системе.
как бы не понятно чья заслуга то что появилась архивация...
причем от самих нетаповцов никаких скриптов не появилось а появилось лишь то что мол вот теперь можно архивировать.... а раньше собственно кто мешал?

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

[freebeer]

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

[mikkey finn]

Биллинг начиная с 5.2.1-006 умеет работать с архивами. Поэтому появляются эти скрипты. Нужен только этот скрипт, либо вы будете разгонять сервер БД постоянно. Все более мощное железо, все больше памяти, все более быстрые винты в самом скоростном рейде.
Это можно избежать скриптом.
В планах к нему еще вынос таблиц в архивную базу, которую надо бекапить раз в месяц. Плюс всем этим таблицам архивным смена движка и типа, с сортировкой и индексацией.

[lancelot]

mikkey finn
ну вот опять сбили с толку...

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

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

с уважением!

[Magnum72]

Биллинг начиная с 5.2.1-006 умеет работать с архивами. Поэтому появляются эти скрипты. Нужен только этот скрипт, либо вы будете разгонять сервер БД постоянно. Все более мощное железо, все больше памяти, все более быстрые винты в самом скоростном рейде.
Это можно избежать скриптом.
В планах к нему еще вынос таблиц в архивную базу, которую надо бекапить раз в месяц. Плюс всем этим таблицам архивным смена движка и типа, с сортировкой и индексацией.

Упс, а почему вы до сих пор этого не делаете? 90% смысла как раз чтобы держать архивные таблицы в соседней базе, я ее назвал UTM5H, соответственно в таблице arсhives пишем UTM5H.discount_transactions_iptraffic_all_01022009 вместо discount_transactions_iptraffic_all_01022009, ну и в конфиге MySQL в секции INNODB указываем что хранить будем table per file

[lancelot]

Мда.....если Magnum72 и mikkey finn друг друга понять не могут то кого слушать теперь?

где правильный вариант скрипта
какой использовать то?
первый от Magnum72
или
второй поменьше от mikkey finn