Oli Sennhauser

Hallo MySQL Gemeinde,

Im neuen iX (2012-10) hat es zwei nette Artikel über: MySQL HA-Lösungen (S. 116) und MySQL 5.6 (S. 66).

Viel Spass beim Lesen!

Taxonomy upgrade extras: High AvailabilityclusterMySQL Clustergalerareplikation

Hallo MySQL Gemeinde,

Im neuen iX (2012-10) hat es zwei nette Artikel über: MySQL HA-Lösungen (S. 116) und MySQL 5.6 (S. 66).

Viel Spass beim Lesen!

Taxonomy upgrade extras: High AvailabilityclusterMySQL Clustergalerareplikation

Taxonomy upgrade extras: High AvailabilityclusterMySQL Clustergalerareplikation

Hallo MySQL Gemeinde,

Im neuen iX (2012-10) hat es zwei nette Artikel über: MySQL HA-Lösungen (S. 116) und MySQL 5.6 (S. 66).

Viel Spass beim Lesen!

Aufgrund einer Kundenrückmeldung haben wir uns entschlossen unsere MySQL Nagios/Icinga Plugins um ein Plugin Galera Cluster für MySQL zu erweitern.

Das Modul prüft, ob der Knoten im Status Primary und ob die erwartete Anzahl von Galera Cluster Knoten vorhanden ist. Wenn nicht, wird eine Warnung oder ein Alarm zurückgemeldet.

Das Skript ist in Perl geschrieben und ist Nagios Plugin API v3.0 konform.

Ihr könnt es Euch von unserer Download Page herunterladen.

Wenn Ihr noch Verbesserungsvorschläge habt, bitte melden. Fehler können in unserer Bugs-Datenbank gemeldet werden.

Folgende Module sind im Paket enthalten:

• check_db_mysql.pl
• check_errorlog_mysql.pl
• check_galera_nodes.pl
• check_repl_mysql_cnt_slave_hosts.pl
• check_repl_mysql_hearbeat.pl
• check_repl_mysql_io_thread.pl
• check_repl_mysql_read_exec_pos.pl
• check_repl_mysql_readonly.pl
• check_repl_mysql_seconds_behind_master.pl
• check_repl_mysql_sql_thread.pl
• perf_mysql.pl

Taxonomy upgrade extras: galeramonitoringcluster

Aufgrund einer Kundenrückmeldung haben wir uns entschlossen unsere MySQL Nagios/Icinga Plugins um ein Plugin Galera Cluster für MySQL zu erweitern.

Das Modul prüft, ob der Knoten im Status Primary und ob die erwartete Anzahl von Galera Cluster Knoten vorhanden ist. Wenn nicht, wird eine Warnung oder ein Alarm zurückgemeldet.

Das Skript ist in Perl geschrieben und ist Nagios Plugin API v3.0 konform.

Ihr könnt es Euch von unserer Download Page herunterladen.

Wenn Ihr noch Verbesserungsvorschläge habt, bitte melden. Fehler können in unserer Bugs-Datenbank gemeldet werden.

Folgende Module sind im Paket enthalten:

• check_db_mysql.pl
• check_errorlog_mysql.pl
• check_galera_nodes.pl
• check_repl_mysql_cnt_slave_hosts.pl
• check_repl_mysql_hearbeat.pl
• check_repl_mysql_io_thread.pl
• check_repl_mysql_read_exec_pos.pl
• check_repl_mysql_readonly.pl
• check_repl_mysql_seconds_behind_master.pl
• check_repl_mysql_sql_thread.pl
• perf_mysql.pl

Taxonomy upgrade extras: galeramonitoringcluster

Taxonomy upgrade extras: galeramonitoringcluster

Aufgrund einer Kundenrückmeldung haben wir uns entschlossen unsere MySQL Nagios/Icinga Plugins um ein Plugin Galera Cluster für MySQL zu erweitern.

Das Modul prüft, ob der Knoten im Status Primary und ob die erwartete Anzahl von Galera Cluster Knoten vorhanden ist. Wenn nicht, wird eine Warnung oder ein Alarm zurückgemeldet.

Das Skript ist in Perl geschrieben und ist Nagios Plugin API v3.0 konform.

Ihr könnt es Euch von unserer Download Page herunterladen.

Wenn Ihr noch Verbesserungsvorschläge habt, bitte melden. Fehler können in unserer Bugs-Datenbank gemeldet werden.

Folgende Module sind im Paket enthalten:

• check_db_mysql.pl
• check_errorlog_mysql.pl
• check_galera_nodes.pl
• check_repl_mysql_cnt_slave_hosts.pl
• check_repl_mysql_hearbeat.pl
• check_repl_mysql_io_thread.pl
• check_repl_mysql_read_exec_pos.pl
• check_repl_mysql_readonly.pl
• check_repl_mysql_seconds_behind_master.pl
• check_repl_mysql_sql_thread.pl
• perf_mysql.pl

Es ist ein bekanntes Problem, dass das Ändern der Storage Engine von MyISAM nach InnoDB Probleme verursachen kann [ 1 ], wenn Abfragen der folgenden Art auftreten:

SELECT COUNT(*) from table;

Glücklicherweise kommt dieser Typ von Abfragen selten vor. Und wenn, kann die Abfrage meist einfach weggelassen oder darum herum gearbeitet werden, indem man die Anzahl Zeilen in der Tabelle schätzt. Zum Beispiel mit:

SHOW TABLE STATUS LIKE 'test';

Aber in einigen seltenen Fällen braucht der Kunde diese Werte aus bestimmten Gründen wirklich exakt. Um die Ressourcen des Servers mit dieser Abfrage, welche in manchen Fällen sehr oft abgesetzt werden kann, nicht zu erschöpfen, nutzen wir die Materialized Views und/oder Shadow Tabellen-Technik [ 2 ].

Das folgende Beispiel zeigt auf, wie dies umgesetzt werden kann.

Unsere ursprüngliche Situation

Wir haben eine Tabelle mit Angeboten, welche durch ein Host-System befüllt wird:

