You are here

FromDual TechFeed (de)

Galera Cluster Nagios Plugin

Oli Sennhauser - Fri, 2012-09-14 10:39

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

Galera Cluster Nagios Plugin

Oli Sennhauser - Fri, 2012-09-14 10:39
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

Ändern von MyISAM Tabellen nach InnoDB und beheben der SELECT COUNT(*) Situation

Oli Sennhauser - Wed, 2012-06-13 07:44

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

Ändern von MyISAM Tabellen nach InnoDB und beheben der SELECT COUNT(*) Situation

Oli Sennhauser - Wed, 2012-06-13 07:44
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';

Hilft die InnoDB Datenkompression bei wenig Diskplatz?

Oli Sennhauser - Sat, 2012-03-24 10:06
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

Hilft die InnoDB Datenkompression bei wenig Diskplatz?

Oli Sennhauser - Sat, 2012-03-24 10:06
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... :-)

MySQL vs. PostgreSQL

Oli Sennhauser - Thu, 2011-11-17 11:33

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

MySQL vs. PostgreSQL

Oli Sennhauser - Thu, 2011-11-17 11:33
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...

DOAG Conference 2011 - MySQL Community Abend

Oli Sennhauser - Tue, 2011-11-01 14:26

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

DOAG Conference 2011 - MySQL Community Abend

Oli Sennhauser - Tue, 2011-11-01 14:26
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

MySQL Queries taggen

Oli Sennhauser - Thu, 2011-10-20 22:36

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

MySQL Queries taggen

Oli Sennhauser - Thu, 2011-10-20 22:36
Taxonomy upgrade extras: tagquerygerman

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...

Automatitisiertes Starten und Stoppen der Canias ERP Applikation

Oli Sennhauser - Wed, 2011-10-19 17:40

Beim Betrieb der Canias ERP Applikation stösst man unweigerlich früher oder später auf das lästige Verhalten, dass eine Konsole mit der Canias RMI Registry Applikation offen gehalten werden muss.

Eine offene Konsole kann dazu führen, dass aus Versehen die Applikation gestoppt wird und somit die ganze Produktion, welche am ERP hängt, still steht.
Ein weiteres Problem besteht darin, dass der Canias Server mit seinen Komponenten (RMI-Registry, Lizenz- und Applikations-Server) nicht als Dienst gestartet werden kann.
Das hat zur Folge, dass keine Standard Monitoring Lösung für die Canias-Überwachung genutzt werden kann.

Um dieses Problem zu umgehen haben wir für die Canias ERP Applikation ein start/stop Skript unter CentOS gebaut, welches alle Canias Komponenten steuert. Dieses Skript sollte mit minimalen Änderungen auch auf anderen Linux Distributionen lauffähig sein.

Mit diesem Skript lässt sich nun die Canias RMI-Registry, der Canias Controler sowie der Canias Server automatisiert beim Systemstart über den init-Prozess starten und wieder stoppen ohne, dass eine lästige Konsole offen bleiben muss.
Somit kann eine hohe Verfügbarkeit der Canias Applikation beim System-Neustart gewährleistet werden.

Zudem lässt sich dieses Skript als Ressource in einen aktiv/passiv Failover Cluster mit einbauen und im Fehlerfall automatisch mit auf den anderen Node rüberschwenken, wo die ERP Applikation innert weniger Minuten wieder zur Verfügung steht.

Wir konnten trotzt ausführlicher Tests keine Probleme mit dieser Konfiguration feststellen und wundern uns daher, dass dieses Verfahren nicht bereits durch den Hersteller Canias eingesetzt wird.

Durch leichtes Abändern des Skripts kann sogar ein Icon auf dem Desktop angelegt werden, welches durch Klicken den ganzen Canias Stack neu startet.

Bei Fragen zur Installation oder zum Betrieb von Canias ERP sowie des zugrunde liegenden MySQL Datenbank helfen wir gerne weiter.

