You are here

FromDual TechFeed (de)

Ugly way to install MySQL Galera Cluster 5.6 on Ubuntu 14.04

Oli Sennhauser - Mon, 2014-10-20 21:26
Taxonomy upgrade extras: galeraGalera Clusterinstallationubuntu

I wanted to install MySQL Galera Cluster 5.6 on the new Ubuntu 14.04 with provided packages. It was a bit tricky to make it work.

apt-get update apt-get install mysql-server # this is still 5.5 # from universe apt-get install mysql-server-5.6 mysql-client-5.6 mysql-client-core-5.6

So far so good. Everything works fine as MySQL 5.6.

Now we have to download Galera 5.6 from Coderships website:

wget https://launchpad.net/galera/3.x/25.3.5/+download/galera-25.3.5-amd64.deb wget https://launchpad.net/codership-mysql/5.6/5.6.16-25.5/+download/mysql-server-wsrep-5.6.16-25.5-amd64.deb apt-get install libssl0.9.8 # Should be resolved by the package? dpkg -i galera-25.3.5-amd64.deb

And then the ugly part:

dpkg --force-all -i mysql-server-wsrep-5.6.16-25.5-amd64.deb

Finally:

# /etc/mysql/conf.d/wsrep.cnf [mysqld] wsrep_provider = /usr/lib/galera/libgalera_smm.so wsrep_cluster_address = "gcomm://"

And to activate the changes:

service mysql restart

If you find a better way, please let me know...

Wir suchen Dich: MySQL DBA für FromDual Support

Oli Sennhauser - Wed, 2013-12-04 16:23

FromDual sucht enthusiastische Mitarbeiter die:

  • Kenntnisse über MySQL, Percona Server oder MariaDB aufweisen oder sich aneignen wollen
  • mit dem Open-Source Ökosystem vertraut sind und Beiträge dazu geleistet haben
  • als DBA oder DevOps wissen, wie man Datenbank-Systeme betreibt
  • verstehen, was beim Betrieb von Datenbanken falsch gemacht werden kann
  • gerne selbständig remote arbeiten und über IRC, Skype, Mail und Telefon zu kommunizieren gewohnt sind
  • sich auf Linux Systemen gut auskennen und wohl fühlen
  • gute Team-Player sind und zum Wachstum der Firma beitragen wollen
  • gerne den direkten Kontakt mit Kunden haben und
  • auf der Suche nach einer neuen Herausforderung sind

Stellenbeschreibung

Wir suchen deutschsprachige vollzeit MySQL Support DBA's (Sie oder Ihn), welche primär für unsere MySQL Support Dienstleistungen zuständig sind und unseren Kunden helfen, ihre MySQL Datenbanken zu betreiben (Support und remote-DBA).

Du bist fit in MySQL und:

  • hast Erfahrung im Betrieb kritischer und hoch verfügbarer produktiver MySQL Datenbanken hauptsächlich auf Linux.
  • Deine tägliche Arbeit ist MySQL-Replikation in allen Variationen.
  • weisst, wie die meist verbreitetsten MySQL HA Setups funktionieren und wie man sie wieder effizient repariert, wenn ein Problem auftritt. (Wenn Du bereits Erfahrungen mit Galera Cluster gesammelt hast, ist das ein Vorteil!)
  • kennst die gängigen Open-Source Technologien (LAMP Stack, etc.)
  • kannst Bash skripten und einfache Programme in mindestens einer verbreiteten Programmier-/Skripting-Sprache (Perl, PHP, ...) erstellen.

Du wirst im direkten Kontakt mit Kunden stehen. Du hast ein gutes Gespür für deren Probleme und kannst zuhören, weisst wie antworten und findest die eigentlichen Probleme. Du wirst proaktiv handeln, bevor etwas passiert und den Kunden wieder auf den richtigen Pfad führen.
Du bist ein guter Kommunikator und ein aktiver Team Player.

Um Deine Arbeit erledigen zu können, arbeitest Du in einer europäischen Zeitzone. Deine Arbeitszeit kannst Du in bestimmten Grenzen flexibel gestalten. Wir erwarten, dass Du Deinen Beitrag zum Bereitschaftsdienst leistest. FromDual ist eine vollständig virtuelle Firma. Ein Umzug ist daher nicht notwendig (Home-Office). Gute schriftliche und mündliche Englischkenntnisse sind zwingend.

Neben Deiner Tätigkeit als Support DBA erwarten wir, dass Du Dir laufend neue Kenntnisse aneignest und Deine Fähigkeiten verbesserst sowie dazu beiträgst, unsere Monitoring-Lösung, unsere Datenbank-Steuerung und unseren weiteren Tools zu verbessern. Im weiteren würden wir es sehr schätzen, wenn Du regelmässig zur Verfassung technischer Artikel (Blog oder Zeitschriften) beiträgst und überall mit hilfst, wo Hilfe nötig ist...

Du solltest in der Lage sein, die meiste Zeit selbständig zu arbeiten, denken und zu handeln und Dir neues Wissen selbständig anzueignen (durch Google, die MySQL Dokumentation, Ausprobieren, etc.). Wenn Du mal nicht weiterkommst, werden Dir Deine Kollegen von FromDual gerne helfen.

Wenn Du jemanden brauchst, der Dir die ganze Zeit Dein Händchen hält, ist FromDual nicht die richtige Wahl.

Wer ist FromDual?

FromDual ist die führende unabhängige MySQL Beratungs- und Dienstleistungs-Firma in Europa mit ihrem Hauptsitz in der Schweiz.

Unsere Kunden befinden sich hauptsächlich in Europa und reichen vom kleinen Start-Up bis zur europäischen Top-500 Firma.

Du wirst in einer spannenden Zeit zu uns stossen. Wir sind am wachsen und brauchen die entsprechenden Leute, welche selbst und mit uns wachsen wollen. In dem Mass, wie wir uns weiter entwickeln, muss auch unser Team wachsen uns seine Fähigkeiten erweitern.

Wie geht es weiter

Wenn Du an dieser Chance interessiert bist und Du denkst, dass Du die passende Kandidatin oder der passende Kandidat bist (wir wissen, dass es niemanden gibt, der 100% auf diese Stellenbeschreibung passt!), würden wir uns freuen, von Dir zu hören.

Bitte schicke Deinen ungeschönten Lebenslauf mit Deinen Lohnvorstellungen und einer Liste Deiner Open-Source Beiträgen, Blog-Artikel, Vorträgen, Tweets etc. an jobs@fromdual.com. Wenn Du mehr über diese Stelle erfahren oder wenn Du mit mir persönlich sprechen möchtest, ruf mich bitte an unter +41 79 830 09 33 (Oli Sennhauser, CTO). Bitte nur Bewerber, KEINE Headhunter!

Nachdem wir Deinen Lebenslauf erhalten und geprüft haben, laden wir Dich ein, Deine technischen Fähigkeiten in einem kleinen MySQL-Test unter Beweis zu stellen. Wenn Du den Test bestanden hast, laden wir Dich für die finalen Interviews ein.