CREATE TABLE offer ( id int unsigned NOT NULL AUTO_INCREMENT , `type` CHAR(3) NOT NULL DEFAULT 'AAA' , data varchar(64) DEFAULT NULL , PRIMARY KEY (`id`) , INDEX (type) ) ENGINE=InnoDB; INSERT INTO offer VALUES (NULL, 'AAA', 'Blablabla'); INSERT INTO offer VALUES (NULL, 'ABC', 'Blablabla'); INSERT INTO offer VALUES (NULL, 'ZZZ', 'Blablabla');

Die Abfrage, welche wir absetzen wollen, schaut wie folgt aus:

SELECT COUNT(*) FROM offer;

Diese Abfrage wird bei InnoDB sehr teuer, wenn Zillionen von Zeilen in der Tabelle sind.

Die Lösung des Problems

Um das Problem zu lösen, legen wir eine Zähler-Tabelle an, in welcher wir die Zeilen zählen, welche auf der Angebots-Tabelle eingefügt, geändert oder gelöscht werden.

CREATE TABLE counter ( `type` char(3) NOT NULL DEFAULT 'AAA' , `count` MEDIUMINT UNSIGNED NOT NULL DEFAULT 0 , `ts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP , PRIMARY KEY (type) ) ENGINE=InnoDB;

Um unsere Zähler-Tabelle zu füllen, brauchen wir einen initialen Stand:

INSERT INTO counter SELECT type, COUNT(*), NULL FROM offer GROUP BY type; SELECT * FROM counter; SELECT COUNT(*) FROM counter; Unterhalt der Zähler-Tabelle

Um die Zähler-Tabelle aktuell zu halten, benötigen wir die 3 folgenden Trigger:

DROP TRIGGER IF EXISTS insert_offer_trigger; delimiter // CREATE TRIGGER insert_offer_trigger AFTER INSERT ON offer FOR EACH ROW BEGIN INSERT INTO counter VALUES (NEW.type, 1, NULL) ON DUPLICATE KEY UPDATE count = count + 1, ts = CURRENT_TIMESTAMP(); END; // delimiter ; DROP TRIGGER IF EXISTS update_offer_trigger; delimiter // CREATE TRIGGER update_offer_trigger AFTER UPDATE ON offer FOR EACH ROW BEGIN IF NEW.type = OLD.type THEN UPDATE counter SET ts = CURRENT_TIMESTAMP() WHERE type = NEW.type; ELSE UPDATE counter SET count = count - 1, ts = CURRENT_TIMESTAMP() WHERE type = OLD.type; INSERT INTO counter VALUES (NEW.type, 1, NULL) ON DUPLICATE KEY UPDATE count = count + 1, ts = CURRENT_TIMESTAMP(); END IF; END; // delimiter ; DROP TRIGGER IF EXISTS delete_offer_trigger; delimiter // CREATE TRIGGER delete_offer_trigger AFTER DELETE ON offer FOR EACH ROW BEGIN UPDATE counter SET count = count - 1 WHERE type = OLD.type; END; // delimiter ;

Jetzt können wir einige Fälle testen und die Resultate beider Tabellen vergleichen:

INSERT INTO offer VALUES (NULL, 'AAA', 'Blablabla'); INSERT INTO offer VALUES (NULL, 'AAA', 'Blablabla'); -- Single offer change UPDATE offer SET data = 'Single offer change' WHERE id = 2; -- Multi offer change UPDATE offer SET data = 'Multi offer change' WHERE type = 'AAA'; -- Single offer delete DELETE FROM offer WHERE id = 1; -- REPLACE (= DELETE / INSERT) REPLACE INTO offer VALUES (3, 'ZZZ', 'Single row replace'); -- New type INSERT INTO offer VALUES (NULL, 'DDD', 'Blablabla'); -- Change of type UPDATE offer SET type = 'ZZZ' where id = 2; -- Change of type to new type UPDATE offer SET type = 'YYY' where id = 3; -- INSERT on DUPLICATE KEY UPDATE INSERT INTO offer VALUES (7, 'DDD', 'ON DUPLICATE KEY UPDATE') ON DUPLICATE KEY UPDATE type = 'DDD', data = 'INSERT ON DUPLICATE KEY'; INSERT INTO offer VALUES (7, 'DDD', 'ON DUPLICATE KEY UPDATE') ON DUPLICATE KEY UPDATE type = 'DDD', data = 'UPDATE ON DUPLICATE KEY UPDATE'; SELECT * FROM offer; SELECT COUNT(*) FROM offer; SELECT * FROM counter; SELECT SUM(count) FROM counter;

Diese Lösung hat den Vorteil, dass wir für eine Abfrage nach der Anzahl Zeilen für einen bestimmten Bestellungs-Typ ebenfalls eine sehr schnelle Antwort erhalten. Diese Abfrage wäre auch für MyISAM Tabellen eine teure Operation...

SELECT `count` FROM counter WHERE `type` = 'DDD'; Taxonomy upgrade extras: innodbmaterialized viewsmaterialised viewsmyisamselectshadow tablecount

Es ist ein bekanntes Problem, dass das Ändern der Storage Engine von MyISAM nach InnoDB Probleme verursachen kann [ 1 ], wenn Abfragen der folgenden Art auftreten:

SELECT COUNT(*) from table;

Glücklicherweise kommt dieser Typ von Abfragen selten vor. Und wenn, kann die Abfrage meist einfach weggelassen oder darum herum gearbeitet werden, indem man die Anzahl Zeilen in der Tabelle schätzt. Zum Beispiel mit:

SHOW TABLE STATUS LIKE 'test';

Aber in einigen seltenen Fällen braucht der Kunde diese Werte aus bestimmten Gründen wirklich exakt. Um die Ressourcen des Servers mit dieser Abfrage, welche in manchen Fällen sehr oft abgesetzt werden kann, nicht zu erschöpfen, nutzen wir die Materialized Views und/oder Shadow Tabellen-Technik [ 2 ].

Das folgende Beispiel zeigt auf, wie dies umgesetzt werden kann.

Unsere ursprüngliche Situation

Wir haben eine Tabelle mit Angeboten, welche durch ein Host-System befüllt wird:

CREATE TABLE offer ( id int unsigned NOT NULL AUTO_INCREMENT , `type` CHAR(3) NOT NULL DEFAULT 'AAA' , data varchar(64) DEFAULT NULL , PRIMARY KEY (`id`) , INDEX (type) ) ENGINE=InnoDB; INSERT INTO offer VALUES (NULL, 'AAA', 'Blablabla'); INSERT INTO offer VALUES (NULL, 'ABC', 'Blablabla'); INSERT INTO offer VALUES (NULL, 'ZZZ', 'Blablabla');

Die Abfrage, welche wir absetzen wollen, schaut wie folgt aus:

SELECT COUNT(*) FROM offer;

Diese Abfrage wird bei InnoDB sehr teuer, wenn Zillionen von Zeilen in der Tabelle sind.

Die Lösung des Problems

Um das Problem zu lösen, legen wir eine Zähler-Tabelle an, in welcher wir die Zeilen zählen, welche auf der Angebots-Tabelle eingefügt, geändert oder gelöscht werden.

CREATE TABLE counter ( `type` char(3) NOT NULL DEFAULT 'AAA' , `count` MEDIUMINT UNSIGNED NOT NULL DEFAULT 0 , `ts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP , PRIMARY KEY (type) ) ENGINE=InnoDB;