#!/bin/sh # # /etc/init.d/canias {start|stop|reload|restart|status} # # canias: Start and Stop Canias ERP System # # chkconfig: is manged by Cluster suite # # Source function library. if [ -f /etc/init.d/functions ] ; then . /etc/init.d/functions elif [ -f /etc/rc.d/init.d/functions ] ; then . /etc/rc.d/init.d/functions else exit 1 fi appdir="/canias/iasAppServer" logdir="$appdir/Log" start() { echo -n "Starting Canias RMI Registry: " runuser -l canias -c "cd $appdir && nohup /usr/lib/jvm/jre-1.6.0/bin/java -jar serverUtils.jar \ start_ias_rmi_registry debug 1>$logdir/start_rmi_registry.log 2>&1 &" echo sleep 2 echo -n "Starting Canias Controller: " export DISPLAY=$(hostname):1 runuser -l canias -c "cd $appdir && nohup /canias/java/j2re1.4.2_18/bin/java -classpath controller.jar \ -Djava.security.policy=canias.policy -Djava.library.path=. com.ias.starter.iasControllerStarter /Port:USB \ 1>$logdir/start_controller.log 2>&1 &" echo sleep 2 echo -n "Starting Canias Server: " export DISPLAY=$(hostname):1 runuser -l canias -c "cd $appdir && nohup /usr/lib/jvm/jre-1.6.0/bin/java -Xmx4g \ -Djava.security.policy=canias.policy -cp server.jar:./RESOURCES/lib/activation.jar:./RESOURCES/lib/axis.jar:\ ./RESOURCES/lib/commons-discovery.jar:./RESOURCES/lib/commons-fileupload-1.1.1.jar:./RESOURCES/lib/commons-io-1.2.jar:\ ./RESOURCES/lib/commons-logging.jar:./RESOURCES/lib/FontBox-0.1.0-dev.jar:./RESOURCES/lib/iascommapi.jar:\ ./RESOURCES/lib/itext-paulo-155.jar:./RESOURCES/lib/jai_codec.jar:./RESOURCES/lib/jai_core.jar:\ ./RESOURCES/lib/jaxrpc.jar:./RESOURCES/lib/jcchart451K.jar:./RESOURCES/lib/jcert.jar:./RESOURCES/lib/jcfield451K.jar:\ ./RESOURCES/lib/jctable451K.jar:./RESOURCES/lib/jdbc2_0-stdext.jar:./RESOURCES/lib/jnet.jar:./RESOURCES/lib/jradius-client.jar:\ ./RESOURCES/lib/jsse.jar:./RESOURCES/lib/mail_v1.4.jar:./RESOURCES/lib/mlibwrapper_jai.jar:./RESOURCES/lib/NSClient_comp_1.4.jar:\ ./RESOURCES/lib/PDFBox-0.7.3-dev-20060516.jar:./RESOURCES/lib/RetepPDF.jar:./RESOURCES/lib/saaj.jar:./RESOURCES/lib/servlet.jar:\ ./RESOURCES/lib/smlib.jar:./RESOURCES/lib/soap.jar:./RESOURCES/lib/uddi4j.jar:./RESOURCES/lib/wsdl4j.jar:\ ./RESOURCES/lib/xerces.jar:./RESOURCES/lib/xml4j.jar:./RESOURCES/lib/JDBCDrivers com.ias.starter.iasServerStarter \ /settings:ServerSettings.ias 1>$logdir/start_server.log 2>&1 &" echo } stop() { echo -n "Shutting down all Canias related Java processes: " # kill processes in reverse order plist=$(pgrep -u canias java | sort -n -r) for i in $plist ; do kill $i done echo } status() { cnt=$(pgrep -u canias java | wc -l) if [[ $cnt -gt 0 ]] ; then echo "$cnt java processes for user canias are running..." exit 0 else echo "Canias seems to be stopped" exit 1 fi } case "$1" in start) start ;; stop) stop ;; restart|reload) stop sleep 5 start ;; status) status ;; *) echo "Usage: $0 {start|stop|restart|reload|status}" exit 1 esac # Always return 0 because we do not want to have a cluster starting # failure just because of Canias! exit 0 Über acar software GmbH

