Upgrade 1.8-2.0 c partitioning

[gdgsoft]

Прошу подсказать следующий момент по партицированию.

Желательно, что бы данные хранились хотя бы год. Ну есть такое желание у людей

Здесь http://www.zabbix.com/wiki/non-engli...oning_in_mysql
написано:
"Обратите внимание, что общее количество разбиений не может превышать 1024 ввиду внутренних ограничений MySQL".

К "ежедневному" разбитию предлагается 5 таблиц:
history
history_log
history_str
history_text
history_uint

Если предположить, что в среднем, каждый месяц в году имеет 31 дней, то общее количество партиций = 5(таблиц) * 31(дней) * 12(месяцев) = 1860 партиций.

Плюс, к этоу стоит прибавить месячные партиции для рекомендуемых 7 таблиц:
acknowledges
alerts
auditlog
events
service_alarms
trends
trends_unit

= 7(таблиц) * 12(месяцев) = 84 партиции.

Что суммарно дает 1944 партиций, что превышает лимит MySQL почти в 2 раза!!!

Собственно вопрос, можно ли при использовании партиций, как описано выше), хранить данные за год?
Если да, то где я ошибаюсь?

[dotneft]

Собственно вопрос, можно ли при использовании партиций, как описано выше), хранить данные за год?
Если да, то где я ошибаюсь?

А зачем вам точная история за год, и тенденции тоже за год? оО Может стоит месяца два хранить точных данных, а вот тенденции уже можно и год, и два хранить.

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

[dotneft]

Именно! Удобнее и быстрее по крону килять партицию и добавять новые чем отдавать все это на хаускипер.
Если уж такая параноя на муссор можно написать триггеры которые будут удалять "мусор" вместе с удаленными итемами
Ну или написать запрос который будет подчищать таблицы за удаленными итемами.

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

[gdgsoft]

А зачем вам точная история за год, и тенденции тоже за год? оО Может стоит месяца два хранить точных данных, а вот тенденции уже можно и год, и два хранить.

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

Тут есть момент.
Конечно, загрузка ЦП на серверах, достаточно и пары месяцев, HDD - вроде как тоже, полгода хватит что бы динамику заполнения отследить. Историю аварийных сообщений, которые собирались с внешних серверов ввиде строковых сообщений, наверное, тоже не стоит хранить больше чем пару месяцев.

Есть точки, которые включены по радиоканалу. Встречал людей, которые анализировали текущие проблемы на них по данным годичной давности, а именно: - листочки распускаются ровно через год и параметры ухудшаются в связи с этим. Вотт на деревья в результате и валят.

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

Вопрос еще вот в чем. Будет ли БД автоматически отслеживать количество партиций и удалять автоматически старые? Правильно ли я понимаю, что контроль количества партиций заложен в таблице "manage_partitions" уже с учетом ограничения мускула в 1024?

[dotneft]

Вопрос еще вот в чем. Будет ли БД автоматически отслеживать количество партиций и удалять автоматически старые? Правильно ли я понимаю, что контроль количества партиций заложен в таблице "manage_partitions" уже с учетом ограничения мускула в 1024?

Нет не будет. Все вручную. Или с помощью планировщика, о чем и написано в статье. Нет в таблице подобного не заложено. Да и какое право имеет какой то скрипт удалять по достижении 1024 партиций все должно быть в рамках планирования и расписания удаления партиций.

[gdgsoft]

Нет не будет. Все вручную. Или с помощью планировщика, о чем и написано в статье. Нет в таблице подобного не заложено. Да и какое право имеет какой то скрипт удалять по достижении 1024 партиций все должно быть в рамках планирования и расписания удаления партиций.

ОК. Спасибо.
Подскажите еще такой момент. Пытаюсь добавить планировщик из статьи и получаю ошибку:

mysql> DELIMITER $$
mysql> CREATE EVENT IF NOT EXISTS 'e_part_manage'
-> ON SCHEDULE EVERY 1 DAY
-> STARTS '2012-07-23 04:00:00'
-> ON COMPLETION PRESERVE
-> ENABLE
-> COMMENT 'Управление созданием и удалением секций'
-> DO BEGIN
-> CALL zabbix.drop_partitions('zabbix');
-> CALL zabbix.create_next_partitions('zabbix');
-> END
-> $$
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''e_part_manage'
ON SCHEDULE EVERY 1 DAY
STARTS '2012-07-23 04:00:0' at line 1
mysql>



