LINUX.ORG.RU
ФорумAdmin

mysql: активная и актуальная базы

 


0

2

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

Софтина только пишет, к примеру, rsyslog, или правит данные? Если только пишет, триггер на INSERT и ежедневное удаление устаревших записей в первой таблице.

riki ★★★★
()
Ответ на: комментарий от riki

Триггер, естественно, пишет вставленное во вторую базу.

riki ★★★★
()
Ответ на: комментарий от macumazan

Вот тебе чистящий мой скрипт для примера:

#!/bin/bash

database=Syslog
dbhost="localhost"
sqluser="Syslog"
password="********"
mysqld=/usr/bin/mysql

cat /usr/local/sbin/rsyslog/rsyslog-hosts.conf | while read line
do
    line2=$(echo $line | sed 's/[\._-]//g')
    export table=SystemEvents_$line2

    SQL_DELETE="DELETE FROM $table WHERE ReceivedAt < CURDATE() - INTERVAL 365 DAY;"
    SQL_OPT="OPTIMIZE TABLE $table;";

    $mysqld -u$sqluser -p$password -h$dbhost -e"$SQL_DELETE" -D$database
    $mysqld -u$sqluser -p$password -h$dbhost -e"$SQL_OPT" -D$database
done

Пробегает нужные таблицы (на самом деле список лучше получать из самого мускуля) и удаляет устаревшие по полю ReceivedAt записи.

riki ★★★★
()
Ответ на: комментарий от riki

Во время OPTIMIZE TABLE табличка успешно лочится и ваш софт курит бамбук. Тут неплохо бы юзать партишнинг, и удалять партиции целиком, это в том числе будет менее затратно по I/O для больших таблиц.

ventilator ★★★
()
Ответ на: комментарий от ventilator

Как раз сейчас накатываю MySQL 5.5, который умеет TRUNCATE TABLE. Думаю сделать 12 разделов и чистить по одному в месяц.

riki ★★★★
()
Ответ на: комментарий от ventilator

Да уже вся обвязка на мускуль заточена... Сделал партиции, перелил данные из живого сислога, грохнул пару месяцев - работает шустро. Задокументирую, пообедаю и буду переделывать боевое окружение :)

riki ★★★★
()

Почитал на тему Archive Storage Engine, вроде то, что надо, но пугает один момнет. Самая толстая таблица сейчас это

SELECT COUNT(*) FROM data ;
+----------+
| COUNT(*) |
+----------+
| 12186980 |
+----------+
1 row in set (22.87 sec)

Это за месяц примерно.

Пранируется хранить архив за год. Токлько вот есть вопрос, работать с такими большими данными за 1 год в Archive Storage Engine это очень большие тормоза?

macumazan ★★
() автор топика
Ответ на: комментарий от macumazan

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

ventilator ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.