Dieses Stellenangebot ist offen bis 31. Januar 2014

Wir brauchen Dich: MySQL DBA für FromDual Support Line

Oli Sennhauser - Tue, 2013-04-02 11:18
Wir brauchen Dich: MySQL DBA für FromDual Support Dienste

FromDual sucht enthusiastische und erfahrene Mitarbeiter die:

  • detaillierte Kenntnisse über MySQL, Percona Server oder MariaDB aufweisen
  • mit dem Open-Source Ökosystem vertraut sind
  • als DBA oder DevOps wissen, wie man Datenbank-Systeme betreibt
  • verstehen, was beim Betrieb von Datenbanken falsche gemacht werden kann
  • gerne selbständig remote arbeiten und über IRC, Skype, Mail und Telefon zu kommunizieren gewohnt sind
  • sich auf Linux Systemen wohl fühlen
  • gute Team-Player sind und zum Wachstum der Firma beitragen wollen
  • gerne den direkten Kontakt mit Kunden haben und
  • auf der Suche nach einer neuen Herausforderung sind

Stellenbeschreibung

Wir suchen Vollzeit-MySQL Support DBA's (Sie oder Ihn), welche primär für unsere MySQL Support Dienstleistungen zuständig sind und unseren Kunden helfen, ihre MySQL Datenbanken zu betreiben (remote-DBA und Notfall-Interventionen).

Du bist fit in MySQL und:

  • hast Erfahrung im Betrieb kritischer und hoch verfügbarer produktiver MySQL Datenbanken hauptsächlich auf Linux.
  • Deine tägliche Arbeit ist MySQL-Replikation in allen Variationen.
  • weisst, wie die meist verbreitetsten MySQL HA Setups funktionieren und wie man sie wieder effizient repariert, wenn ein Problem auftritt. (Wenn Du bereits Erfahrungen mit Galera Cluster gesammelt hast, ist das ein Vorteil!)
  • kennst die gängigen Open-Source Technologien (LAMP Stack, etc.)
  • kannst Bash skripten und einfache Programme in mindestens einer verbreiteten Programmier-/Skripting-Sprache (Perl, PHP, ...) erstellen.

Du wirst im direkten Kontakt mit Kunden stehen. Du hast ein gutes Gespür für deren Probleme und kannst zuhören, weisst wie antworten und findest die eigentlichen Probleme. Du wirst proaktiv handeln, bevor etwas passiert und den Kunden wieder auf den richtigen Pfad führen.
Du bist ein guter Kommunikator und ein aktiver Team Player.

Um Deine Arbeit erledigen zu können, arbeitest Du in einer Europäischen Zeitzone. Deine Arbeitszeit kannst Du in bestimmten Grenzen flexibel gestalten. Wir erwarten, dass Du Deinen Beitrag zum Bereitschaftsdienst leistest. FromDual ist eine vollständig virtuelle Firma. Ein Umzug ist daher nicht notwendig (Home-Office). Gute schriftliche und mündliche Englischkenntnisse sind zwingend. Die meisten unserer Kunden sind deutschsprachig. Deutschkenntnisse sind daher von Vorteil.

Neben Deiner Tätigkeit als Support DBA erwarten wir, dass Du Dir laufend neue Kenntnisse aneignest und Deine Fähigkeiten verbesserst sowie dazu beiträgst, unsere Monitoring-Lösung, unsere Datenbank-Steuerung und unseren weiteren Tools zu verbessern. Im weiteren erwarten wir, dass Du regelmässig zur Verfassung technischer Artikel (Blog oder Zeitschriften) beiträgst und überall mit hilfst, wo Hilfe nötig ist...

Du solltest in der Lage sein, die meiste Zeit selbständig zu arbeiten, denken und zu handeln und Dir neues Wissen selbständig anzueignen (durch Google, die MySQL Dokumentation, Ausprobieren, etc.). Wenn Du mal nicht weiterkommst, werden Dir Deine Kollegen von FromDual helfen.

Wenn Du jemanden brauchst, der Dir die ganze Zeit Dein Händchen hält, ist FromDual nicht die richtige Wahl.

Wer ist FromDual?

FromDual ist die führende unabhängige MySQL Beratungs- und Dienstleistungs-Firma in Europa mit ihrem Hauptsitz in der Schweiz.

Unsere Kunden befinden sich hauptsächlich in Europa und reichen vom kleinen Start-Up bis zur europäischen Top-500 Firma.

Du wirst in einer spannenden Zeit zu uns stossen. Wir sind am wachsen und brauchen die entsprechenden Leute, welche selbst und mit uns wachsen wollen. In dem Mass, wie wir uns weiter entwickeln, muss auch unser Team wachsen uns seine Fähigkeiten erweitern.

Sich bei uns zu bewerben, kann kann Deine beste Entscheidung sein.

Wie geht's weiter

Wenn Du an dieser Chance interessiert bist und Du denkst, dass Du die passende Kandidatin oder der passende Kandidat bist (wir wissen, dass es niemanden gibt, der 100% auf diese Stellenbeschreibung passt!), würden wir uns freuen, von Dir zu hören.

Bitte schicke Deinen ungeschönten Lebenslauf mit Deinen Lohnvorstellungen und einer Liste Deiner Open-Source Beiträgen, Blog-Artikel, Vorträgen, Tweets etc. an jobs@fromdual.com. Wenn Du mehr über diese Stelle erfahren oder wenn Du mit mir persönlich sprechen möchtest, ruf mich bitte an unter +41 79 830 09 33 (Oli Sennhauser, CTO). Bitte nur Bewerber, KEINE Headhunter!

Nachdem wir Deinen Lebenslauf erhalten und geprüft haben, laden wir Dich ein, Deine technischen Fähigkeiten in einem kleinen MySQL-Test unter Beweis zu stellen. Wenn Du den Test bestanden hast, laden wir Dich für die finalen Interviews ein.

Dieses Stellenangebot ist offen bis 31. Mai 2013

Artikel über MySQL im neuen iX

Oli Sennhauser - Thu, 2012-09-20 15:12
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!

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

Wo sich die MySQL Gemeinde tummelt...

Oli Sennhauser - Sun, 2011-03-27 21:27
Taxonomy upgrade extras: irchilfecommunitygerman

Weit, weit weg von hier, in einem anderen Universum namens IRC, gibt es eine Welt mit Namen irc.freenode.net und dort, im Land #mysql.de, tummelt sich die deutschsprachige MySQL Gemeinde.
Die Bewohner dieses Landes sind meist nette Leute, die sich mit MySQL beschäftigen und einige davon sind sogar Kenner ihres Fachs!