Все процедуры созданы:
mysql> show procedure status \G
*************************** 1. row ********************
Db: zabbix
Name: create_next_partitions
Type: PROCEDURE
Definer: root@localhost
Modified: 2012-07-23 11:05:50
Created: 2012-07-23 11:05:50
Security_type: DEFINER
Comment:
character_set_client: utf8
collation_connection: utf8_general_ci
Database Collation: utf8_general_ci
*************************** 2. row *********************
Db: zabbix
Name: create_partition_by_day
Type: PROCEDURE
...
*************************** 3. row *********************
Db: zabbix
Name: create_partition_by_month
Type: PROCEDURE
...
*************************** 4. row *******************
Db: zabbix
Name: drop_old_partition
Type: PROCEDURE
...
*************************** 5. row *********************
Db: zabbix
Name: drop_partitions
Type: PROCEDURE
...

[gdgsoft]

Отвечу сам. Название события в ковычки брать не нужно. У меня так

[gdgsoft]

Не получается создать "первичную" пратицию для таблицы auditlog

Опять же, делаю все по инструкции:
http://www.zabbix.com/wiki/non-engli...oning_in_mysql

БД не патчилась. Ставится с нуля для 2.0. Для всех "рекомендованных" таблиц убил/создал ключи (пункт 3.1 пп 1.)
нарезал для всех таблиц партиции аля...

Для месячных:
ALTER TABLE `acknowledges` PARTITION BY RANGE ( clock)
(PARTITION p2012_08 VALUES LESS THAN (UNIX_TIMESTAMP("2012-09-01 00:00:00")) ENGINE = InnoDB);