Acar software GmbH ist ein IT-Systemhaus, welches sich im ERP Bereich spezialisiert und weitreichendes Know-How in komplexen Geschäftsprozessen angeeignet hat. Wir sorgen dafür, dass der Kunde seine komplexen Prozesse mit unserer Software transparent und leicht abwickeln kann, ohne einen grossen Overhead zu erzeugen.
Mehr Infos zur acar software GmbH finden Sie unter: www.acarsoftware.de

Über FromDual GmbH

FromDual GmbH ist ein Hersteller unabhängiges und neutrales Beratungs- und Dienstleistungs-Unternehmen für MySQL, Percona Server und MariaDB.
Wir unterstützen unsere Kunden bei der Wartung und dem Betrieb von MySQL Datenbanken. Zudem machen wir auch MySQL Performance Tuning und helfen unseren Kunden MySQL Hochverfügbarkeits-Lösung zu implementieren, für welche wir auf Wunsch auch MySQL Support anbieten.
Mehr Infos zur FromDual GmbH finden Sie unter: www.fromdual.com

Taxonomy upgrade extras: haerpcaniasstartstopinitskripthochverfügbarkeitgerman

Automatitisiertes Starten und Stoppen der Canias ERP Applikation

Oli Sennhauser - Wed, 2011-10-19 17:40
Taxonomy upgrade extras: haerpcaniasstartstopinitskripthochverfügbarkeitgerman

Beim Betrieb der Canias ERP Applikation stösst man unweigerlich früher oder später auf das lästige Verhalten, dass eine Konsole mit der Canias RMI Registry Applikation offen gehalten werden muss.

Eine offene Konsole kann dazu führen, dass aus Versehen die Applikation gestoppt wird und somit die ganze Produktion, welche am ERP hängt, still steht.
Ein weiteres Problem besteht darin, dass der Canias Server mit seinen Komponenten (RMI-Registry, Lizenz- und Applikations-Server) nicht als Dienst gestartet werden kann.
Das hat zur Folge, dass keine Standard Monitoring Lösung für die Canias-Überwachung genutzt werden kann.

Um dieses Problem zu umgehen haben wir für die Canias ERP Applikation ein start/stop Skript unter CentOS gebaut, welches alle Canias Komponenten steuert. Dieses Skript sollte mit minimalen Änderungen auch auf anderen Linux Distributionen lauffähig sein.

Mit diesem Skript lässt sich nun die Canias RMI-Registry, der Canias Controler sowie der Canias Server automatisiert beim Systemstart über den init-Prozess starten und wieder stoppen ohne, dass eine lästige Konsole offen bleiben muss.
Somit kann eine hohe Verfügbarkeit der Canias Applikation beim System-Neustart gewährleistet werden.

Zudem lässt sich dieses Skript als Ressource in einen aktiv/passiv Failover Cluster mit einbauen und im Fehlerfall automatisch mit auf den anderen Node rüberschwenken, wo die ERP Applikation innert weniger Minuten wieder zur Verfügung steht.

Wir konnten trotzt ausführlicher Tests keine Probleme mit dieser Konfiguration feststellen und wundern uns daher, dass dieses Verfahren nicht bereits durch den Hersteller Canias eingesetzt wird.

Durch leichtes Abändern des Skripts kann sogar ein Icon auf dem Desktop angelegt werden, welches durch Klicken den ganzen Canias Stack neu startet.

Bei Fragen zur Installation oder zum Betrieb von Canias ERP sowie des zugrunde liegenden MySQL Datenbank helfen wir gerne weiter.