Bewohner anderer Universen, welche nach ausführlichem Studium des MySQL Handbuchs immer noch nicht weiter wissen, finden bei den Bewohnern diese Landes meist Rat.
Nicht alle Bürger dieses Landes sind die geborenen Diplomaten. Aber unter ihrer rauen Schale schlummert ein grosses Herz. Wenn man also keine oder eine nicht allzu zuvorkommende Antwort erhält, sollte man nicht verzagen. Die Leute meinen das nicht böse und können nichts für Ihre ungeschliffene Herzlichkeit.

Der Weg nach #mysql.de

Der einzige Weg, um in das rätselhafte Land #mysql.de zu gelangen, besteht darin, dass man sich ein Portal sucht und mit einem IRC-Client den Sprung dorthin unternimmt, was meist problemlos gelingt. Beliebte und oft verwendete IRC-Clients sind z.B. Xchat, Pidgin oder Iriss.

Web-IRC

Wer keinen eigenen Client installieren kann oder mag, kann auch auf den IRC Web-Client zurückgreifen, um dorthin zu gelangen.

Die Reise

Wenn man den IRC-Client startet, muss man ihm mitteilen wohin die Reise gehen soll:

Ein Benutzernamen respektive der Alias kann frei gewählt werden, solange er keinen Konflikt mit den Namen eines Einheimischen verursacht.
Nicht alle IRC-Clients unterstützen mehrere Protokolle. Ein Passwort ist nicht für alle Länder notwendig. In manche Länder kann man zwar ohne Passwort einreisen, nicht aber Fragen stellen...

Wenn man den Sprung in die gewählte Welt geschafft hat, kriegt man eine entsprechende Meldung:

Um eine Einreise in das entsprechende Land zu beantragen muss folgender Wunsch geäussert werden:

/join #mysql.de

Sobald man den Wunsch geäussert hat befindet man sich im gewünschten Land.

Bräuche und Sitten

Es ist eine gute Angewohnheit die Bewohner des entsprechenden Landes zuerst kurz zu begrüssen. Dann können aber bereits Fragen gestellt werden.
Darf ich was Fragen? oder ähnliche Fragen sind verpönt und führen unter Umständen zu unfreundlichen Antworten wie z.B. Nein!. Diese Antworten sind aber nicht ernst zu nehmen. Im weiteren braucht man sich auch nicht zu entschuldigen wenn man keinen perfekten Deutsch-Stil beherrscht.

Wenn ein ortsansässiger Zeit und Lust hat, wird er gerne Auskunft geben oder genauer nachfragen was der Fremdling gerade Fragen wollte...

Ist man mit einem Einheimischen im Gespräch kann man ihn auch gezielt ansprechen z.B. mit "shinguz: dies und das..."

Im Lande #mysql.de gilt es als Unsitte sich auf englisch zu unterhalten. Wenn grössere Auszüge aus Logfiles etc. ausgetauscht werden sollen, wird es nicht geschätzt, wenn diese direkt im IRC Fenster übermittelt werden. Um solche Meldungen zu übermitteln ist z.B. das Tool Pastebin hervorragend geeignet. Es wird dann nur noch der Link mitgeteilt und jeder den es interessiert kann sich den Inhalt der Nachricht anschauen.

Was im Lande #mysql.de ebenfalls geschätzt wird, ist, wenn man Problem in einfache nachvollziehbare Beispiele zerlegt, die von den Bewohnern schnell und einfach nachgestellt werden können.

Wichtig: Die Bewohner sind viel beschäftigte Leute, welche zuerst Ihrer täglichen Arbeit nachgehen müssen. Seid also geduldig und nicht zu aufdringlich. Der Kontakt mit Fremden ist freiwillig und es besteht keine Auskunftspflicht.

Dies sind, so denke ich, die wichtigsten Information und Regeln um ins Land #mysql.de zu finden und sich darin zu bewegen.

Willkommen!

Die Bewohner von #mysql.de würden sich freuen wenn Ihr sie zahlreich besuchen kommt und etwas Leben und Blutauffrischung in ihr Land bringt...

Kommt uns doch mal besuchen!

Lokale Sprache

Einige nützliche Redewendungen im IRC-Universum sind:

RedewendungBedeutung/nick shinguz_futternMan gibt sich einen anderen Namen/quit Kissen lauschen!Ausreise mit Grundangabe/me zerstört gerade eine DatenbankBeschreibt den Anwesenden, was man gerade macht.../whois shinguzErfragt mehr Informationen über einen Bewohner/query shinguzGespräch unter vier Augen mit einem Anwesenden/invite shinguzLädt einen Anwesenden in ein anderes Land ein./msg shinguz Ganz private MitteilungSendet eine private Meldung an den Bewohner

Weiter hilft sonst auch das Fremdwörterbuch für IRC.

Weiter Länder in dieser Welt

Weitere Länder mit ähnlich gearteter Bevölkerung findest Du auf dieser Welt hier:

Land Wichtigkeit Beschreibung #drizzle 62Drizzle - Database for Cloud#maatkit 16Maatkit#maria 58Welcome to #maria, home of MariaDB!#mysql 606MySQL help channel#mysql.de 21Der deutschsprachige MySQL Channel#mysql-dev 22MySQL server development#mysql-es 5Bienvenidos a canal de MySQL en español#mysql-fr 3Canal MySQL français#mysql-ndb 19Discussion of MySQL Cluster#mysql-proxy 13MySQL Proxy#ourdelta 10OurDelta - Enhanced Builds for MySQL, MariaDB#percona 15XtraDB, XtraBackup, Percona Server#workbench 11MySQL Workbench

Vorsicht bei der Nutzung von SAN

Oli Sennhauser - Fri, 2011-03-04 18:36
Taxonomy upgrade extras: performancesanvirtualizationconsolidationcloudvirtualisierungkonsolidierunggerman

Vorsicht bei der Nutzung von SAN (Storage Area Networks) oder ähnlichen Shard Storage Lösungen (und allen anderen Virtualisierungs-, Konsolidierungs- oder Cloud-Lösungen).

Diese Woche ist es wieder passiert: Ein Kunde rief bei uns an, weil er Ärger mit seinem on-line Shop hatte (siehe Datum!). Alle in seiner Firma beschwerten sich, dass die Datenbank langsam antwortet.

Als wir auf seine Maschine schauten (mit iostat), haben wir I/O Last und einige pending reads in InnoDB gesehen (SHOW ENGINE INNODB STATUS und SHOW GLOBAL STATUS LIKE 'InnoDB%') und eine sehr schlechte InnoDB Buffer Pool Hit Ratio (ungefähr 80%, ja, ich weiss Hit Ratios sind schlechte Indikatoren, aber manchmal sind sie recht nützlich).

Der Kunde beteuerte, dass er seit einigen Tagen nichts am System geändert habe. Und am vorherigen Tag sei alles prima gelaufen, aber an diesem Nachmittag wurde das System plötzlich langsam. Er teilte uns im weiteren mit, dass sie zur Zeit daran seien, Monatsreports zu generieren. Aber nur auf den Slaves.

