Feed aggregator

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

SELECT COUNT(*) from table;

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

SHOW TABLE STATUS LIKE 'test';

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

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

Unsere ursprüngliche Situation

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

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

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

SELECT COUNT(*) FROM offer;

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

Die Lösung des Problems

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

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

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

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

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

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

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

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

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

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

Taxonomy upgrade extras: innodbmaterialized viewsmaterialised viewsmyisamselectshadow tablecount

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

SELECT COUNT(*) from table;

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

SHOW TABLE STATUS LIKE 'test';

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

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

Unsere ursprüngliche Situation

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

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

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

SELECT COUNT(*) FROM offer;

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

Die Lösung des Problems

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

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

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

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

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

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

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

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

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

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

Taxonomy upgrade extras: innodbmaterialized viewsmaterialised viewsmyisamselectshadow tablecount

Its a known problem that changing the Storage Engine from MyISAM to InnoDB can cause some problems [ 1 ] if you have queries of this type:

SELECT COUNT(*) from table;

Luckily this query happens rarely and if, the query can be easily omitted or worked around by guesstimating the amount of rows in the table. For example with:

SHOW TABLE STATUS LIKE 'test';

But in some rare cases customer really needs these values for some reasons. To not exhaust the resources of the server with this query which can be fired quite often in some cases we make use of the materialized views/shadow table technique [ 2 ].

The following example illustrates how to do this.

Our original situation

We have an offer table which is feed by a host system:

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');

The query we want to perform looks like this:

SELECT COUNT(*) FROM offer;

This query becomes expensive when you have zillions of rows in your table.v

The work around

To work around the problem we create a counter table where we count the rows which are inserted, updated or deleted on the offer table.

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;

To fill this counter table we need an initial snapshot:

INSERT INTO counter SELECT type, COUNT(*), NULL FROM offer GROUP BY type; SELECT * FROM counter; SELECT COUNT(*) FROM counter; Update the counter table

To keep the counter table up-to-date we need the following 3 triggers:

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 ;

Now we can test some cases and compare the results of both tables:

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;

This solution has the advantage that we get also a very fast response on the number of rows for a specific order type. Which would be also expensive for MyISAM tables...

Taxonomy upgrade extras: mysqltalkconferencefroscon

Also this year we will have a special track for MySQL, Galera, Percona und MariaDB at the FrOSCon in St. Augustin in Germany. The conference is scheduled for August 25 and 26 2012.

Together with the PostgreSQL people we are organizing a sub-conference for Open Source RDBMS there. Now we are looking for interesting talks about MySQL and related techniques like Galera, Percona, MariaDB. The only restriction for the talks is: They must be about an Open Source topic.

We encourage you to send your proposals.

After registering you can Submit a new event. Choose the Databases track. It makes easier to assign the proposal.

Regarding the talks: Please do NOT add talks about NON Open Source solutions. It can be about some new technical things or about some user experience with MySQL technology.

Keep in mind the audience is going to be technical driven. Think about the audience as colleges and not as decision makers.