#!/bin/sh # # /etc/init.d/canias {start|stop|reload|restart|status} # # canias: Start and Stop Canias ERP System # # chkconfig: is manged by Cluster suite # # Source function library. if [ -f /etc/init.d/functions ] ; then . /etc/init.d/functions elif [ -f /etc/rc.d/init.d/functions ] ; then . /etc/rc.d/init.d/functions else exit 1 fi appdir="/canias/iasAppServer" logdir="$appdir/Log" start() { echo -n "Starting Canias RMI Registry: " runuser -l canias -c "cd $appdir && nohup /usr/lib/jvm/jre-1.6.0/bin/java -jar serverUtils.jar \ start_ias_rmi_registry debug 1>$logdir/start_rmi_registry.log 2>&1 &" echo sleep 2 echo -n "Starting Canias Controller: " export DISPLAY=$(hostname):1 runuser -l canias -c "cd $appdir && nohup /canias/java/j2re1.4.2_18/bin/java -classpath controller.jar \ -Djava.security.policy=canias.policy -Djava.library.path=. com.ias.starter.iasControllerStarter /Port:USB \ 1>$logdir/start_controller.log 2>&1 &" echo sleep 2 echo -n "Starting Canias Server: " export DISPLAY=$(hostname):1 runuser -l canias -c "cd $appdir && nohup /usr/lib/jvm/jre-1.6.0/bin/java -Xmx4g \ -Djava.security.policy=canias.policy -cp server.jar:./RESOURCES/lib/activation.jar:./RESOURCES/lib/axis.jar:\ ./RESOURCES/lib/commons-discovery.jar:./RESOURCES/lib/commons-fileupload-1.1.1.jar:./RESOURCES/lib/commons-io-1.2.jar:\ ./RESOURCES/lib/commons-logging.jar:./RESOURCES/lib/FontBox-0.1.0-dev.jar:./RESOURCES/lib/iascommapi.jar:\ ./RESOURCES/lib/itext-paulo-155.jar:./RESOURCES/lib/jai_codec.jar:./RESOURCES/lib/jai_core.jar:\ ./RESOURCES/lib/jaxrpc.jar:./RESOURCES/lib/jcchart451K.jar:./RESOURCES/lib/jcert.jar:./RESOURCES/lib/jcfield451K.jar:\ ./RESOURCES/lib/jctable451K.jar:./RESOURCES/lib/jdbc2_0-stdext.jar:./RESOURCES/lib/jnet.jar:./RESOURCES/lib/jradius-client.jar:\ ./RESOURCES/lib/jsse.jar:./RESOURCES/lib/mail_v1.4.jar:./RESOURCES/lib/mlibwrapper_jai.jar:./RESOURCES/lib/NSClient_comp_1.4.jar:\ ./RESOURCES/lib/PDFBox-0.7.3-dev-20060516.jar:./RESOURCES/lib/RetepPDF.jar:./RESOURCES/lib/saaj.jar:./RESOURCES/lib/servlet.jar:\ ./RESOURCES/lib/smlib.jar:./RESOURCES/lib/soap.jar:./RESOURCES/lib/uddi4j.jar:./RESOURCES/lib/wsdl4j.jar:\ ./RESOURCES/lib/xerces.jar:./RESOURCES/lib/xml4j.jar:./RESOURCES/lib/JDBCDrivers com.ias.starter.iasServerStarter \ /settings:ServerSettings.ias 1>$logdir/start_server.log 2>&1 &" echo } stop() { echo -n "Shutting down all Canias related Java processes: " # kill processes in reverse order plist=$(pgrep -u canias java | sort -n -r) for i in $plist ; do kill $i done echo } status() { cnt=$(pgrep -u canias java | wc -l) if [[ $cnt -gt 0 ]] ; then echo "$cnt java processes for user canias are running..." exit 0 else echo "Canias seems to be stopped" exit 1 fi } case "$1" in start) start ;; stop) stop ;; restart|reload) stop sleep 5 start ;; status) status ;; *) echo "Usage: $0 {start|stop|restart|reload|status}" exit 1 esac # Always return 0 because we do not want to have a cluster starting # failure just because of Canias! exit 0 Über acar software GmbH