Um unsere Zähler-Tabelle zu füllen, brauchen wir einen initialen Stand:

INSERT INTO counter SELECT type, COUNT(*), NULL FROM offer GROUP BY type; SELECT * FROM counter; SELECT COUNT(*) FROM counter; Unterhalt der Zähler-Tabelle

Um die Zähler-Tabelle aktuell zu halten, benötigen wir die 3 folgenden Trigger:

DROP TRIGGER IF EXISTS insert_offer_trigger; delimiter // CREATE TRIGGER insert_offer_trigger AFTER INSERT ON offer FOR EACH ROW BEGIN INSERT INTO counter VALUES (NEW.type, 1, NULL) ON DUPLICATE KEY UPDATE count = count + 1, ts = CURRENT_TIMESTAMP(); END; // delimiter ; DROP TRIGGER IF EXISTS update_offer_trigger; delimiter // CREATE TRIGGER update_offer_trigger AFTER UPDATE ON offer FOR EACH ROW BEGIN IF NEW.type = OLD.type THEN UPDATE counter SET ts = CURRENT_TIMESTAMP() WHERE type = NEW.type; ELSE UPDATE counter SET count = count - 1, ts = CURRENT_TIMESTAMP() WHERE type = OLD.type; INSERT INTO counter VALUES (NEW.type, 1, NULL) ON DUPLICATE KEY UPDATE count = count + 1, ts = CURRENT_TIMESTAMP(); END IF; END; // delimiter ; DROP TRIGGER IF EXISTS delete_offer_trigger; delimiter // CREATE TRIGGER delete_offer_trigger AFTER DELETE ON offer FOR EACH ROW BEGIN UPDATE counter SET count = count - 1 WHERE type = OLD.type; END; // delimiter ;

Jetzt können wir einige Fälle testen und die Resultate beider Tabellen vergleichen:

INSERT INTO offer VALUES (NULL, 'AAA', 'Blablabla'); INSERT INTO offer VALUES (NULL, 'AAA', 'Blablabla'); -- Single offer change UPDATE offer SET data = 'Single offer change' WHERE id = 2; -- Multi offer change UPDATE offer SET data = 'Multi offer change' WHERE type = 'AAA'; -- Single offer delete DELETE FROM offer WHERE id = 1; -- REPLACE (= DELETE / INSERT) REPLACE INTO offer VALUES (3, 'ZZZ', 'Single row replace'); -- New type INSERT INTO offer VALUES (NULL, 'DDD', 'Blablabla'); -- Change of type UPDATE offer SET type = 'ZZZ' where id = 2; -- Change of type to new type UPDATE offer SET type = 'YYY' where id = 3; -- INSERT on DUPLICATE KEY UPDATE INSERT INTO offer VALUES (7, 'DDD', 'ON DUPLICATE KEY UPDATE') ON DUPLICATE KEY UPDATE type = 'DDD', data = 'INSERT ON DUPLICATE KEY'; INSERT INTO offer VALUES (7, 'DDD', 'ON DUPLICATE KEY UPDATE') ON DUPLICATE KEY UPDATE type = 'DDD', data = 'UPDATE ON DUPLICATE KEY UPDATE'; SELECT * FROM offer; SELECT COUNT(*) FROM offer; SELECT * FROM counter; SELECT SUM(count) FROM counter;

Diese Lösung hat den Vorteil, dass wir für eine Abfrage nach der Anzahl Zeilen für einen bestimmten Bestellungs-Typ ebenfalls eine sehr schnelle Antwort erhalten. Diese Abfrage wäre auch für MyISAM Tabellen eine teure Operation...

SELECT `count` FROM counter WHERE `type` = 'DDD'; Taxonomy upgrade extras: innodbmaterialized viewsmaterialised viewsmyisamselectshadow tablecount

Taxonomy upgrade extras: innodbmaterialized viewsmaterialised viewsmyisamselectshadow tablecount

Es ist ein bekanntes Problem, dass das Ändern der Storage Engine von MyISAM nach InnoDB Probleme verursachen kann [ 1 ], wenn Abfragen der folgenden Art auftreten:

SELECT COUNT(*) from table;

Glücklicherweise kommt dieser Typ von Abfragen selten vor. Und wenn, kann die Abfrage meist einfach weggelassen oder darum herum gearbeitet werden, indem man die Anzahl Zeilen in der Tabelle schätzt. Zum Beispiel mit:

SHOW TABLE STATUS LIKE 'test';

Aber in einigen seltenen Fällen braucht der Kunde diese Werte aus bestimmten Gründen wirklich exakt. Um die Ressourcen des Servers mit dieser Abfrage, welche in manchen Fällen sehr oft abgesetzt werden kann, nicht zu erschöpfen, nutzen wir die Materialized Views und/oder Shadow Tabellen-Technik [ 2 ].

Das folgende Beispiel zeigt auf, wie dies umgesetzt werden kann.

Unsere ursprüngliche Situation