Wir fanden eine Abfrage, welche seit 25 Minuten am laufen war, also nahm ich an, dass diese Abfrage der Übeltäter ist. Nachdem wir die Abfrage gekillt hatten, entspannte sich das System ein wenig, war aber immer noch unter I/O last und der Kunde merkte an, dass wir kurz vor Ende der Hauptlast-Zeit sind. Das würde erklären, warum das System nicht mehr so ausgelastet sei.

Bis zu diesem Zeitpunkt hatte ich keine Ahnung, was der Grund für unser Problem ist. Etwas frustrierend, wenn man dem Kunden nicht erklären kann, warum er gerade ein Problem hat.

Glücklicherweise kam gerade einer der Systemadministratoren ins Büro und beschwerte sich, dass wir gerade sein SAN füllen. Schuld sei der Slave unseres langsamen Masters. Auf dem Slave fanden wir eine Abfrage (Monatsend-Report), welche seit 2 bis 3 Stunden am laufen war, welche eine temporäre Tabelle von ungefähr 350 Gbyte erzeugte! Diese Tabelle füllte das SAN auf ungefähr 99%.

Der Systemadministrator bemerkte im Weiteren, dass das Füllen eines SAN's auf mehr als 90%, das ganze SAN ausbremsen würde (warum auch immer).

Diese Aussage liess bei uns die Alarmglocken klingeln: Hatten wir nicht ein I/O Problem, welches urplötzlich vor 2 bis 3 Stunden einsetzte? Wir fanden heraus, dass unser Master und der Slave unglücklicherweise auf dem selben SAN platziert waren.

Als wird die Abfrage gekillt hatten, wurde die Tabelle automatisch gelöscht und nach einigen Minuten wurde der Diskplatz wieder frei gegeben. Mir wurde gesagt, dass es einige Stunden dauert, bis das SAN sich wieder beruhigt haben wird (warum auch immer). Am nächsten Tag bestätigte der Kunde, dass alles wieder wie gewohnt läuft. Somit können wir ziemlich sicher sein, dass das Füllen des SAN's mit dem Slave das Problem auf unserem produktiven Master verursacht hat.

Schlussfolgerung: SAN's können verschiedene unerwartete Nebeneffekte und Auswirkungen auf die Performance haben. Wenn Sie nicht ungewollt unvorhersehbare Performanceauswirkungen erleben wollen, versuchen sie auf dedizierten Storagelösungen zu bleiben.

Siehe auch unser Commit Demo Test:

MySQL Cluster - Cluster Ring-Replikation mit 2 Replikations-Kanälen

Oli Sennhauser - Wed, 2011-01-12 20:25
Taxonomy upgrade extras: replicationMySQL Clusterfail-overchannelRing-Replikationgerman

Vor ein paar Tagen hatte ich wieder einmal mit einer MySQL Cluster Replikation zu tun. Ich habe das schon eine Weile nicht mehr angelangt und war somit vorbereitet, wieder einmal ein paar Überraschungen zu erleben.

Diejenige, für welche MySQL Cluster - Cluster Ring-Replikationen das tägliche Brot ist, können diesen Artikel getrost überspringen. Alle anderen können möglicherweise von unseren Erfahrungen profitieren.

Wir hatten das folgende MySQL Cluster Konstrukt im Einsatz:

Mehr Informationen über solche Gebilde können in der MySQL Cluster Dokumentation gefunden werden.

Situationen welche zu einem Channel Fail-over führen:

Was sind die Problem, mit dem MySQL Cluster, welche zu einem Channel Fail-over führen:

  • Der MySQL Master verliert die Verbindung zum MySQL Cluster (lost_event, gap).
  • Der MySQL Master kann mit der Last auf dem MySQL Cluster nicht Schritt halten und verliert daher Events (gap). Ich bin wirklich etwas verwundert über das Argument in der Dokumentation [ 1 ], dass in einem solchen Fall ein Channel Fail-over durchgeführt werden kann oder soll. Weil, wenn der Master 1 mit der Last nicht mehr Schritt halten kann, warum soll es dann Master 2 noch können...?).

Was eine Lücke (gap / lost_event) ist, kann der folgenden Skizze entnommen werden:

Wie ein solches System aufgesetzt wird, wollen wir hier nicht betrachten. Die Anleitung dazu können der MySQL Cluster Dokumentation entnommen werden.

Unsere Erkenntnisse

Unsere Erkenntnisse waren folgender Art:

Doppelte Primary Key Einträge

Wir erhielten einige doppelte Index Einträge für unsere AUTO_INCREMENT Primary Keys:

ERROR 1062 (23000): Duplicate entry '260' for key 'PRIMARY'

Der Grund dafür ist, dass wir ndb_autoincrement_prefetch_sz auf 256 gesetzt hatten, um eine bessere INSERT Performance zu erhalten.

Als Konsequenz erhält man, früher oder später, wenn man Daten in alle mysqld's auf beiden Clustern einfügt, einen Primary Key Konflikt.

Wir haben dieses Problem gelöst, indem wir die auto_increment_increment und auto_increment_offset Werte für die SQL Knoten auf beiden MySQL Clustern entsprechend gesetzt haben.

Empfohlene Channel Fail-over Methode funktioniert nur unter Last

Ein weiteres Problem, welches wir bereits vor langer Zeit bei einem anderen Kunden entdeckt haben, ist, dass das empfohlenen Channel Failover-Vorgehen [ 2 ]:

slave1> STOP SLAVE; slave1> SELECT MAX(epoch) AS latest FROM mysql.ndb_apply_status; master2> SELECT SUBSTRING_INDEX(File, '/', -1) AS master_log_file , Position AS master_log_pos FROM mysql.ndb_binlog_index WHERE epoch > <latest> ORDER BY epoch ASC LIMIT 1; slave2> CHANGE MASTER TO master_log_file='<master_log_file>', master_log_pos=<master_log_pos>;

nur funktioniert, wenn wir Last auf dem MySQL Cluster haben. Wenn wir gar keine Last haben, gibt diese Abfrage ein leeres Resultat zurück und es muss der Befehl SHOW MASTER STATUS dazu verwendet werden.

Dokumentationsfehler über log_slave_updates

Diese Situation haben wir fortwährend für Kanal ch2 und ch3 vom Cluster B auf den Cluster A wenn wir KEINE Last auf Cluster B haben und streng der Dokumentation gefolgt wird, wo für ein solches Gebilde gesagt wird: log_slave_updates DARF NICHT eingeschaltet (MUST NOT be enabled) [3] werden.

Ich habe dieses Problem mit ein paar Leuten diskutiert und bin zur Ansicht gekommen, dass die MySQL Cluster Dokumentation hier punktuell falsch ist. Der Master für eine 2 Cluster Replikation KANN log_slave_updates eingeschaltet haben und IMHO MUSS der Master einer 3 Cluster Replikation log_slave_updates eingeschaltet haben.