Acar software GmbH ist ein IT-Systemhaus, welches sich im ERP Bereich spezialisiert und weitreichendes Know-How in komplexen Geschäftsprozessen angeeignet hat. Wir sorgen dafür, dass der Kunde seine komplexen Prozesse mit unserer Software transparent und leicht abwickeln kann, ohne einen grossen Overhead zu erzeugen.
Mehr Infos zur acar software GmbH finden Sie unter: www.acarsoftware.de

Über FromDual GmbH

FromDual GmbH ist ein Hersteller unabhängiges und neutrales Beratungs- und Dienstleistungs-Unternehmen für MySQL, Percona Server und MariaDB.
Wir unterstützen unsere Kunden bei der Wartung und dem Betrieb von MySQL Datenbanken. Zudem machen wir auch MySQL Performance Tuning und helfen unseren Kunden MySQL Hochverfügbarkeits-Lösung zu implementieren, für welche wir auf Wunsch auch MySQL Support anbieten.
Mehr Infos zur FromDual GmbH finden Sie unter: www.fromdual.com

ER-Diagramm des InnoDB Data Dictionaries

Oli Sennhauser - Wed, 2011-08-03 10:03

Mit dem neuen MySQL Release 5.6 sind einige neue InnoDB Data Dictionary Tabellen zum INFORMATION_SCHEMA hinzu gekommen:

Neu in MySQL 5.5 sind:

INNODB_CMPINNODB_CMP_RESETINNODB_CMPMEMINNODB_CMPMEM_RESETINNODB_TRXINNODB_LOCK_WAITSINNODB_LOCKS

Neu in MySQL 5.6 sind:

INNODB_BUFFER_PAGEINNODB_BUFFER_PAGE_LRUINNODB_BUFFER_POOL_STATSINNODB_METRICSINNODB_SYS_COLUMNSINNODB_SYS_FIELDSINNODB_SYS_FOREIGNINNODB_SYS_FOREIGN_COLSINNODB_SYS_INDEXESINNODB_SYS_TABLESINNODB_SYS_TABLESTATS

Die INNODB_SYS Tabellen waren bereits früher vorhanden, aber nicht über SQL zugreifbar. Man konnte Sie sehen, indem man den InnoDB Table Monitor eingeschaltet hat.

Um eine grobe Übersicht zu erhalten, welchen Bezug diese Tabellen zueinander haben, haben wir das ER-Diagramm des InnoDB Data Dictionaries reverse engineered. Bitte teilt uns mit, wenn Ihr einen Fehler findet oder wenn etwas fehlt...

Viel Spass!

Oli

innodb_dd.pdf (PDF: 93k)

Taxonomy upgrade extras: innodbdata dictionaryer-diagramgerman

ER-Diagramm des InnoDB Data Dictionaries

Oli Sennhauser - Wed, 2011-08-03 10:03
Taxonomy upgrade extras: innodbdata dictionaryer-diagramgerman

Mit dem neuen MySQL Release 5.6 sind einige neue InnoDB Data Dictionary Tabellen zum INFORMATION_SCHEMA hinzu gekommen:

Neu in MySQL 5.5 sind:

INNODB_CMPINNODB_CMP_RESETINNODB_CMPMEMINNODB_CMPMEM_RESETINNODB_TRXINNODB_LOCK_WAITSINNODB_LOCKS

Neu in MySQL 5.6 sind:

INNODB_BUFFER_PAGEINNODB_BUFFER_PAGE_LRUINNODB_BUFFER_POOL_STATSINNODB_METRICSINNODB_SYS_COLUMNSINNODB_SYS_FIELDSINNODB_SYS_FOREIGNINNODB_SYS_FOREIGN_COLSINNODB_SYS_INDEXESINNODB_SYS_TABLESINNODB_SYS_TABLESTATS

Die INNODB_SYS Tabellen waren bereits früher vorhanden, aber nicht über SQL zugreifbar. Man konnte Sie sehen, indem man den InnoDB Table Monitor eingeschaltet hat.