Please help spreading the word for the Conference by blogging and twittering about it (#froscon)!

And now let us go...

Oli

Taxonomy upgrade extras: performanceperformance monitoringperformance monitormpmmaaswindows

A customer recently was asking why our MySQL Performance Monitor (MPM) is not working on Windows...? The answer is short: It was developed on Linux and never tested on Windows...

But I was wondering how much effort it would take to make it work on Windows as well.

I was quite surprised how fast it was to make the basic functionality working on Windows. It took me less than one hour to install, configure and patch MPM.

Patch MPM

The file FromDualMySQLagent.pm has to be patched at 2 locations. The lock file name must be something understandable by Windows (for example C:\Temp\FromDualMySQLagent.lock. We will fix that in the next MPM release.

40 # Should NOT be hard coded, tofix later!!! 41 # Does not work on Windows! 42 my $lAgentLockFile = '/tmp/FromDualMySQLagent.lock'; 43 # Check if lock file already exists and complain if yes ... 533 # Does not work on Windows! 534 my $lAgentLockFile = '/tmp/FromDualMySQLagent.lock'; 535 if ( ! unlink($lAgentLockFile) ) {

There are at least 2 other parts in the code which make troubles. But they can be circumvented by disabling the modules (server and process) respectively configuring MPM accordingly.

A basic MPM configuration file on Windows

We have used the following basic configuration file:

[default] LogFile = C:\Users\oli\logs\mpm.log Debug = 2 CacheFileBase = C:\Users\oli\cache MaaS = on Hash = <your hash> Methtode = http Url = http://support.fromdual.com/maas/receiver.php [FromDual.Win_laptop] Modules = mpm [FromDual.Win_laptop.win_db]

In your case there is possibly some more configuration needed. For details please look here.

Now we are quite confident that the next MPM release will work more or less with Windows out of the box. If you cannot wait try it out with this hack. More details about installing the MPM on Windows you can find here. If you run into problems please report them in the MPM installation on Windows forum. All paying customers can naturally use our support platform.

When you install a Galera Cluster for MySQL for High Availability (HA) it is not enough to install the Database Cluster to achieve this goal. You also have to make the application aware of this HA functionality. This is typically done with some kind of load balancing mechanism between the database and the application.

We have several possibilities how to make such a load balancing possible:

• We build such a load balancing mechanism directly into the application.
• When we use Java or PHP we can use the fail-over functionality of the connectors (Connector/J, mysqlnd-ms).
• If we cannot touch the application we can put a load balancing mechanism between the application and the database. This can be done with:
  • a Hardware Load Balancer,
  • a Software Load Balancer (Pen, GLB, LVS, HAProxy and others...),
  • or with MySQL-Proxy.

Building the Galera Load Balancer

As an example we look at the Galera Load Balancer (GLB). The documentation about it you can find in the README file.

It can be built as follows:

wget http://www.codership.com/files/glb/glb-0.7.4.tar.gz tar xf glb-0.7.4.tar.gz cd glb-0.7.4 ./configure make make install
Starting the Galera Load Balancer

The Galera Load Balancer will be started as follows:

./glbd --daemon --threads 6 --control 127.0.0.1:4444 127.0.0.1:3306 \ 192.168.56.101:3306:1 192.168.56.102:3306:1 192.168.56.103:3306:1 Incoming address: 127.0.0.1:3306 , control FIFO: /tmp/glbd.fifo Control address: 127.0.0.1:4444 Number of threads: 6, source tracking: OFF, verbose: OFF, daemon: YES Destinations: 3 0: 192.168.56.101:3306 , w: 1.000 1: 192.168.56.102:3306 , w: 1.000 2: 192.168.56.103:3306 , w: 1.000
Querying the Galera Load Balancer

It can be queried as follows:

echo getinfo | nc -q 1 127.0.0.1 4444 Router: ---------------------------------------------------- Address : weight usage conns 192.168.56.101:3306 : 1.000 0.667 2 192.168.56.102:3306 : 1.000 0.500 1 192.168.56.103:3306 : 1.000 0.500 1 ---------------------------------------------------- Destinations: 3, total connections: 4

and

echo getstats | nc -q 1 127.0.0.1 4444 in: 37349 out: 52598 recv: 89947 / 1989 send: 89947 / 1768 conns: 225 / 4 poll: 1989 / 0 / 1989 elapsed: 76.59987
Draining nodes with Galera Load Balancer

Let's assume, we want to take out node 192.168.56.101 from the Load Balancer for maintenance purposes, this can be done as follows:

echo 192.168.56.101:3306:0 | nc -q 1 127.0.0.1 4444 echo getinfo | nc -q 1 127.0.0.1 4444 Router: ---------------------------------------------------- Address : weight usage conns 192.168.56.101:3306 : 0.000 1.000 0 192.168.56.102:3306 : 1.000 0.667 2 192.168.56.103:3306 : 1.000 0.667 2 ---------------------------------------------------- Destinations: 3, total connections: 4
Removing and adding nodes from Galera Load Balancer

If you want to shrink or grow your database cluster, removing and adding nodes works as follows:

echo 192.168.56.103:3306:-1 | nc -q 1 127.0.0.1 4444 echo 192.168.56.103:3306:2 | nc -q 1 127.0.0.1 4444

And now have fun playing around with your Galera Load Balancer...

Taxonomy upgrade extras: mysqlcoursetrainingmysql-coursemysql-training

Am 18. bis 22. Juni findet an der Heinlein Akademie in Berlin ein fünftägiger hands-on Workshop MySQL für Profis statt. Es hat noch Plätze frei!

Anmeldung und weitere Infos unter: http://www.heinlein-support.de/schulung/mysql-fuer-profis

Taxonomy upgrade extras: MySQL Clusterschulungtrainingmysql-training

Am 30. und 31. Mai findet im Linux-Hotel in Essen ein MySQL-Cluster Kurs statt. Der Kurs wird durchgeführt und es hat noch Plätze frei!

Weitere Infos unter: http://www.linuxhotel.de/kurs/mysql-cluster/

Anmeldung: http://www.linuxhotel.de/cgi-bin/anmeldung_kurs.pl?veranstaltung=MySQL-C...

Taxonomy upgrade extras: performanceenterprise monitormonitoringperformance monitoringnewsperformance monitorreleasegraphgalerampmmaas

On April 2nd 2012 FromDual released the new version v0.9 of its Performance Monitor for MySQL (mpm). The new version can be downloaded from here.

The Performance Monitor for MySQL (mpm) is an agent which is hooked into Zabbix. Zabbix is an integrated Enterprise Monitoring solution which can produce performance graphs and alerting.

The changes in the new release are:

New functionality

• A new server module gathers MySQL database specific server informations. This is especially interesting for the Monitoring as a Service customers.
• You can monitor Galera Cluster for MySQL now. All important items of Galera Cluster for MySQL up to version 2.0 are gathered. The important Triggers and Graphs are available. FromDual Performance Monitor for MySQL becomes your indispensable tool for monitoring Galera Cluster!
• Trigger was added on low open_files_limit

Changed functionality

• Item history was reduced from 90 to 30 days to safe space on disk.
• InnoDB items were added and Graphs improved and cleaned-up.
• MyISAM items were added and Graphs improved.
• Query Cache items were added.
• Some triggers were too verbose or complained when they should not. Should be fixed now.
• MPM v0.9 was tested with Zabbix 1.8.11 and works without any problems.

Fixes

• Some items were not reported correctly. Fixed them.
• Many little bugs in different modules were fixed.

For more detailed informations see the CHANGELOG.

Installation and upgrade documentation can be found here.

If you want to stay tuned about the progess of the next release of mpm follow us on Twitter...

If you find any bug please report them to our bugs database. If you have some questions or if you want to exchange know-how related to the mpm please go to our Forum.

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

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

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

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

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

Die Tabelle wurde mit den folgenden Werten komprimiert:

ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=4

Anschliessend schaut die Lage wie folgt aus:

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

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

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

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

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

Ein paar nette Grafen InnoDB Buffer Pool activity

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

InnoDB compression time

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

InnoDB Row operations

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

Taxonomy upgrade extras: tabledatainnodbpartitioncompress

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

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

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

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

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

Die Tabelle wurde mit den folgenden Werten komprimiert:

ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=4

Anschliessend schaut die Lage wie folgt aus:

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

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

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

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

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

Ein paar nette Grafen InnoDB Buffer Pool activity

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

InnoDB compression time

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

InnoDB Row operations

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

Taxonomy upgrade extras: tabledatainnodbpartitioncompress

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

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

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

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

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

Die Tabelle wurde mit den folgenden Werten komprimiert:

ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=4

Anschliessend schaut die Lage wie folgt aus:

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

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

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

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

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

Ein paar nette Grafen InnoDB Buffer Pool activity

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

InnoDB compression time

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

InnoDB Row operations

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

Taxonomy upgrade extras: High Availabilitymysqlconsultingclusterinnodbfromdualsupportgaleracodershipmysql-supportmysql-consulting

Helsinki, Finland, Uster, Switzerland – February 18, 2012 – Codership, the provider of Galera Cluster for MySQL, and FromDual, a MySQL consulting company, today announced collaboration to offer Galera Cluster technology and related support and consulting services for Galera users all over the world, especially in German speaking countries Germany, Austria and Switzerland (DACH). Galera Cluster is a synchronous, true multi-master replication cluster for MySQL using the well known InnoDB storage engine. Customers can deploy Galera Cluster locally in LAN environments, as geo-clusters over the WAN or as virtual cluster in the cloud.

Galera Cluster for MySQL is offered as open source software. It can be downloaded freely from www.codership.com. Many of Codership customers are using Galera Cluster for business critical applications. FromDual will be offering consulting and support services for Galera users, especially in German speaking countries. FromDual has years of competence in MySQL consulting and support. They have a deep understanding of clustering and replication technologies and how to implement them into production. FromDual is the perfect partner for Codership said Seppo Jaakola, CEO of Codership.

With Galera we get a great high availability (HA) product for MySQL which removes all the pain we had with the existing MySQL HA solutions. Our customers are always looking for better ways to solve MySQL replication, scalability and management issues to secure 24/7 business availability and growth for the future business. Galera Cluster does exactly that. We are happy to add Galera Cluster to our consulting and support portfolio with the top level support from Codership says Oli Sennhauser, Senior MySQL consultant and CEO of FromDual.

Galera Cluster is used by users who need highly available MySQL database back-ends with very fast fail-over time for business critical applications like Social networks, Gaming platforms, Telecom/VoiP solutions, Media and entertainment sites, Business Software as a Service (SaaS), Platform as a Service (PaaS), ERP systems, web-shops, e-commerce solutions or similar critical applications.

About FromDual GmbH

FromDual is a global acting, neutral and vendor independent consulting, support and training company for MySQL, Percona Server, MariaDB and Galera Cluster with numerous customers all over the world in the Telecom, Media, Public Service, Internet and Industry sector. FromDual is Oracle Silver Partner and Open Database Alliance (ODBA) Silver Partner. In addition to its MySQL services FromDual distributes its Performance Monitor for MySQL for local installations or as Software as a Service solution. For more information about FromDual, their products, consulting and support services, please visit www.fromdual.com.

Press contact:

FromDual GmbH
Oli Sennhauser, CEO
E-Mail: oli.sennhauser@fromdual.com
Cell: +41 79 830 09 33

About Codership Oy

Codership develops fundamentally new replication and clustering solutions for open source databases, adopting novel ideas from latest DBMS and distributed computing research. The founders of Codership have long experience in developing several widely used MySQL clustering solutions before starting Galera development in 2007. Already thousands of users have chosen Galera Cluster solution – the Codership's flagship open source product and Codership is working actively for and with this growing user community. For more information about Codership, products, consulting and support services, please visit www.codership.com.

Press contact:

Codership OY
Seppo Jaakola, CEO
E-Mail: seppo.jaakola@codership.com
Cell: +358 405 105 938

Taxonomy upgrade extras: mysqlclusterfromdualreplikationgalerahochverfügbarkeitcodership

Helsinki, Finnland, Uster, Schweiz – 18. Februar 2012 – Codership, Anbieter des Galera Clusters für MySQL, und FromDual, eine MySQL Beratungsfirma, kündigen eine Zusammenarbeit bei der Verbreitung von Galera Cluster Technologie und dazugehörigen Support- und Beratungs-Dienstleistungen für Galera Anwender an. Galera Cluster ist ein synchroner, echter Multi-Master Replikations-Cluster für MySQL, welcher die weit verbreitete InnoDB Storage Engine nutzt. Anwender können Galera Cluster lokal in LAN-Umgebungen, als Geo-Cluster über das WAN oder als virtualisierten Cluster in der Cloud einsetzen.

Galera Cluster für MySQL wird als Open Source Software angeboten. Er kann kostenlos von der Website www.codership.com heruntergeladen werden. Viele der Codership Kunden nutzen Galera Cluster für geschäftskritische Anwendungen. FromDual bietet Beratungs- und Support-Dienstleistungen für Galera-Anwender, insbesondere in den deutschsprachigen Ländern Deutschland, Österreich und Schweiz (DACH) an. FromDual Mitarbeiter haben jahrelange Erfahrung in MySQL-Beratung und -Support. Sie haben ein tiefes Verständnis von Cluster- und Replikations-Technologien und wie diese im Betrieb umgesetzt werden müssen. FromDual ist der perfekte Partner für Codership, sagt Seppo Jaakola, CEO von Codership.

Mit Galera haben wir ein grossartiges Hochverfügbarkeits-Produkt für MySQL, welches alle Schmerzen beseitigt, welche wir bisher mit bestehenden MySQL HA-Lösungen gehabt haben. Unsere Kunden sind immer auf der Suche nach Wegen, um ihre MySQL Replikations-, Skalierungs- und Betriebs-Abläufe zu optimieren und um ihre 7x24 h Verfügbarkeit und ihr Geschäftswachstum sicherzustellen. Galera Cluster macht genau das. Wir schätzen uns glücklich, Galera Cluster zu unserem Beratungs- und Support-Angebot hinzufügen zu können, sagt Oli Sennhauser, Senior MySQL Berater und CEO von FromDual.

Galera Cluster wir von Anwendern genutzt, welche hoch verfügbare MySQL Datenbank-Backends mit sehr kurzen Failover-Zeiten für geschäftskritische Applikationen wie Telekom/VoIP-Lösungen, ERP-Systeme, Web-Shops, e-Commerce-Lösungen, Geschäftsanwendungen as a Service (SaaS), Platform as a Service (PaaS), Medien- und Unterhaltungs-Websites, Spieleplattformen, soziale Netzwerke oder ähnlich kritische Applikationen benötigen.

Über FromDual GmbH

FromDual ist eine global agierende, neutrale und Hersteller unabhängige Beratungs-, Support- und Schulungs-Firma für MySQL, Percona Server, MariaDB und Galera Cluster mit zahlreichen Kunden aus der ganzen Welt aus den Sektoren: Telekommunikation, Medien, Öffentlicher Dienst, Internet und Industrie. FromDual ist Oracle Silber Partner und Open Database Alliance (ODBA) Silber Partner. Zusätzlich zu seinen MySQL-Dienstleistungen vertreibt FromDual seinen Performance Monitor für MySQL als lokale Installation oder als Software as a Service-Lösung. Weitere Informationen über FromDual-Produkte, Beratungs- und Support-Dienstleistungen finden Sie unter www.fromdual.com.

Pressekontakt:

FromDual GmbH
Oli Sennhauser, CEO
E-Mail: oli.sennhauser@fromdual.com
Mobil: +41 79 830 09 33

Über Codership Oy

Codership entwickelt Replikations- und Cluster-Lösungen für Open Source Datenbanken unter Einbezug neuartiger Ideen modernster Datenbanksysteme und Forschungsresultate aus dem Bereich verteilter Rechner-Netze und setzt diese zu neuen Hochverfügbarkeits-Lösungen um. Die Gründer von Codership haben langjährige Erfahrung bei der Entwicklung mehrerer weit verbreiteter MySQL Cluster-Lösungen gesammelt, bevor sie die Entwicklung von Galera im Jahr 2007 begonnen haben. Tausende von Anwendern haben die Galera Cluster Lösungen – das Codership Open Source Flaggschiff – bereits für ihre geschäftskritischen Anwendungen gewählt. Codership arbeitet aktiv für diese wachsende Anwendergemeinschaft. Mehr Informationen über Codership-Produkte, Beratungs- und Support-Dienstleistungen finden Sie unter www.codership.com.

Pressekontakt:

Codership OY
Seppo Jaakola, CEO
E-Mail: seppo.jaakola@codership.com
Mobil: +358 405 105 938

Taxonomy upgrade extras: monitoringmonitornewsperformance monitornewslettermpmmaas

On January 9th FromDual launched its Monitoring as a Service (MaaS) solution for MySQL.
This service is based on the Performance Monitor for MySQL (mpm) v0.8 and Zabbix.

The installation on customer side of the so called monitoring agent takes about 5 minutes (for installation, configuration and scheduling).

The collected performance data are sent to our service where you can view them with your web browser. Some examples you can find here.

You can download the Performance Monitor for MySQL from our download page.

To use this service a key is needed which will be provided by FromDual. To request a key please use this form.

This service is free for FromDual support and consulting customers. For all others we offer a special enterprise customer monitoring subscription.

More information about MySQL Monitoring as a Service you can find here.

You can follow discussion about the MaaS on our forum.

InnoDB and NDB module are now under GPL!

Further we have the pleasure to announce that now all modules are available under GPL. Before the InnoDB and the NDB (MySQL Cluster) module were available for FromDual customers only.
For commercial use of the FromDual Performance Monitor an Enterprise subscription is required.

The changes in the new FromDual Performance Monitor release v0.8 are:

New functionality

• Monitoring as a Service (MaaS) functionality was added to the FromDual Performance Monitor for MySQL.

Changed functionality

• The InnoDB and NDB module are now available under GPL.
• Agent lock was implemented. Only one agent can run per server now at a time. This is to prevent a system overload because of some locks or timeouts etc.
• Agent log is now touched on every call. From the timestamp it is visible now when the agent was running last.
• Cache file is now per server/device.
• Data are mostly cached in the cache file first instead of calling zabbix_sender zillions of times.
• Zabbix server port is now configurable.
• Foreign Key Error detection for InnoDB was implemented.
• Deadlock detection for InnoDB was implemented.
• XtraDB and InnoDB agents/templates were merged. There is now no more difference between GPL and commercial builds.

Fixes

• ndb_cluster_connection_pool is now reported correctly and according trigger works correctly again.
• Some templates where improved.
• Missing item to MyISAM template added.
• Missing item to Process template added.
• Fix in the mysql module (sql_mode).
• Fix in the master template (adding 20 missing items for binary log events).

If you want to stay tuned to our information, follow our Tweets on Twitter. If you like this service please let us know.

We would love to hear about your feedback.

Best Regards,

Your FromDual Team

Taxonomy upgrade extras: monitoringmonitorperformance monitoringnewsnewslettermpmmaas

Am 9. Januar hat FromDual seinen neuen Dienst Monitoring as a Service (MaaS) für MySQL freigegeben.
Diese Dienstleistung basiert auf dem FromDual Performance Monitor für MySQL (mpm) v0.8 und Zabbix.

Die Installation des sogenannten Monitoring-Agents auf Kundenseite nimmt etwa 5 Minuten in Anspruch (für Installation, Konfiguration und Scheduling).

Die gesammelten Performance-Daten werden an unseren Dienst geschickt, auf welchem Sie diese anschliessend mit Ihrem Web-Browser einsehen können. Einige Beispiele finden Sie hier.

Sie können den FromDual Performance Monitor für MySQL von unserer Downloadseite herunterladen.

Um diese Dienstleistung nutzen zu können brauchen Sie einen Schlüssel von uns. Um einen Schlüssel anzufordern benutzen Sie bitte dieses Formular.

Diese Dienstleistung ist für FromDual Support- und Beratung-Kunden kostenlos. Für alle anderen bieten wir eine spezielle Enterprise-Kunden-Monitoring-Subskription an.

Weitere Informationen über MySQL Monitoring as a Service finden Sie hier.

Sie können sich auch an Diskussionen über MaaS in unserem Forum beteiligen.

InnoDB und NDB Module sind jetzt neu unter GPL erhältlich

Im Weiteren dürfen wir Ihnen ankündigen, dass jetzt alle Module unter der GPL verfügbar sind. Bis jetzt waren die Module für InnoDB und NDB (MySQL Cluster) ausschliesslich für FromDual Kunden zugänglich.
Für die kommerzielle Nutzung des FromDual Performance Monitors ist eine Enterprise-Subskription erforderlich.

Folgende Änderungen sind in den neuen FromDual Performance Monitor Release v0.8 eingeflossen:

Neue Funktionalität

• Monitoring as a Service (MaaS) Funktionalität wurde für den FromDual Performance Monitor für MySQL hinzugefügt.

Geänderte Funktionalität

• Das InnoDB und NDB Modul sind jetzt unter GPL verfügbar.
• Ein Lock für den Agenten wurde eingeführt. Jetzt kann nur noch ein Agent pro Server aufs Mal gestartet werden. Diese Funktionalität wurde eingeführt um Systemüberlast, verursacht durch Locks oder Timeouts, zu vermeiden.
• Das Agenten-Log wird jetzt bei jedem Aufruf angelangt. Jetzt ist anhand des Zeitstempels ersichtlich, wann der Agent das letze mal gelaufen ist.
• Das Cache File wird jetzt pro Server/Device angelegt.
• Die Daten werden jetzt hauptsächlich zuerst im Cache File gecached anstatt dass zabbix_sender oft aufgerufen wird.
• Der Zabbix-Server-Port ist jetzt konfigurierbar.
• InnoDB Foreign Key Fehler Detektierung wurde implementiert.
• InnoDB Deadlock Detektierung wurde implementiert.
• XtraDB und InnoDB Agenten und Templates wurde zusammengelegt. Es gibt jetzt keinen Unterschied mehr zwischen den GPL und den kommerziellen Builds.

Fehlerbehebungen

• ndb_cluster_connection_pool wird jetzt richtig gemeldet und der entsprechende Trigger arbeitet jetzt wieder richtig.
• Einige Templates wurden verbessert.
• Fehlende Items am MyISAM Template wurden hinzugefügt.
• Fehlende Items am Process Template wurden hinzugefügt.
• Fehlerbehebung im mysql Modul (sql_mode).
• Fehlerbehebung im master Template (20 fehlende Items für Binary-Log Events wurden hinzugefügt).

Wenn Sie über unsere Informationen immer auf dem Laufenden gehalten werden wollen, folgen Sie uns am besten auf Twitter. Wenn Sie diese Dienstleistung mögen lassen Sie es uns wissen

Gerne nehmen wir auch Ihre Rückmeldungen entgegen.

Mit freundlichen Grüssen,

Ihr FromDual Team

Taxonomy upgrade extras: performanceenterprise monitormonitoringmonitorperformance monitoringperformance monitorreleasegraphgalerampmmaas

On December 2nd 2011 FromDual released the new version v0.7.2 of its Performance Monitor for MySQL. The new version can be downloaded from here.

The Performance Monitor for MySQL is an agent which is hooked into the agent of the well known Monitoring solution called Zabbix. Zabbix is an integrated Enterprise Monitoring solution which can produce performance graphs and alerting.

The changes in the new release are:

New functionality

• A new module for Galera was added (mainly Galera 0.8).
• A new module for the MySQL Performance Monitor (mpm) was added.
• Information about InnoDB Row Locking was added (status and graph).
• Some MySQL variables were added for monitoring (customer request).
• Triggers for some of those MySQL variables are implemented (customer request).

Changed functionality

• MPM agent hook (FromDual.MySQL.check) was moved from the mysql module to the mpm module. To call the MPM agent you have to run the mpm module only once per monitored server (computer).
• Path to the MPM agent libraries is not hard coded anymore but follows $basedir/lib now. The MPM can now be located anywhere... (customer request)
• The MPM cache file is now configurable.
• The MPM agent is prepared for Deadlock and Foreign Key Error detection (customer request).
• Name collision in the server module fixed (customer bug report).
• Old style basename code replace by new Perl style.

Fixes

• Security fix in the MPM agent (password is no longer displayed in the log file).
• Some fixes in different XML templates.
• Some fixes in the ndb, memcached, aria, drbd and server module.
• Some fixes in the MPM agent.

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

Susanne hat dabei PostgreSQL, wir MySQL betreut...

Taxonomy upgrade extras: Performance Tuningmysqlbenchmarkpostgresqlgerman

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

Susanne hat dabei PostgreSQL, wir MySQL betreut...

Taxonomy upgrade extras: Performance Tuningmysqlbenchmarkpostgresqlgerman

Taxonomy upgrade extras: Performance Tuningmysqlbenchmarkpostgresqlgerman

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

Susanne hat dabei PostgreSQL, wir MySQL betreut...