Aber trotzdem, wenn wir keine Last auf beiden Servern haben, müssen wir das Verfahren ändern um die korrekte Binary Log Position zu bestimmen, wenn wir den Kanal wechseln wollen. Das macht es etwas schwieriger wenn wir den Channel Fail-over automatisieren oder skripten wollen.

Leere Epochen

Früher, wenn ich mich recht erinnere, hat MySQL Cluster immer leere Epochen ins Binary Log geschrieben. Das hatte gewährleistet, dass immer eine gewisse Last auf den Kanälen geherrscht hat. Dann habe ich bei den MySQL Cluster Entwicklern reklamiert und diese haben dieses Problem behoben. Aber für die eben besprochene Situation wäre dieses Verhalten geradezu nützlich und würde Sinn machen. Also habe ich nach der ndb-log-empty-epochs Variablen Ausschau gehalten und gehofft, dass sie dieses Verhalten wieder ermöglicht. Aber irgendwie hat der MySQL Cluster für dieses Set-Up trotz der Verwendung dieser Variable keine leeren Epochen ans Binary Log gemeldet. Zumindest nicht in der kurzen Zeit, wo ich mich mit diesem Problem beschäftigt hatte.

Log_slave_updates wird auch durch den Binlog Injector Thread berücksichtigt

Eine weitere Erkenntnis mit log_slave_updates war, dass dieser Parameter entsprechend der Dokumentation, nur zum Zug kommt, wenn ein Slave auch als Master agiert [4]. Was heisst, dass er nur die Daten in sein Binary Log schreibt, wenn er die Daten direkt von seinem Master erhält. Es macht den Anschein, dass dies eine falsche Annahme ist. Ein Master scheint auch die Statements welche durch den Binlog Injector Thread [5] über den Cluster kommen, in sein Binary Log zu schreiben. Dies ist möglicherweise ein weiterer Dokumentationsfehler oder zumindest eine Dokumentationslücke.

Skip_slave_start sollte verwendet werden

Eine weiter Stolperfalle ist, dass ich vergessen habe, die Variable skip-slave-start zu setzen. Diese Variable sollte IMHO in einem solchen Set-up immer auf dem Slave gesetzt sein. Wenn ein Slave startet, kann er nicht wissen, ob er der aktive Channel sein wird oder nicht.

Zusammenfassung
  • Überwache Deine Replikations-Kanäle.
  • Nutze auto_increment_increment und auto_increment_offset wenn auf beide MySQL Cluster gleichzeitig geschrieben wird oder vermeideAUTO_INCREMENT.
  • Verwende ein kluges Channel Fail-over Skript.
  • Verwende log_slave_updates auf allen Mastern.
  • Verwende skip_slave_start auf allen Slaves.

Das waren die Erkenntnisse unseres letzten Einsatzes mit MySQL Cluster Replikation und Fail-over Replikations-Kanälen. Wenn Sie weitere oder andere Erfahrungen gesammelt haben, wären wir froh, von Ihnen darüber zu hören.

Ein Skript zum automatisierten Fail-over der Kanäle kann unter Download gefunden werden.

MyEnv für Multi-Datenbank Set-ups

Oli Sennhauser - Wed, 2010-12-01 12:21
Taxonomy upgrade extras: mysqlmyenvenvironmentmulti instancedatabasevirtualizationconsolidationSaaSgerman

Vor ein paar Wochen haben wir einem unserer Kunden unser MyEnv gezeigt. Er war sehr interessiert daran und hat uns geraten MyEnv einer breiten Öffentlichkeit bekannter zu machen. In Tat und Wahrheit ist das MyEnv bereits seit mehreren Jahren verfügbar und kann frei heruntergeladen werden...

Aber bis anhin konnten wir uns noch kein Herz fassen es gross einer breiten Öffentlichkeit anzukündigen weil es noch überhaupt nicht Endbenutzer tauglich war. Nachdem ich ein Wochenende damit verbracht habe, das MyEnv benutzerfreundlicher zu machen, einige Zeilen Code zu konsolidieren, altes Zeugs zu löschen, etc., denke ich, dass es jetzt akzeptable für die Öffentlichkeit, aber noch nicht perfekt ist (release early release often?).

Was ist MyEnv?

MyEnv ist ein Set von Skripten um bequem mehrere MySQL oder MariaDB Datenbankinstanzen auf ein und dem selben Server zu betreiben. Es können sogar mehrere Datenbanken mit verschiedenen Binaryversionen betrieben werden.

Meines Erachtens ist MyEnv bequemer als mysqld_multi und bietet mehr Funktionalität.

Wann soll MyEnv eingesetzt werden?

MyEnv macht Sinn, sobald mehrere MySQL Datenbanken auf einem Server installiert werden sollen. Das ist üblicherweise der Fall wenn:

  • viele verschiedene kleine Datenbanken von mehreren Servern auf einen Server konsolidiert werden sollen oder,
  • wenn die Daten mehrerer Kunden aus Sicherheitsgründen oder auf Kundenwunsch in verschiedenen Datenbanken gehalten werden müssen. Zum Beispiel wenn eine Applikation als Software-as-a-Service (SaaS) Lösung angeboten wird.

MyEnv hat den Vorteil gegenüber Virtualiserungslösungen (wie VMWare oder VirtualBox), dass der Overhead der virtuellen Maschine und des zusätzlichen Betriebssystems weg fällt. Somit können mehrere MySQL/MariaDB Datenbanken auf weniger Maschinen betrieben werden.

Probiert es also aus. Wenn Euch das MyEnv von Nutzen ist, sind wir froh. Bitte lasst uns auch wissen, wenn Ihr auf Probleme mit dem MyEnv stosst, wenn Ihr Bugs findet oder wenn Ihr einen Verbesserungsvorschlag habt.

Wenn allgemeine Fragen zur Konsolidierung von MySQL Datenbankservern oder MySQL in Software-as-a-Service (SaaS) Umgebungen bestehen, würde Euch unser MySQL Beratungsteam, gerne zur Seite stehen...

Weitere Informationen finden Sie in der MyEnv Dokumentation.

WAMP oder LAMP?

Oli Sennhauser - Fri, 2010-10-22 17:51
Taxonomy upgrade extras: wamplampgerman

Einer unserer Kunden hat mich kürzlich gefragt, was wir ihm empfehlen: WAMP oder LAMP? Also Windows oder Linux zusammen mit Apache, MySQL und PHP.

Im weiteren hat er angemerkt, sein Lieferant habe gesagt, dass MySQL Cluster NICHT auf Windows läuft...

