Проблема разрастания InnoDB таблиц discount_transactions_all

[G@rik]

Проблема разрастания InnoDB таблиц discount_transactions_all и discount_transactions_iptraffic_all в MySQL 5.0

Клиентов около 10000, за 2 месяца БД выросла на 40ГБ.
На данный момент размер таблиц 50ГБ и 60ГБ.

После архивирования таблиц способом от murano ( viewtopic.php?t=7353 ) не уменьшается объём файлов этих таблиц.
Приходится делать дамп (mysqldump), удалять таблицы и восстанавливать их из дампа.
Но делать так каждый раз с такими объёмными таблицами накладно (от 4 часов).

Кто нибудь решил эту проблему?

В официальной документации по MySQL 5.0 рассматривается данный вопрос: http://dev.mysql.com/doc/refman/5.0/en/ ... nting.html
Как я понял, данная проблема проявляется только у MySQL ветки 5.0.

Может быть стоит попробовать MySQL 5.1 или вообще октазаться от использования InnoDB для этих таблиц?

[Magnum72]

Проблема разрастания InnoDB таблиц discount_transactions_all и discount_transactions_iptraffic_all в MySQL 5.0

Клиентов около 10000, за 2 месяца БД выросла на 40ГБ.
На данный момент размер таблиц 50ГБ и 60ГБ.

После архивирования таблиц способом от murano ( viewtopic.php?t=7353 ) не уменьшается объём файлов этих таблиц.
Приходится делать дамп (mysqldump), удалять таблицы и восстанавливать их из дампа.
Но делать так каждый раз с такими объёмными таблицами накладно (от 4 часов).

Кто нибудь решил эту проблему?

В официальной документации по MySQL 5.0 рассматривается данный вопрос: http://dev.mysql.com/doc/refman/5.0/en/ ... nting.html
Как я понял, данная проблема проявляется только у MySQL ветки 5.0.

Может быть стоит попробовать MySQL 5.1 или вообще октазаться от использования InnoDB для этих таблиц?

Переведи эти таблицы в муисам, ничего не потеряешь.

[gtk]

Проблема разрастания InnoDB таблиц discount_transactions_all и discount_transactions_iptraffic_all в MySQL 5.0

Клиентов около 10000, за 2 месяца БД выросла на 40ГБ.
На данный момент размер таблиц 50ГБ и 60ГБ.

После архивирования таблиц способом от murano ( viewtopic.php?t=7353 ) не уменьшается объём файлов этих таблиц.
Приходится делать дамп (mysqldump), удалять таблицы и восстанавливать их из дампа.
Но делать так каждый раз с такими объёмными таблицами накладно (от 4 часов).

Кто нибудь решил эту проблему?

В официальной документации по MySQL 5.0 рассматривается данный вопрос: http://dev.mysql.com/doc/refman/5.0/en/ ... nting.html
Как я понял, данная проблема проявляется только у MySQL ветки 5.0.

Может быть стоит попробовать MySQL 5.1 или вообще октазаться от использования InnoDB для этих таблиц?

Переведи эти таблицы в муисам, ничего не потеряешь.

Мне кстати так никто и не объяснил. Какой максимальный размер тыблицы в myisam , в Mysql 5.0

[GMS]

Всю базу держу в MySAM.
Главная фишка - использование ежемесячной архивации быстрорастущих таблиц (на сайте NetUP описан принцип). В результате и основная база практически не разрастается (соотв. скорость обработки запросов не падает), и сохраняется доступ к данным предыдущих периодов.

[dk]

Мне кстати так никто и не объяснил. Какой максимальный размер тыблицы в myisam , в Mysql 5.0

http://dev.mysql.com/doc/refman/5.0/en/ ... limit.html

[littlesavage]

Проблема разрастания InnoDB таблиц discount_transactions_all и discount_transactions_iptraffic_all в MySQL 5.0

После архивирования таблиц способом от murano ( viewtopic.php?t=7353 ) не уменьшается объём файлов этих таблиц.
Приходится делать дамп (mysqldump), удалять таблицы и восстанавливать их из дампа.
Но делать так каждый раз с такими объёмными таблицами накладно (от 4 часов).

Вместо этого можно выполнять optimize table.

В mysql 5.1 есть partitioning. Кnо-нибудь пробовал ее в качестве альтернативы архивированию?

[JAO]

А у меня таблицы в InnoDB, но в конфиге опция innodb_file_per_table=1. С этой опцией команда OPTIMIZE TABLE работает на InnoDB таблицах. Версия MySQL 5.0.

[gravis]

В mysql 5.1 есть partitioning. Кnо-нибудь пробовал ее в качестве альтернативы архивированию?

сходу:
1. Partitioning не позволяет хранить данные в другой БД
2. mysqlcheck and myisamchk are not supported with partitioned tables
3. Не всякий запрос к таблице будет использовать оптимизацию partition prunning, а без нее мускл будет считывать данные со всех партиций по-очереди и искать нужные по условиям (WHERE). На фоне этого, жесткое разделение данных по таблицам, выглядит более приемлемо, ведь ядро UTM5 само решает из каких таблиц делать выборку.