Um eine grobe Übersicht zu erhalten, welchen Bezug diese Tabellen zueinander haben, haben wir das ER-Diagramm des InnoDB Data Dictionaries reverse engineered. Bitte teilt uns mit, wenn Ihr einen Fehler findet oder wenn etwas fehlt...

Viel Spass!

Oli

innodb_dd.pdf (PDF: 93k)

Deutschsprachige MySQL Anwender Gruppe gegründet (DMySQLAG)

Oli Sennhauser - Mon, 2011-06-06 16:51
Heute wurde in Berlin die Deutschsprachige MySQL Anwender Gruppe formal gegründet. Der Verein fördert:
  • die Information über den Einsatz, den Umgang und die Erfahrung mit MySQL und Entwicklungen im MySQL Eco-System sowie Anwendungssysteme welche MySQL nutzen.
  • den Erfahrungsaustausch zwischen den Benutzern über MySQL sowie anderer Systeme.
  • die Beratung und Zusammenarbeit mit Oracle und Herstellern anderer Systeme.
  • die Unterbreitung von Mitgliedervorschlägen an Oracle und Hersteller von anderen Systemen.
Die deutschsprachige MySQL Anwender Gruppe ist für MySQL Anwender aus Deutschland, Österreich und der Schweiz gedacht. Damit Österreich und Schweiz ein genügend grosses Gewicht erhalten sind insbesondere zahlreiche Anmeldungen aus diesen beiden Ländern erwünscht! Wer als Gründungsmitglied aufgeführt werden will, soll sich asap (bis Freitag) bei uns per e-Mail melden. Eine spätere Mitgliedschaft ist jederzeit möglich. Mitgliederbeiträge
  • Schüler und Studenten: frei
  • Einzelmitglieder: EUR 100.-/a
  • Firmen bis 500 Mitarbeiter: EUR 200.-/a
  • Firmen über 500 Mitarbeiter: EUR 300.-/a
Taxonomy upgrade extras: mysqlanwendergerman

Deutschsprachige MySQL Anwender Gruppe gegründet (DMySQLAG)

Oli Sennhauser - Mon, 2011-06-06 16:51
Taxonomy upgrade extras: mysqlanwendergermanHeute wurde in Berlin die Deutschsprachige MySQL Anwender Gruppe formal gegründet. Der Verein fördert:
  • die Information über den Einsatz, den Umgang und die Erfahrung mit MySQL und Entwicklungen im MySQL Eco-System sowie Anwendungssysteme welche MySQL nutzen.
  • den Erfahrungsaustausch zwischen den Benutzern über MySQL sowie anderer Systeme.
  • die Beratung und Zusammenarbeit mit Oracle und Herstellern anderer Systeme.
  • die Unterbreitung von Mitgliedervorschlägen an Oracle und Hersteller von anderen Systemen.
Die deutschsprachige MySQL Anwender Gruppe ist für MySQL Anwender aus Deutschland, Österreich und der Schweiz gedacht. Damit Österreich und Schweiz ein genügend grosses Gewicht erhalten sind insbesondere zahlreiche Anmeldungen aus diesen beiden Ländern erwünscht! Wer als Gründungsmitglied aufgeführt werden will, soll sich asap (bis Freitag) bei uns per e-Mail melden. Eine spätere Mitgliedschaft ist jederzeit möglich. Mitgliederbeiträge
  • Schüler und Studenten: frei
  • Einzelmitglieder: EUR 100.-/a
  • Firmen bis 500 Mitarbeiter: EUR 200.-/a
  • Firmen über 500 Mitarbeiter: EUR 300.-/a

BLOB's aus der MySQL Datenbank herausklauben

Oli Sennhauser - Fri, 2011-04-22 14:12

Ein Kunde, welcher mit digitalen Zertifikaten zu tun hat, hatte ein Problem mit einem solchen. Also mussten wir nachforschen, was das Problem war.

Weil das Zertifikat in binärer Form vorliegt, ist es in einem BLOB gespeichert und wir mussten es aus der Datenbank herausklauben um einige Tests damit durchzuführen.