Das ist eine nicht triviale Frage. Was wir in so einem Fall raten, ist folgende Punkte zu beachten:

  • Ca. 80% der MySQL-Installationen laufen auf Linux! Es ist also auf Linux mit den wenigsten Problemen zu rechnen. Weitere Plattformen, welche man von Zeit zu Zeit bei Kunden antrifft sind: Windows, BSD-Derivate und Solaris (in etwa in dieser Reihenfolge).
  • MySQL als Firma und die MySQL-Mitarbeiter haben am meisten Know-How auf Linux, Mac, Solaris und Windows (in etwa in dieser Reihenfolge).
  • Also rein statistisch gesehen hat man mit Linux wahrscheinlich am wenigsten Ärger oder Probleme zu erwarten.
  • Wie der Name LAMP schon sagt werden diese 4 Komponenten häufig zusammen eingesetzt und sollten daher am besten ineinander eingeschliffen sein.
  • Das Linux für den professionellen Einsatz besser geeignet ist als Windows, würde ich persönlich bejahen (ich bin Linux-biased). Aber da scheiden sich bekanntlich die Geister! Windows-Admins werden jetzt wahrscheinlich einen roten Kopf kriegen... :)
  • Grundsätzlich denke ich aber, dass die Unterschiede zwischen Windows und Linux was Stabilität, Sicherheit und Performance anbelangen, heute marginal sind.
  • Was die Sicherheit anbelangt ist sicher PHP das grösste Risiko (respektive das, was die Entwickler damit anstellen).
  • Wenn Kunden ganz freaky Sachen machen wollen, denke ich, das Linux wegen seiner Flexibilität besser geeignet ist als Windows (siehe Facebook und Konsorten...).
  • Meines Erachtens das Wichtigste Kriterium ist das Know-How sowohl im Betrieb als auch, eingeschränkt, in der Entwicklung. Ich denke, dass dieses den grössten Einfluss hat. Also: Wenn der Betrieb keine Ahnung von Linux hat: Finger davon lassen!
  • Die Aussage des Lieferanten ist teilweise richtig. Früher lief MySQL Cluster ausschliesslich auf Linux (und anderen Unixoiden). Seit MySQL Cluster 7.1 wird aber mehr Gewicht auf Windows gelegt und Oracle hat MySQL Cluster 7.1 sogar als GA deklariert (GA = General Available = Production Ready). MySQL Support hat darüber aber die Nase gerümpft und den Kopf geschüttelt...
  • Oracle positioniert ja das Produkt MySQL neu gegen Windows SQL-Server auf Windows und wird voraussichtlich sehr viel Entwicklungstätigkeit da rein stecken!
  • Achtung: MySQL Cluster ist KEINE General-Purpose Datenbank. Man kann also NICHT einfach denken, ich baue meine Applikation und hänge dann einen MySQL Cluster drunter. Bei MySQL Cluster wird eine Applikation spezifisch auf dieses Produkt zugeschnitten! Anders verhält es sich mit einem geclusterten MySQL (MySQL HA, geht sowohl unter Windows als auch unter unixoiden Systemen).

Wie der MySQL Optimizer schummelt, wenn es um MySQL Cluster geht...

Oli Sennhauser - Thu, 2010-05-20 11:50
Taxonomy upgrade extras: mysqlviewMySQL ClusterhintOptimizergerman

Bei einem Kunden sind wir auf ein nettes Beispiel gestossen, wie der MySQL Optimizer schummelt, wenn er mit dem MySQL Cluster zusammen arbeiten sollte. Dieser Kunde hat Abfragen, welche auf dem Entwicklungssystem nicht sonderlich langsam gelaufen sind. Aber wenn er diese Abfragen auf dem Abnahmetest-System (mit wesentlich mehr Daten) ausführt, benötigen diese viel zu viel Zeit, was für ihn nicht akzeptabel ist, da diese Abfragen mehrmals pro Sekunde abgesetzt werden können.

Was ist genau passiert?

Zu aller erst haben wir uns den Ausführungsplan der Abfragen angeschaut, welcher durch den MySQL Optimizer generiert wird:

EXPLAIN SELECT t0.*, t1.* FROM t2 JOIN t0 ON t2.t0_id = t0.id JOIN t1 ON t1.t0_id = t0.id WHERE t2.productnumber LIKE '%3301' AND t0.organization_id = 157 AND t0.type = 'User'; 1 row in set (8.78 sec) +-------+--------+---------------------+---------------+---------+----------+------+-----------------------------------+ | table | type | possible_keys | key | key_len | ref | rows | Extra | +-------+--------+---------------------+---------------+---------+----------+------+-----------------------------------+ | t0 | ref | PRIMARY,ORG_ID,TYPE | ORG_ID | 5 | const | 10 | Using where with pushed condition | | t1 | eq_ref | PRIMARY | PRIMARY | 4 | t0.id | 1 | | | t2 | ref | PRODUCTNUMBER | PRODUCTNUMBER | 5 | t1.t0_id | 1 | Using where with pushed condition | +-------+--------+---------------------+---------------+---------+----------+------+-----------------------------------+

Der Ausführungsplan schaut auf den ersten Blick nahezu perfekt aus. 10 Datensätze für die erste Tabelle (t0) und anschliessend ein Nested Loop Join über t1 und t2. Aber das Slow Query Log zeigt ein etwas anderes Bild:

# Query_time: 8.784943 Lock_time: 0.000367 Rows_sent: 1 Rows_examined: 40052

40052 Datensätze werden angelangt (Rows_examined) für ein Resultat von nur einem EINZIGEN Datensatz (Rows_sent). Gemäss dem Ausführungsplan sollten wir nicht mehr als 10 bis 30 Datensätze anlangen müssen (hängt davon ab, wie gezählt wird).

Der SHOW SESSION STATUS Befehl vor und nach der Abfrage gibt uns folgende Information:

SHOW SESSION STATUS LIKE 'ndb%count';

Vorher:

+--------------------------------+-----------+ | Variable_name | Value | +--------------------------------+-----------+ | Ndb_execute_count | 0 | | Ndb_scan_count | 0 | +--------------------------------+-----------+

Nachher:

+--------------------------------+-----------+ | Variable_name | Value | +--------------------------------+-----------+ | Ndb_execute_count | 40052 | | Ndb_scan_count | 8 | +--------------------------------+-----------+
Ndb_execute_count: Zeigt die Anzahl der Round-Trips zum NDB Kernel, welche durch die Operationen durchgeführt wurden. [1] Ndb_scan_count: Diese Variable beinhaltet die Gesamtzahl ausgeführter Scans. [2]

Gemäss den GLOBAL STATUS VARIABLES verursachen wir 40052 Round-Trips zum Cluster und 8 Scans. Aus dem Ausführungsplan erwarte ich kleiner gleich 21 Round-Trips und 2 bis 3 Scans.

Mit dieser Information haben wir immherhin eine erste Spur gefunden, warum es so lange dauern könnte. Eine kleine Schätzung zeigt, dass wir auf der richtigen Fährte sind:

60 µs (ping) pro Round-Trip x 40052 Round-Trips = 2.4 Sekunden.

Mit 2.4 Sekunden sind wir zumindest bei der richtigen Grössenordnung für die Problemsuche angelangt.