Для дневных:
ALTER TABLE `history` PARTITION BY RANGE ( clock)
(PARTITION p2012_07_25 VALUES LESS THAN (UNIX_TIMESTAMP("2012-07-26 00:00:00")) ENGINE = InnoDB;


Но при выполнении:
ALTER TABLE `auditlog` PARTITION BY RANGE ( clock)
-> (PARTITION p2012_07 VALUES LESS THAN (UNIX_TIMESTAMP("2012-08-01 00:00:00")) ENGINE = InnoDB);

Ошибка: ERROR 1217 (23000): Cannot delete or update a parent row: a foreign key constraint fails

Команда:
SET foreign_key_checks = 0;
не помогла

Что подскажите?

[dotneft]

Убейте все constraints которые ссылаются на/с этой таблицы.

[camerondepalma]

Прошу помощи,
при попытке разбить таблицу с помощью запроса:

ALTER TABLE `history_uint` PARTITION BY RANGE ( clock)
( PARTITION p2012_11_14 VALUES LESS THAN (UNIX_TIMESTAMP("2012_11_13 00:00:00")) ENGINE = InnoDB,
PARTITION p2012_11_15 VALUES LESS THAN (UNIX_TIMESTAMP("2012_11_14 00:00:00")) ENGINE = InnoDB,
PARTITION p2012_11_16 VALUES LESS THAN (UNIX_TIMESTAMP("2012_11_15 00:00:00")) ENGINE = InnoDB);

возникают такие файлы в момент выполнения запроса:

#sql-5678_5f1#P#p2012_11_14.MYD
#sql-5678_5f1#P#p2012_11_14.MYI
#sql-5678_5f1#P#p2012_11_15.MYD
#sql-5678_5f1#P#p2012_11_15.MYI
#sql-5678_5f1#P#p2012_11_16.MYD
#sql-5678_5f1#P#p2012_11_16.MYI
#sql-5678_5f1.frm
#sql-5678_5f1.par

После окончания запроса файлы исчезают! Прошу помочь разобраться...
Таблицы MyISAM

[dotneft]

наверно потому что myISAM не поддерживает партиционирование

[camerondepalma]

myisamchk не поддерживается на партицированных таблицах (myisamchk are not supported with partitioned tables),
но таблица MyISAM может быть разбита на партиции.

[Mox]

Закомментить все FOREIGN keys, которые ссылаются/используются на партиционированных таблицах. MySQL не поддерживает их в связки с партиционированием! http://dev.mysql.com/doc/refman/5.1/...mitations.html

А как их закомментить?
Просто найти в скрипте апгреда все строчки и тупо их удалить?
Типа

sed -i '' -e 's/^.*FOREIGN\ KEY.*$//g' server/upgrades/dbpatches/2.0/mysql/patch.sql

[dotneft]

все не нужно. только те в которых упоминаются партиционируемые таблицы. Проще ручками их убить. Там буквально 8-10 alter table.

[Mox]

все не нужно. только те в которых упоминаются партиционируемые таблицы. Проще ручками их убить. Там буквально 8-10 alter table.

ой, точно.

Сейчас попробовал на тестовой машине такое обновление:

# diff -u /usr/local/share/zabbix2/server/upgrades/dbpatches/2.0/mysql/patch.sql.orig /usr/local/share/zabbix2/server/upgrades/dbpatches/2.0/mysql/patch.sql
--- /usr/local/share/zabbix2/server/upgrades/dbpatches/2.0/mysql/patch.sql.orig 2013-02-18 11:48:57.000000000 +0400
+++ /usr/local/share/zabbix2/server/upgrades/dbpatches/2.0/mysql/patch.sql      2013-02-20 11:03:59.000000000 +0400
@@ -3,8 +3,6 @@
                         MODIFY eventid bigint unsigned NOT NULL;
 DELETE FROM acknowledges WHERE NOT userid IN (SELECT userid FROM users);
 DELETE FROM acknowledges WHERE NOT eventid IN (SELECT eventid FROM events);
-ALTER TABLE acknowledges ADD CONSTRAINT c_acknowledges_1 FOREIGN KEY (userid) REFERENCES users (userid) ON DELETE CASCADE;
-ALTER TABLE acknowledges ADD CONSTRAINT c_acknowledges_2 FOREIGN KEY (eventid) REFERENCES events (eventid) ON DELETE CASCADE;
 ALTER TABLE actions
        MODIFY actionid bigint unsigned NOT NULL,
        MODIFY def_longdata text NOT NULL,
@@ -23,10 +21,6 @@
 DELETE FROM alerts WHERE NOT eventid IN (SELECT eventid FROM events);
 DELETE FROM alerts WHERE NOT userid IN (SELECT userid FROM users);
 DELETE FROM alerts WHERE NOT mediatypeid IN (SELECT mediatypeid FROM media_type);
-ALTER TABLE alerts ADD CONSTRAINT c_alerts_1 FOREIGN KEY (actionid) REFERENCES actions (actionid) ON DELETE CASCADE;
-ALTER TABLE alerts ADD CONSTRAINT c_alerts_2 FOREIGN KEY (eventid) REFERENCES events (eventid) ON DELETE CASCADE;
-ALTER TABLE alerts ADD CONSTRAINT c_alerts_3 FOREIGN KEY (userid) REFERENCES users (userid) ON DELETE CASCADE;
-ALTER TABLE alerts ADD CONSTRAINT c_alerts_4 FOREIGN KEY (mediatypeid) REFERENCES media_type (mediatypeid) ON DELETE CASCADE;
 ALTER TABLE applications MODIFY applicationid bigint unsigned NOT NULL,
                         MODIFY hostid bigint unsigned NOT NULL,
                         MODIFY templateid bigint unsigned NULL;
@@ -44,11 +38,9 @@
        MODIFY oldvalue text NOT NULL,
        MODIFY newvalue text NOT NULL;
 DELETE FROM auditlog_details WHERE NOT auditid IN (SELECT auditid FROM auditlog);
-ALTER TABLE auditlog_details ADD CONSTRAINT c_auditlog_details_1 FOREIGN KEY (auditid) REFERENCES auditlog (auditid) ON DELETE CASCADE;
 ALTER TABLE auditlog MODIFY auditid bigint unsigned NOT NULL,
                     MODIFY userid bigint unsigned NOT NULL;
 DELETE FROM auditlog WHERE NOT userid IN (SELECT userid FROM users);
-ALTER TABLE auditlog ADD CONSTRAINT c_auditlog_1 FOREIGN KEY (userid) REFERENCES users (userid) ON DELETE CASCADE;
 DROP INDEX autoreg_host_1 ON autoreg_host;
 CREATE INDEX autoreg_host_1 ON autoreg_host (proxy_hostid,host);
 ALTER TABLE autoreg_host MODIFY autoreg_hostid bigint unsigned NOT NULL,
@@ -1623,7 +1615,6 @@
 ALTER TABLE service_alarms MODIFY servicealarmid bigint unsigned NOT NULL,
                           MODIFY serviceid bigint unsigned NOT NULL;
 DELETE FROM service_alarms WHERE NOT serviceid IN (SELECT serviceid FROM services);
-ALTER TABLE service_alarms ADD CONSTRAINT c_service_alarms_1 FOREIGN KEY (serviceid) REFERENCES services (serviceid) ON DELETE CASCADE;
 ALTER TABLE services_links MODIFY linkid bigint unsigned NOT NULL,
                           MODIFY serviceupid bigint unsigned NOT NULL,
                           MODIFY servicedownid bigint unsigned NOT NULL;

Вроде прокатило