Wir haben eine Tabelle mit Angeboten, welche durch ein Host-System befüllt wird:

CREATE TABLE offer ( id int unsigned NOT NULL AUTO_INCREMENT , `type` CHAR(3) NOT NULL DEFAULT 'AAA' , data varchar(64) DEFAULT NULL , PRIMARY KEY (`id`) , INDEX (type) ) ENGINE=InnoDB; INSERT INTO offer VALUES (NULL, 'AAA', 'Blablabla'); INSERT INTO offer VALUES (NULL, 'ABC', 'Blablabla'); INSERT INTO offer VALUES (NULL, 'ZZZ', 'Blablabla');

Die Abfrage, welche wir absetzen wollen, schaut wie folgt aus:

SELECT COUNT(*) FROM offer;

Diese Abfrage wird bei InnoDB sehr teuer, wenn Zillionen von Zeilen in der Tabelle sind.

Die Lösung des Problems

Um das Problem zu lösen, legen wir eine Zähler-Tabelle an, in welcher wir die Zeilen zählen, welche auf der Angebots-Tabelle eingefügt, geändert oder gelöscht werden.

CREATE TABLE counter ( `type` char(3) NOT NULL DEFAULT 'AAA' , `count` MEDIUMINT UNSIGNED NOT NULL DEFAULT 0 , `ts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP , PRIMARY KEY (type) ) ENGINE=InnoDB;

Um unsere Zähler-Tabelle zu füllen, brauchen wir einen initialen Stand:

INSERT INTO counter SELECT type, COUNT(*), NULL FROM offer GROUP BY type; SELECT * FROM counter; SELECT COUNT(*) FROM counter; Unterhalt der Zähler-Tabelle

Um die Zähler-Tabelle aktuell zu halten, benötigen wir die 3 folgenden Trigger:

DROP TRIGGER IF EXISTS insert_offer_trigger; delimiter // CREATE TRIGGER insert_offer_trigger AFTER INSERT ON offer FOR EACH ROW BEGIN INSERT INTO counter VALUES (NEW.type, 1, NULL) ON DUPLICATE KEY UPDATE count = count + 1, ts = CURRENT_TIMESTAMP(); END; // delimiter ; DROP TRIGGER IF EXISTS update_offer_trigger; delimiter // CREATE TRIGGER update_offer_trigger AFTER UPDATE ON offer FOR EACH ROW BEGIN IF NEW.type = OLD.type THEN UPDATE counter SET ts = CURRENT_TIMESTAMP() WHERE type = NEW.type; ELSE UPDATE counter SET count = count - 1, ts = CURRENT_TIMESTAMP() WHERE type = OLD.type; INSERT INTO counter VALUES (NEW.type, 1, NULL) ON DUPLICATE KEY UPDATE count = count + 1, ts = CURRENT_TIMESTAMP(); END IF; END; // delimiter ; DROP TRIGGER IF EXISTS delete_offer_trigger; delimiter // CREATE TRIGGER delete_offer_trigger AFTER DELETE ON offer FOR EACH ROW BEGIN UPDATE counter SET count = count - 1 WHERE type = OLD.type; END; // delimiter ;

Jetzt können wir einige Fälle testen und die Resultate beider Tabellen vergleichen:

INSERT INTO offer VALUES (NULL, 'AAA', 'Blablabla'); INSERT INTO offer VALUES (NULL, 'AAA', 'Blablabla'); -- Single offer change UPDATE offer SET data = 'Single offer change' WHERE id = 2; -- Multi offer change UPDATE offer SET data = 'Multi offer change' WHERE type = 'AAA'; -- Single offer delete DELETE FROM offer WHERE id = 1; -- REPLACE (= DELETE / INSERT) REPLACE INTO offer VALUES (3, 'ZZZ', 'Single row replace'); -- New type INSERT INTO offer VALUES (NULL, 'DDD', 'Blablabla'); -- Change of type UPDATE offer SET type = 'ZZZ' where id = 2; -- Change of type to new type UPDATE offer SET type = 'YYY' where id = 3; -- INSERT on DUPLICATE KEY UPDATE INSERT INTO offer VALUES (7, 'DDD', 'ON DUPLICATE KEY UPDATE') ON DUPLICATE KEY UPDATE type = 'DDD', data = 'INSERT ON DUPLICATE KEY'; INSERT INTO offer VALUES (7, 'DDD', 'ON DUPLICATE KEY UPDATE') ON DUPLICATE KEY UPDATE type = 'DDD', data = 'UPDATE ON DUPLICATE KEY UPDATE'; SELECT * FROM offer; SELECT COUNT(*) FROM offer; SELECT * FROM counter; SELECT SUM(count) FROM counter;

Diese Lösung hat den Vorteil, dass wir für eine Abfrage nach der Anzahl Zeilen für einen bestimmten Bestellungs-Typ ebenfalls eine sehr schnelle Antwort erhalten. Diese Abfrage wäre auch für MyISAM Tabellen eine teure Operation...

SELECT `count` FROM counter WHERE `type` = 'DDD';

Weil wir auf einem unserer Server etwas knapp an Diskplatz sind, hatte ich die Idee, das MySQL Feature Datenkompression für InnoDB auszuprobieren. Dieses Feature ist nützlich, wenn Tabellen mit VARCHAR, BLOB oderr TEXT Attributen vorhanden sind.

Um es nicht allzu einfach zu machen ist unsere Tabelle auch noch partitioniert. Sie sieht wie folgt aus:

CREATE TABLE `history_str` ( `itemid` mediumint(8) unsigned NOT NULL DEFAULT '0', `clock` int(11) unsigned NOT NULL DEFAULT '0', `value` varchar(255) NOT NULL DEFAULT '', PRIMARY KEY (`itemid`,`clock`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 PARTITION BY RANGE (clock) (PARTITION p2012_kw05 VALUES LESS THAN (1328482800) ENGINE = InnoDB, PARTITION p2012_kw06 VALUES LESS THAN (1329087600) ENGINE = InnoDB, PARTITION p2012_kw07 VALUES LESS THAN (1329692400) ENGINE = InnoDB, PARTITION p2012_kw08 VALUES LESS THAN (1330297200) ENGINE = InnoDB, PARTITION p2012_kw09 VALUES LESS THAN (1330902000) ENGINE = InnoDB, PARTITION p2012_kw10 VALUES LESS THAN (1331506800) ENGINE = InnoDB, PARTITION p2012_kw11 VALUES LESS THAN (1332111600) ENGINE = InnoDB, PARTITION p2012_kw12 VALUES LESS THAN MAXVALUE ENGINE = InnoDB);

Und die Partitionen verbrauchen wie folgt Diskplatz (nicht wirklich viel, ich weiss!):

-rw-rw---- 1 mysql mysql 184549376 Mar 7 00:43 history_str#P#p2012_kw05.ibd -rw-rw---- 1 mysql mysql 209715200 Mar 14 00:11 history_str#P#p2012_kw06.ibd -rw-rw---- 1 mysql mysql 234881024 Mar 21 00:47 history_str#P#p2012_kw07.ibd -rw-rw---- 1 mysql mysql 226492416 Mar 23 16:39 history_str#P#p2012_kw08.ibd -rw-rw---- 1 mysql mysql 234881024 Mar 19 18:22 history_str#P#p2012_kw09.ibd -rw-rw---- 1 mysql mysql 289406976 Mar 19 18:22 history_str#P#p2012_kw10.ibd -rw-rw---- 1 mysql mysql 281018368 Mar 23 16:39 history_str#P#p2012_kw11.ibd -rw-rw---- 1 mysql mysql 213909504 Mar 23 17:23 history_str#P#p2012_kw12.ibd

Die Tabelle wurde mit den folgenden Werten komprimiert:

ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=4

Anschliessend schaut die Lage wie folgt aus:

-rw-rw---- 1 mysql mysql 7340032 Mar 23 17:33 history_str#P#p2012_kw05.ibd -rw-rw---- 1 mysql mysql 7340032 Mar 23 17:34 history_str#P#p2012_kw06.ibd -rw-rw---- 1 mysql mysql 8388608 Mar 23 17:36 history_str#P#p2012_kw07.ibd -rw-rw---- 1 mysql mysql 75497472 Mar 23 17:49 history_str#P#p2012_kw08.ibd -rw-rw---- 1 mysql mysql 104857600 Mar 23 17:44 history_str#P#p2012_kw09.ibd -rw-rw---- 1 mysql mysql 125829120 Mar 23 17:51 history_str#P#p2012_kw10.ibd -rw-rw---- 1 mysql mysql 125829120 Mar 23 17:57 history_str#P#p2012_kw11.ibd -rw-rw---- 1 mysql mysql 134217728 Mar 23 18:11 history_str#P#p2012_kw12.ibd

Wir erhalten somit eine Platzersparnis von 40 - 60%! Nicht allzu schlecht.

Aber spannend wäre auch noch den Einfluss auf den Speicher zu sehen:

SHOW GLOBAL STATUS LIKE 'innodb_buffer%'; +---------------------------------------+----------------------+ | Variable_name | Value | +---------------------------------------+----------------------+ | Innodb_buffer_pool_pages_data | 10769 | | Innodb_buffer_pool_pages_dirty | 6613 | | Innodb_buffer_pool_pages_free | 644 | | Innodb_buffer_pool_pages_misc | 18446744073709549802 | | Innodb_buffer_pool_pages_total | 9599 | +---------------------------------------+----------------------+

Diese Zahlen machen nicht wirklich Sinn. Zudem sind wir noch auf einen bekannten MySQL Bug #59550: Innodb_buffer_pool_pages_misc goes wrong gestossen.

Ein paar nette Grafen InnoDB Buffer Pool activity

Weil unser InnoDB Buffer Pool zu gross war, haben wir ihn etwas kleiner gemacht. Um das Barracuda File Format einzuschalten, haben wir anschliessend die Datenbank neu gestartet. Und dann sind die Zahlen amok gelaufen...

InnoDB compression time

Das erste mal, dass wir InnoDB Compression Time in unserem Monitor sehen... \o/

InnoDB Row operations

Und hier sehen Sie, wie wir die Konvertierung technisch gelöst haben... :-)

Taxonomy upgrade extras: tabledatainnodbpartitioncompress

Weil wir auf einem unserer Server etwas knapp an Diskplatz sind, hatte ich die Idee, das MySQL Feature Datenkompression für InnoDB auszuprobieren. Dieses Feature ist nützlich, wenn Tabellen mit VARCHAR, BLOB oderr TEXT Attributen vorhanden sind.

Um es nicht allzu einfach zu machen ist unsere Tabelle auch noch partitioniert. Sie sieht wie folgt aus:

CREATE TABLE `history_str` ( `itemid` mediumint(8) unsigned NOT NULL DEFAULT '0', `clock` int(11) unsigned NOT NULL DEFAULT '0', `value` varchar(255) NOT NULL DEFAULT '', PRIMARY KEY (`itemid`,`clock`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 PARTITION BY RANGE (clock) (PARTITION p2012_kw05 VALUES LESS THAN (1328482800) ENGINE = InnoDB, PARTITION p2012_kw06 VALUES LESS THAN (1329087600) ENGINE = InnoDB, PARTITION p2012_kw07 VALUES LESS THAN (1329692400) ENGINE = InnoDB, PARTITION p2012_kw08 VALUES LESS THAN (1330297200) ENGINE = InnoDB, PARTITION p2012_kw09 VALUES LESS THAN (1330902000) ENGINE = InnoDB, PARTITION p2012_kw10 VALUES LESS THAN (1331506800) ENGINE = InnoDB, PARTITION p2012_kw11 VALUES LESS THAN (1332111600) ENGINE = InnoDB, PARTITION p2012_kw12 VALUES LESS THAN MAXVALUE ENGINE = InnoDB);

Und die Partitionen verbrauchen wie folgt Diskplatz (nicht wirklich viel, ich weiss!):

-rw-rw---- 1 mysql mysql 184549376 Mar 7 00:43 history_str#P#p2012_kw05.ibd -rw-rw---- 1 mysql mysql 209715200 Mar 14 00:11 history_str#P#p2012_kw06.ibd -rw-rw---- 1 mysql mysql 234881024 Mar 21 00:47 history_str#P#p2012_kw07.ibd -rw-rw---- 1 mysql mysql 226492416 Mar 23 16:39 history_str#P#p2012_kw08.ibd -rw-rw---- 1 mysql mysql 234881024 Mar 19 18:22 history_str#P#p2012_kw09.ibd -rw-rw---- 1 mysql mysql 289406976 Mar 19 18:22 history_str#P#p2012_kw10.ibd -rw-rw---- 1 mysql mysql 281018368 Mar 23 16:39 history_str#P#p2012_kw11.ibd -rw-rw---- 1 mysql mysql 213909504 Mar 23 17:23 history_str#P#p2012_kw12.ibd

Die Tabelle wurde mit den folgenden Werten komprimiert:

ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=4

Anschliessend schaut die Lage wie folgt aus:

-rw-rw---- 1 mysql mysql 7340032 Mar 23 17:33 history_str#P#p2012_kw05.ibd -rw-rw---- 1 mysql mysql 7340032 Mar 23 17:34 history_str#P#p2012_kw06.ibd -rw-rw---- 1 mysql mysql 8388608 Mar 23 17:36 history_str#P#p2012_kw07.ibd -rw-rw---- 1 mysql mysql 75497472 Mar 23 17:49 history_str#P#p2012_kw08.ibd -rw-rw---- 1 mysql mysql 104857600 Mar 23 17:44 history_str#P#p2012_kw09.ibd -rw-rw---- 1 mysql mysql 125829120 Mar 23 17:51 history_str#P#p2012_kw10.ibd -rw-rw---- 1 mysql mysql 125829120 Mar 23 17:57 history_str#P#p2012_kw11.ibd -rw-rw---- 1 mysql mysql 134217728 Mar 23 18:11 history_str#P#p2012_kw12.ibd

Wir erhalten somit eine Platzersparnis von 40 - 60%! Nicht allzu schlecht.

Aber spannend wäre auch noch den Einfluss auf den Speicher zu sehen:

SHOW GLOBAL STATUS LIKE 'innodb_buffer%'; +---------------------------------------+----------------------+ | Variable_name | Value | +---------------------------------------+----------------------+ | Innodb_buffer_pool_pages_data | 10769 | | Innodb_buffer_pool_pages_dirty | 6613 | | Innodb_buffer_pool_pages_free | 644 | | Innodb_buffer_pool_pages_misc | 18446744073709549802 | | Innodb_buffer_pool_pages_total | 9599 | +---------------------------------------+----------------------+

Diese Zahlen machen nicht wirklich Sinn. Zudem sind wir noch auf einen bekannten MySQL Bug #59550: Innodb_buffer_pool_pages_misc goes wrong gestossen.

Ein paar nette Grafen InnoDB Buffer Pool activity

Weil unser InnoDB Buffer Pool zu gross war, haben wir ihn etwas kleiner gemacht. Um das Barracuda File Format einzuschalten, haben wir anschliessend die Datenbank neu gestartet. Und dann sind die Zahlen amok gelaufen...

InnoDB compression time

Das erste mal, dass wir InnoDB Compression Time in unserem Monitor sehen... \o/

InnoDB Row operations

Und hier sehen Sie, wie wir die Konvertierung technisch gelöst haben... :-)

Taxonomy upgrade extras: tabledatainnodbpartitioncompress

Taxonomy upgrade extras: tabledatainnodbpartitioncompressWeil wir auf einem unserer Server etwas knapp an Diskplatz sind, hatte ich die Idee, das MySQL Feature Datenkompression für InnoDB auszuprobieren. Dieses Feature ist nützlich, wenn Tabellen mit VARCHAR, BLOB oderr TEXT Attributen vorhanden sind.

Um es nicht allzu einfach zu machen ist unsere Tabelle auch noch partitioniert. Sie sieht wie folgt aus:

CREATE TABLE `history_str` ( `itemid` mediumint(8) unsigned NOT NULL DEFAULT '0', `clock` int(11) unsigned NOT NULL DEFAULT '0', `value` varchar(255) NOT NULL DEFAULT '', PRIMARY KEY (`itemid`,`clock`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 PARTITION BY RANGE (clock) (PARTITION p2012_kw05 VALUES LESS THAN (1328482800) ENGINE = InnoDB, PARTITION p2012_kw06 VALUES LESS THAN (1329087600) ENGINE = InnoDB, PARTITION p2012_kw07 VALUES LESS THAN (1329692400) ENGINE = InnoDB, PARTITION p2012_kw08 VALUES LESS THAN (1330297200) ENGINE = InnoDB, PARTITION p2012_kw09 VALUES LESS THAN (1330902000) ENGINE = InnoDB, PARTITION p2012_kw10 VALUES LESS THAN (1331506800) ENGINE = InnoDB, PARTITION p2012_kw11 VALUES LESS THAN (1332111600) ENGINE = InnoDB, PARTITION p2012_kw12 VALUES LESS THAN MAXVALUE ENGINE = InnoDB);

Und die Partitionen verbrauchen wie folgt Diskplatz (nicht wirklich viel, ich weiss!):

-rw-rw---- 1 mysql mysql 184549376 Mar 7 00:43 history_str#P#p2012_kw05.ibd -rw-rw---- 1 mysql mysql 209715200 Mar 14 00:11 history_str#P#p2012_kw06.ibd -rw-rw---- 1 mysql mysql 234881024 Mar 21 00:47 history_str#P#p2012_kw07.ibd -rw-rw---- 1 mysql mysql 226492416 Mar 23 16:39 history_str#P#p2012_kw08.ibd -rw-rw---- 1 mysql mysql 234881024 Mar 19 18:22 history_str#P#p2012_kw09.ibd -rw-rw---- 1 mysql mysql 289406976 Mar 19 18:22 history_str#P#p2012_kw10.ibd -rw-rw---- 1 mysql mysql 281018368 Mar 23 16:39 history_str#P#p2012_kw11.ibd -rw-rw---- 1 mysql mysql 213909504 Mar 23 17:23 history_str#P#p2012_kw12.ibd

Die Tabelle wurde mit den folgenden Werten komprimiert:

ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=4

Anschliessend schaut die Lage wie folgt aus:

-rw-rw---- 1 mysql mysql 7340032 Mar 23 17:33 history_str#P#p2012_kw05.ibd -rw-rw---- 1 mysql mysql 7340032 Mar 23 17:34 history_str#P#p2012_kw06.ibd -rw-rw---- 1 mysql mysql 8388608 Mar 23 17:36 history_str#P#p2012_kw07.ibd -rw-rw---- 1 mysql mysql 75497472 Mar 23 17:49 history_str#P#p2012_kw08.ibd -rw-rw---- 1 mysql mysql 104857600 Mar 23 17:44 history_str#P#p2012_kw09.ibd -rw-rw---- 1 mysql mysql 125829120 Mar 23 17:51 history_str#P#p2012_kw10.ibd -rw-rw---- 1 mysql mysql 125829120 Mar 23 17:57 history_str#P#p2012_kw11.ibd -rw-rw---- 1 mysql mysql 134217728 Mar 23 18:11 history_str#P#p2012_kw12.ibd

Wir erhalten somit eine Platzersparnis von 40 - 60%! Nicht allzu schlecht.

Aber spannend wäre auch noch den Einfluss auf den Speicher zu sehen:

SHOW GLOBAL STATUS LIKE 'innodb_buffer%'; +---------------------------------------+----------------------+ | Variable_name | Value | +---------------------------------------+----------------------+ | Innodb_buffer_pool_pages_data | 10769 | | Innodb_buffer_pool_pages_dirty | 6613 | | Innodb_buffer_pool_pages_free | 644 | | Innodb_buffer_pool_pages_misc | 18446744073709549802 | | Innodb_buffer_pool_pages_total | 9599 | +---------------------------------------+----------------------+

Diese Zahlen machen nicht wirklich Sinn. Zudem sind wir noch auf einen bekannten MySQL Bug #59550: Innodb_buffer_pool_pages_misc goes wrong gestossen.

Ein paar nette Grafen InnoDB Buffer Pool activity

Weil unser InnoDB Buffer Pool zu gross war, haben wir ihn etwas kleiner gemacht. Um das Barracuda File Format einzuschalten, haben wir anschliessend die Datenbank neu gestartet. Und dann sind die Zahlen amok gelaufen...

InnoDB compression time

Das erste mal, dass wir InnoDB Compression Time in unserem Monitor sehen... \o/

InnoDB Row operations

Und hier sehen Sie, wie wir die Konvertierung technisch gelöst haben... :-)

Im Admin-Magazin 2011/06 hat es einen netten Artikel über MySQL und PostgreSQL Performance Tuning: Duell der Datenbanken: In einem Shootout messen sich MySQL und PostgreSQL

Susanne hat dabei PostgreSQL, wir MySQL betreut...

Taxonomy upgrade extras: Performance Tuningmysqlbenchmarkpostgresqlgerman

Im Admin-Magazin 2011/06 hat es einen netten Artikel über MySQL und PostgreSQL Performance Tuning: Duell der Datenbanken: In einem Shootout messen sich MySQL und PostgreSQL

Susanne hat dabei PostgreSQL, wir MySQL betreut...

Taxonomy upgrade extras: Performance Tuningmysqlbenchmarkpostgresqlgerman

Taxonomy upgrade extras: Performance Tuningmysqlbenchmarkpostgresqlgerman

Im Admin-Magazin 2011/06 hat es einen netten Artikel über MySQL und PostgreSQL Performance Tuning: Duell der Datenbanken: In einem Shootout messen sich MySQL und PostgreSQL

Susanne hat dabei PostgreSQL, wir MySQL betreut...

Hallo zusammen,

Einige von Euch haben sicher vor, an die DOAG Conference 2011 nach Nürnberg zu kommen, welche vom 15. bis 17. November statt findet.

Neben zahlreichen interessanten Vorträgen über MySQL soll auch das Gesellschaftliche nicht zu kurz kommen. Daher planen wir am Dienstag, 15. November einen MySQL Community Abend mit gemeinsamem Nachtessen in einer netten Lokalität in Nürnberg. Ca. 18:30 - 19:00

Ihr seid alle herzlich eingeladen, daran teilzunehmen (auch wenn Ihr es nicht auf die DOAG Conference 2011 schafft).

Wer kennt ein nettes Restaurant wo wir hin gehen könnten (ich wüsste noch ein peruanisches Restaurant (nein, es gibt KEINE Meerschweinchen zu essen!) unterhalb der Burg!)?

Wer kommen möchte, bitte asap bei uns melden (contact@fromdual.com), damit wir genügend Plätze reservieren können.

Wenn die Speaker das Event während Ihres Vortrags ebenfalls ankündigen würden, wäre das sehr nett! Und wenn Ihr noch alle Leute, welche ebenfalls Interesse daran haben, informieren würdet wäre das toll!

Liebe Grüsse,

Oli

Taxonomy upgrade extras: doagcommunityconferencesocial eventgerman

Hallo zusammen,

Einige von Euch haben sicher vor, an die DOAG Conference 2011 nach Nürnberg zu kommen, welche vom 15. bis 17. November statt findet.

Neben zahlreichen interessanten Vorträgen über MySQL soll auch das Gesellschaftliche nicht zu kurz kommen. Daher planen wir am Dienstag, 15. November einen MySQL Community Abend mit gemeinsamem Nachtessen in einer netten Lokalität in Nürnberg. Ca. 18:30 - 19:00

Ihr seid alle herzlich eingeladen, daran teilzunehmen (auch wenn Ihr es nicht auf die DOAG Conference 2011 schafft).

Wer kennt ein nettes Restaurant wo wir hin gehen könnten (ich wüsste noch ein peruanisches Restaurant (nein, es gibt KEINE Meerschweinchen zu essen!) unterhalb der Burg!)?

Wer kommen möchte, bitte asap bei uns melden (contact@fromdual.com), damit wir genügend Plätze reservieren können.

Wenn die Speaker das Event während Ihres Vortrags ebenfalls ankündigen würden, wäre das sehr nett! Und wenn Ihr noch alle Leute, welche ebenfalls Interesse daran haben, informieren würdet wäre das toll!

Liebe Grüsse,

Oli

Taxonomy upgrade extras: doagcommunityconferencesocial eventgerman

Taxonomy upgrade extras: doagcommunityconferencesocial eventgerman

Hallo zusammen,

Einige von Euch haben sicher vor, an die DOAG Conference 2011 nach Nürnberg zu kommen, welche vom 15. bis 17. November statt findet.

Neben zahlreichen interessanten Vorträgen über MySQL soll auch das Gesellschaftliche nicht zu kurz kommen. Daher planen wir am Dienstag, 15. November einen MySQL Community Abend mit gemeinsamem Nachtessen in einer netten Lokalität in Nürnberg. Ca. 18:30 - 19:00

Ihr seid alle herzlich eingeladen, daran teilzunehmen (auch wenn Ihr es nicht auf die DOAG Conference 2011 schafft).

Wer kennt ein nettes Restaurant wo wir hin gehen könnten (ich wüsste noch ein peruanisches Restaurant (nein, es gibt KEINE Meerschweinchen zu essen!) unterhalb der Burg!)?

Wer kommen möchte, bitte asap bei uns melden (contact@fromdual.com), damit wir genügend Plätze reservieren können.

Wenn die Speaker das Event während Ihres Vortrags ebenfalls ankündigen würden, wäre das sehr nett! Und wenn Ihr noch alle Leute, welche ebenfalls Interesse daran haben, informieren würdet wäre das toll!

Liebe Grüsse,

Oli

Früher, lange, lange ist's her, konnte man den folgenden Trick verwenden um MySQL Queries in der Applikation zu taggen:

SELECT /* My Application Tag */ * FROM test;

Im Slow Query Log und im General Query Log ist das SQL Query dann wie folgt erschienen:

# Time: 111020 22:03:33 # User@Host: root[root] @ localhost [] Id: 1335 # Query_time: 17.873938 Lock_time: 0.007952 Rows_sent: 12048576 Rows_examined: 12048576 use test; SET timestamp=1319141013; SELECT /* My Application Tag */ * FROM test;

und

111020 22:03:15 1335 Query SELECT /* My Application Tag */ * FROM test

Das ist recht nützlich, wenn man nicht genau weiss woher ein Query stammt oder wie es von der Applikation schlussendlich ausformuliert wird.

Leider wurde dieses Feature irgendwann einmal von MySQL abgeschafft. Wann das genau geschehen ist, konnte ich nicht mehr herausfinden. Heute sehen die entsprechenden Einträge wie folgt aus:

# Time: 111020 22:03:33 # User@Host: root[root] @ localhost [] Id: 1335 # Query_time: 17.873938 Lock_time: 0.007952 Rows_sent: 12048576 Rows_examined: 12048576 use test; SET timestamp=1319141013; SELECT * FROM test;

und

111020 22:03:15 1335 Query SELECT * FROM test

Bei unserem heutigen Kunden hatten wir wieder mal genau dieses Problem. Zum Glück hatte er eine glorreiche Idee. Aus:

SELECT * FROM test WHERE 1 = 1;

machten wir kurzerhand:

SELECT * FROM test WHERE 'My Application Tag' = 'My Application Tag';

und siehe da:

# Time: 111020 22:24:59 # User@Host: root[root] @ localhost [] Id: 2077 # Query_time: 12.270074 Lock_time: 0.000124 Rows_sent: 12048576 Rows_examined: 12048576 use test; SET timestamp=1319142299; SELECT * FROM test WHERE 'My Application Tag' = 'My Application Tag';

und

2077 Query SELECT * FROM test WHERE 'My Application Tag' = 'My Application Tag'

es funktioniert...

Ist zwar nicht ganz so sexy, aber recht nützlich...

Taxonomy upgrade extras: tagquerygeneral query log

Früher, lange, lange ist's her, konnte man den folgenden Trick verwenden um MySQL Queries in der Applikation zu taggen:

SELECT /* My Application Tag */ * FROM test;

Im Slow Query Log und im General Query Log ist das SQL Query dann wie folgt erschienen:

# Time: 111020 22:03:33 # User@Host: root[root] @ localhost [] Id: 1335 # Query_time: 17.873938 Lock_time: 0.007952 Rows_sent: 12048576 Rows_examined: 12048576 use test; SET timestamp=1319141013; SELECT /* My Application Tag */ * FROM test;

und

111020 22:03:15 1335 Query SELECT /* My Application Tag */ * FROM test

Das ist recht nützlich, wenn man nicht genau weiss woher ein Query stammt oder wie es von der Applikation schlussendlich ausformuliert wird.

Leider wurde dieses Feature irgendwann einmal von MySQL abgeschafft. Wann das genau geschehen ist, konnte ich nicht mehr herausfinden. Heute sehen die entsprechenden Einträge wie folgt aus:

# Time: 111020 22:03:33 # User@Host: root[root] @ localhost [] Id: 1335 # Query_time: 17.873938 Lock_time: 0.007952 Rows_sent: 12048576 Rows_examined: 12048576 use test; SET timestamp=1319141013; SELECT * FROM test;

und

111020 22:03:15 1335 Query SELECT * FROM test

Bei unserem heutigen Kunden hatten wir wieder mal genau dieses Problem. Zum Glück hatte er eine glorreiche Idee. Aus:

SELECT * FROM test WHERE 1 = 1;

machten wir kurzerhand:

SELECT * FROM test WHERE 'My Application Tag' = 'My Application Tag';

und siehe da:

# Time: 111020 22:24:59 # User@Host: root[root] @ localhost [] Id: 2077 # Query_time: 12.270074 Lock_time: 0.000124 Rows_sent: 12048576 Rows_examined: 12048576 use test; SET timestamp=1319142299; SELECT * FROM test WHERE 'My Application Tag' = 'My Application Tag';

und

2077 Query SELECT * FROM test WHERE 'My Application Tag' = 'My Application Tag'

es funktioniert...

Ist zwar nicht ganz so sexy, aber recht nützlich...

Taxonomy upgrade extras: tagquerygerman