Aber warum in aller Welt macht er 40k Round-Trips, wenn wir ca. 20 erwarten?

Versuchen wir händisch auszuführen, was der Optimizer tun sollte:

SELECT COUNT(*) FROM t0 WHERE t0.organization_id = 157 AND t0.type = 'User'; 40044 rows in set (0.78 sec) +-------+------+---------------+--------+---------+-------+------+-----------------------------------+ | table | type | possible_keys | key | key_len | ref | rows | Extra | +-------+------+---------------+--------+---------+-------+------+-----------------------------------+ | t0 | ref | ORG_ID,TYPE | ORG_ID | 5 | const | 10 | Using where with pushed condition | +-------+------+---------------+--------+---------+-------+------+-----------------------------------+

Aha! Der Ausführungsplan schaut gleich aus. Und die Abfrage gibt 40044 Datensätze (in 0.78 s) zurück anstatt nur 10!!! Also hat uns der Optimizer angeschummelt!

SHOW SESSION STATUS zeigt:

Ndb_execute_count = 1 Ndb_scan_count = 1

Der zweite Schritt verursacht dann die grosse Anzahl von Round-Trips (und verbraucht die meiste Zeit):

SELECT COUNT(*) FROM t0 JOIN t1 ON t1.t0_id = t0.id WHERE t0.organization_id = 157 AND t0.type = 'User'; 7 rows in set (8.73 sec) Ndb_execute_count = 40044 Ndb_scan_count = 1

Der letzte Schritt verursacht weitere 7 Round-Trips (7 Datensätze aus Schritt 2) und 6 Scans:

SELECT COUNT(*) FROM t2 JOIN t0 ON t2.t0_id = t0.id JOIN t1 ON t1.t0_id = t0.id WHERE t2.productnumber LIKE '%3301' AND t0.organization_id = 157 AND t0.type = 'User'; 1 row in set (8.78 sec) Ndb_execute_count = 7 Ndb_scan_count = 6

Schluss: Der MySQL Optimizer hat die falsche Entscheidung getroffen, als er mit Tabelle t0 anfing.

Wir werden selber Optimizer

Jetzt wollen wir es besser machen... Welche Möglichkeiten haben wir?

Wir könnten anfangen mit:

  • Tabelle t2, indem wir eine Full-Table-Scan mit anschliessender Filterung oder einen Index-Scan mit anschliessender Filterung auf dem Kriterium t2.productnumber LIKE '%3301', welches ein "schlechter" Filter ist, machen.
  • Tabelle t0, indem wir einen Full-Table-Scan mit anschliessender Filterung oder einen Index-Scan mit anschliessener Filterung auf organization_id = 157 ODER type = 'User' (zur Zeit gibt es KEINEN kombinierten Index auf beide Attribute zusammen) machen.
  • Tabelle t1, indem wir einen Full-table-Scan machen (was der Cluster, so wie es aussieht, sowieso macht).

Somit suchen wir als besten Anfangspunk zuerst das kleinste Resultat, weil Round-Trips in MySQL Cluster Joins weh tun:

SELECT COUNT(*) FROM t2 WHERE t2.productnumber LIKE '%3301'; --> 1 Datensatz SELECT COUNT(*) FROM t0 WHERE t0.organization_id = 157 AND t0.type = 'User'; --> 40044 Datensätze (das kennen wir bereits und wissen, dass es schlecht ist) SELECT COUNT(*) FROM t1; --> 325 Datensätze

Mit Tabelle t2 in dieser speziellen Abfrage anzufangen und einen Full-Table-Scan zu riskieren sollte eine wesentlich besser Antwortzeit geben. Mehr über diese Technik finden Sie unter [3].

Um zu sehen, ob unsere Idee eine bessere Antwortzeit ergibt, zwingen wir den MySQL Optimizer den STRAIGHT_JOIN [4] Hint zu verwenden:

SELECT STRAIGHT_JOIN COUNT(*) FROM t2 JOIN t0 ON t2.t0_id = t0.id JOIN t1 ON t1.t0_id = t0.id WHERE t2.productnumber LIKE '%3301' AND t0.organization_id = 157 AND t0.type = 'User'; 1 row in set (0.02 sec) +----+-------------+-------+--------+---------------------+---------+---------+----------+------+-----------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+--------+---------------------+---------+---------+----------+------+-----------------------------------+ | 1 | SIMPLE | t2 | ALL | PRODUCTNUMBER | NULL | NULL | NULL | 1099 | Using where with pushed condition | | 1 | SIMPLE | t0 | eq_ref | PRIMARY,ORG_ID,TYPE | PRIMARY | 4 | t2.t0_id | 1 | Using where with pushed condition | | 1 | SIMPLE | t1 | eq_ref | PRIMARY | PRIMARY | 4 | t0.id | 1 | Using where | +----+-------------+-------+--------+---------------------+---------+---------+----------+------+-----------------------------------+ Ndb_execute_count = 3 Ndb_scan_count = 1
SELECT STRAIGHT_JOIN COUNT(*) FROM t2 JOIN t1 ON t1.t0_id = t2.t0_id JOIN t0 ON t1.t0_id = t0.id WHERE t2.productnumber LIKE '%3301' AND t0.organization_id = 157 AND t0.type = 'User'; 1 row in set (0.02 sec) +----+-------------+-------+--------+---------------------+---------+---------+----------+------+-----------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+--------+---------------------+---------+---------+----------+------+-----------------------------------+ | 1 | SIMPLE | t2 | ALL | PRODUCTNUMBER | NULL | NULL | NULL | 1099 | Using where with pushed condition | | 1 | SIMPLE | t1 | eq_ref | PRIMARY | PRIMARY | 4 | t2.t0_id | 1 | | | 1 | SIMPLE | t0 | eq_ref | PRIMARY,ORG_ID,TYPE | PRIMARY | 4 | t1.t0_id | 1 | Using where with pushed condition | +----+-------------+-------+--------+---------------------+---------+---------+----------+------+-----------------------------------+ Ndb_execute_count 3 Ndb_scan_count 1

Es schaut so aus als ob Variante 2 und 3 mehr oder minder gleichwertig sind. Und wir haben die Abfrage von ca. 9 Sekunden auf ca. 20 ms (f=450!) verbessert.

Unglücklicherweise konnte der Kunde diese Lösung nicht akzeptieren, weil sein generisches Framework Abfrage-Hints nicht erlaubt und seine Applikation generisch auch für andere Datenbank-Backends sein soll.

Was mir als Alternative weiter in den Sinn kam, ist eine VIEW anzulegen um den Hint zu kapseln:

CREATE VIEW t2_t1_t0_v AS SELECT STRAIGHT_JOIN t0.*, t1.*, t2.productnumber FROM t2 JOIN t1 ON t1.t0_id = t2.t0_id JOIN t0 ON t1.t0_id = t0.id;