Als erstes kam mir in den Sinn, das Zertifikat mit dem Befehl SELECT INTO OUTFILE zu erhalten. Aber das Verifizierungstool reklamierte und sagte uns, dass das Zertifikat ein falsches Format habe.

Zum Glück fand ich in der MySQL Dokumentation den folgenden Satz: If you use INTO DUMPFILE instead of INTO OUTFILE, MySQL writes only one row into the file, without any column or line termination and without performing any escape processing. This is useful if you want to store a BLOB value in a file.

Wir haben es ausprobiert mit:

mysql> SELECT certificate INTO DUMPFILE '/tmp/certificate.bin' FROM identity WHERE id = 42;

und es hat perfekt funktioniert. Das Zertifikat-Verifizierungstool hatte nichts mehr zu meckern und wir konnten weiter nachforschen, warum das Zertifikat überhaupt ein Problem verursacht hat...

Mit diesem Befehl, welchen ich vorher noch nicht kannte, ist es sehr einfach ein einzelnes BLOB aus der Datenbank in eine Datei zu dumpen und dieses von dort aus weiter zu verarbeiten.

Zur Erinnerung: MySQL hat eine generelle Protokoll-Limitation für BLOB's von 1 Gbyte und die Grösse für max_allowed_packet muss entsprechend für den Client UND den Server angepasst werden wenn grosse BLOB's verwendet werden. Weitere Informationen über MySQL-Limitationen finden Sie hier.

Im weiteren muss der Typ des BLOB's entsprechend der erwarteten Grösse des BLOB's richtig gewählt werden. Siehe auch: Data Type Storage Requirements.

Literatur
  1. SELECT Syntax
Taxonomy upgrade extras: mysqlblobdumpselectgerman

BLOB's aus der MySQL Datenbank herausklauben

Oli Sennhauser - Fri, 2011-04-22 14:12
Taxonomy upgrade extras: mysqlblobdumpselectgerman

Ein Kunde, welcher mit digitalen Zertifikaten zu tun hat, hatte ein Problem mit einem solchen. Also mussten wir nachforschen, was das Problem war.

Weil das Zertifikat in binärer Form vorliegt, ist es in einem BLOB gespeichert und wir mussten es aus der Datenbank herausklauben um einige Tests damit durchzuführen.

Als erstes kam mir in den Sinn, das Zertifikat mit dem Befehl SELECT INTO OUTFILE zu erhalten. Aber das Verifizierungstool reklamierte und sagte uns, dass das Zertifikat ein falsches Format habe.

Zum Glück fand ich in der MySQL Dokumentation den folgenden Satz: If you use INTO DUMPFILE instead of INTO OUTFILE, MySQL writes only one row into the file, without any column or line termination and without performing any escape processing. This is useful if you want to store a BLOB value in a file.

Wir haben es ausprobiert mit:

mysql> SELECT certificate INTO DUMPFILE '/tmp/certificate.bin' FROM identity WHERE id = 42;

und es hat perfekt funktioniert. Das Zertifikat-Verifizierungstool hatte nichts mehr zu meckern und wir konnten weiter nachforschen, warum das Zertifikat überhaupt ein Problem verursacht hat...

Mit diesem Befehl, welchen ich vorher noch nicht kannte, ist es sehr einfach ein einzelnes BLOB aus der Datenbank in eine Datei zu dumpen und dieses von dort aus weiter zu verarbeiten.

Zur Erinnerung: MySQL hat eine generelle Protokoll-Limitation für BLOB's von 1 Gbyte und die Grösse für max_allowed_packet muss entsprechend für den Client UND den Server angepasst werden wenn grosse BLOB's verwendet werden. Weitere Informationen über MySQL-Limitationen finden Sie hier.

Im weiteren muss der Typ des BLOB's entsprechend der erwarteten Grösse des BLOB's richtig gewählt werden. Siehe auch: Data Type Storage Requirements.

Literatur
  1. SELECT Syntax

Pages

Subscribe to FromDual aggregator - FromDual TechFeed (de)