Aber es sieht danach aus, dass die Abfrage derart umgeschrieben wird, dass der Hint ignoriert wird:

EXPLAIN SELECT COUNT(*) FROM t2_t1_t0_v WHERE productnumber LIKE '%3301' AND organization_id = 157 AND type = 'User'; +----+-------------+-------+--------+---------------------+---------------+---------+----------+------+-----------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+--------+---------------------+---------------+---------+----------+------+-----------------------------------+ | 1 | SIMPLE | t0 | ref | PRIMARY,ORG_ID,TYPE | ORG_ID | 5 | const | 10 | Using where with pushed condition | | 1 | SIMPLE | t1 | eq_ref | PRIMARY | PRIMARY | 4 | t0.id | 1 | | | 1 | SIMPLE | t2 | ref | PRODUCTNUMBER | PRODUCTNUMBER | 5 | t1.t0_id | 1 | Using where | +----+-------------+-------+--------+---------------------+---------------+---------+----------+------+-----------------------------------+

Wenn die Abfrage wie folgt (mit Hint) abgesetzt wird, wird sie wieder in der richtigen Reihenfolge ausgeführt. Aber das wollen wir ja gerade wegen unserem Kunden vermeiden...

SELECT STRAIGHT_JOIN COUNT(*) FROM t2_t1_t0_v WHERE productnumber LIKE '%3301' AND organization_id = 157 AND type = 'User';

Gemäss MySQL ist das kein Bug sonderen ein "Feature Request"... :-( Mehr Informationen können Sie finden unter MySQL Bug #28700.

Risiken
  • Ein Problem mit Hints ist, das sie zukünftigen MySQL Releases/Features die Möglichkeit nehmen, Ihre volle Pracht zu entfalten, wenn Sie denn irgendwann einmal in ferner Zukunft implementiert werden sollten. Zum Beispiel wenn BKA (batched key access) [9] oder Push-Down-Joins [5] wahr werden oder wenn der Optimizer schlauer wird und die MySQL Cluster Datenverteilung kennt und damit besser Schätzungen macht. Wir verbauen uns damit möglicherweise besser Ausführungspläne in der Zukunft.
  • Ein zweiter Problem ist, dass das Beginnen mit einem Full-Table-Scan auf t2 nicht skaliert, wenn die Menge der Daten in Zukunft grösser wird. An einem bestimmten Punkt wird der Full-Table-Scan langsamer werden als 40k Round-Trips.
  • Was wir in diesem Artikel überhaupt noch nicht angeschaut haben, ist dass es noch grosses Verbesserungspotential bei der Daten- und Tabellenstruktur für das Filterkriterium auf t2 gibt. Eine Suche nach "%xyz% ist für die Datenbank schlecht und führt zu einem Scan. Wenn der Inhalt des Feldes gedreht wird in "zyx%' kann eine Suche den Index nutzen und ein Full-Table-Scan wird vermieden.
  • Wenn der Trick mit der VIEW funktioniert hätte, gäbe es ein weiteres Problem: Weil die VIEW im SQL Node gespeichert wird und nicht im MySQL Cluster, muss sichergestellt werden, das ALLE SQL Nodes synchron gehalten werden und dass das Backup der VIEWs richtig gemacht wird. Dies ist nicht ganz einfach mit MySQL Cluster in Kombination mit Objekten, welche auf den SQL Nodes gespeichert sind.
  • Wenn das Filterkriterium auf t2 nicht so selektiv wäre, würde der Trick so nicht funktionieren.
Was haben wir daraus gelernt?
  • Die Menge der Testdaten ist relevant. Wenn Sie wesentlich mehr Daten auf dem Produktionssystem als auf dem Testsystem haben werden Sie nicht auf die Performance-Probleme stossen, bis sie Life gehen. Also füllen Sie Ihr Testsystem with der selbe Menge an Daten, wie Ihr Produktivsystem, oder zumindest Ihr Acceptance-Test-System.
  • Der MySQL Optimizer schummelt, weil ihm die wirkliche Datenverteilung nicht bekannt ist. Der MySQL Optimizer arbeitet zur Zeit am besten mit MyISAM/Maria zusammen. Ein "guter" Ausführungsplan für die selbe Abfrage mit MyISAM/Maria Tabellen sieht wie folgt aus:
    +----+-------------+-------+--------+---------------------+---------------+---------+----------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+--------+---------------------+---------------+---------+----------+------+-------------+ | 1 | SIMPLE | t1 | ALL | PRIMARY | NULL | NULL | NULL | 325 | | | 1 | SIMPLE | t2 | ref | PRODUCTNUMBER | PRODUCTNUMBER | 5 | t1.t0_id | 3 | Using where | | 1 | SIMPLE | t0 | eq_ref | PRIMARY,ORG_ID,TYPE | PRIMARY | 4 | t1.t0_id | 1 | Using where | +----+-------------+-------+--------+---------------------+---------------+---------+----------+------+-------------+

    Wir könnten auch diese Möglichkeit noch probieren...

  • Die ndb_%count Status Variable ist irgendwie nicht korrekt implementiert oder die Dokumentation beschreibt nicht das aktuelle verhalten. Siehe auch MySQL bug #52940.
  • Hints und VIEWs arbeiten nicht wie erwartet zusammen.
  • MySQL Cluster führt mehr Scans als erwartet aus. Aber wir können dies zumindest mit der ndb_%count Status Variablen nachweisen.
Weitere Untersuchungen

In der Dokumentation sind einige Parameter zu finden (ndb_index_stat_cache_entries, ndb_index_stat_enable und ndb_index_stat_update_freq [7]) welche den Eindruck vermitteln, dass Sie hier helfen könnten. Aber wir haben keine Möglichkeit gefunden, wie wir mit diesen Variablen das Verhalten des MySQL Optimizers beeinflussen können. Wenn uns jemand einen Hinweis oder ein Beispiel dazu zukommen lässt, würde uns dies sehr freuen.

MySQL Cluster Beratung von FromDual

Wenn Sie mehr über MySQL Cluster und Abfrageoptimierung wissen möchten, würde es uns freuen, Sie als unseren Kunden besuchen zu dürfen.

Literatur [1] Ndb_execute_count
[2] Ndb_scan_count
[3] Dan Tow: SQL Tuning
[4] STRAIGHT_JOIN
[5] Trying out MySQL Push-Down-Join (SPJ) preview
[6] Bug #52940: ndb_*_count status variables ARE session related in contrary what docu says.
[7] ndb_index_stat%
[8] Lesen Sie auch den sehr informativen Artikel von Johan Andersson über das selbe Thema: Optimizing Queries on Cluster
[9] Batched Key Access (BKA) [10] How does the MySQL Optimizer work [11] Bug #28700: VIEWs using the MERGE algorithm ignore STRAIGHT_JOIN
Subscribe to FromDual - MySQL, Galera Cluster, MariaDB and Percona Server support, SLA and services aggregator - FromDual TechFeed (de)