You are here

News

MySQL Environment MyEnv 1.2.2 has been released

FromDual.en - Mon, 2015-10-12 17:48

FromDual has the pleasure to announce the release of the new version 1.2.2 of its popular MySQL, Galera Cluster, MariaDB and Percona Server multi-instance environment MyEnv.

The new MyEnv can be downloaded here.

In the inconceivable case that you find a bug in the MyEnv please report it to our bug tracker.

Any feedback, statements and testimonials are welcome as well! Please send them to feedback@fromdual.com.

Upgrade from 1.1.x to 1.2.2 # cd ${HOME}/product # tar xf /download/myenv-1.2.2.tar.gz # rm -f myenv # ln -s myenv-1.2.2 myenv

If you are using plug-ins for showMyEnvStatus create all the links in the new directory structure:

cd ${HOME}/product/myenv ln -s ../../utl/oem_agent.php plg/showMyEnvStatus/
Changes in MyEnv 1.2.2 MyEnv
  • IP addresses are shown in up.
  • All values from [default] section should be inherited to [dbname] section.
  • Configuration file parser made more robust.
  • Empty my.cnf is caught correctly now.
MyEnv Installer
  • Mac OSX findings fixed in installer.
  • Fixed suppressed mysql_install_db error output problem.
  • Missing libaio library is found in installer now.
  • Check for missing /var/run/mysqld directory added.
  • Installation script mysql_install_db is called with --no-defaults now to avoid interference with other configuration files.
MyEnv Utilities
  • Skript log_maintenance.php will not abort when having a problem with one log file but continue.
  • Help examples and template improved for log_maintenance.php.
  • Function check for mb_strlen added for log_maintenance.php.
  • Skript option --truncate with too many lines leads to out of memory and takes ages. Fixed this by limiting lines to 10000 in log_maintenance.php.
  • But in drop_partition.php was fixed.

For subscriptions of commercial use of MyEnv please get in contact with us.

Taxonomy upgrade extras: myenvoperationMySQL Operationsmulti instanceconsolidationtestingupgrade

FromDual Performance Monitor for MySQL and MariaDB 0.10.5 has been released

FromDual.en - Thu, 2015-08-06 18:29
Taxonomy upgrade extras: mysqlperformancemonitormonitoringfpmmmmaasperformance monitormpm

FromDual has the pleasure to announce the release of the new version 0.10.5 of its popular Database Performance Monitor for MySQL, MariaDB, Galera Cluster and Percona Server fpmmm.

You can download fpmmm from here.

In the inconceivable case that you find a bug in fpmmm please report it to our Bug-tracker.

Any feedback, statements and testimonials are welcome as well! Please send them to feedback@fromdual.com.

This release contains various bug fixes and improvements. The previous release had some major bugs so we recommend to upgrade...

New installation of fpmmm v0.10.5

Please follow our mpm installation guide. A specific fpmmm installation guide will follow with the next version.

Prerequisites CentOS 6
# yum install php-cli php-process php-mysqli # cat << _EOF >/etc/php.d/fpmmm.ini variables_order = "EGPCS" date.timezone = 'Europe/Zurich' _EOF rpm -Uvh http://repo.zabbix.com/zabbix/2.2/rhel/6/x86_64/zabbix-release-2.2-1.el6.noarch.rpm yum update yum install zabbix-sender
CentOS 7 # yum install php-cli php-process php-mysqli # cat << _EOF >/etc/php.d/fpmmm.ini variables_order = "EGPCS" date.timezone = 'Europe/Zurich' _EOF rpm -Uvh http://repo.zabbix.com/zabbix/2.2/rhel/7/x86_64/zabbix-release-2.2-1.el7.noarch.rpm yum update yum install zabbix-sender
Ubuntu 14.04
# apt-get install php5-cli php5-mysqlnd php5-curl # cat << _EOF >/etc/php5/cli/conf.d/fpmmm.ini variables_order = "EGPCS" date.timezone = 'Europe/Zurich' _EOF apt-get install zabbix-agent
OpenSuSE 13.1
# zypper install php5 php5-posix php5-mysql php5-pcntl php5-curl #cat << _EOF >/etc/php5/conf.d/fpmmm.ini variables_order = "EGPCS" date.timezone = 'Europe/Zurich' _EOF zypper addrepo http://download.opensuse.org/repositories/server:/monitoring/openSUSE_13.1 server_monitoring zypper update zypper install zabbix-agent
Upgrade from fpmmm 0.10.x to fpmmm 0.10.5 # cd /opt # tar xf /download/fpmmm-0.10.5.tar.gz # rm -f fpmmm # ln -s fpmmm-0.10.5 fpmmm

The following templates in your Zabbix monitor should be replaced. Before you replace the templates it is a good idea to first delete all triggers...

  • tpl/Template_FromDual.MySQL.fpmmm.xml
  • tpl/Template_FromDual.MySQL.innodb.xml
  • tpl/Template_FromDual.MySQL.master.xml
  • tpl/Template_FromDual.MySQL.myisam.xml
  • tpl/Template_FromDual.MySQL.mysql.xml
  • tpl/Template_FromDual.MySQL.server.xml
  • tpl/Template_FromDual.MySQL.slave.xml
Changes in fpmmm v0.10.5 fpmmm agent
  • Better and more verbose error handling in various modules.
  • Directory for log file is created automatically if it does not exist yet.
  • All broken SQL queries (from 0.10.4) fixed again.
  • Add delay for not so frequent changing data.
  • Several triggers which complained after restart are fixed now.
  • Connections to database were now reduced to the minimum.
  • Links for templates fixed.
  • Innodb_flush_log_at_trx_commit, log_queries_not_using_indexes and character_set_server triggers disabled by default.
  • Also sendCachedData is now checked for too big cache file. Bug from swd.
Slave module
  • Slave error messages are caught and sent to the monitor.
  • Warning is written to the log file if slave module is configured without being a slave.
  • New slave status is reported correctly now.
  • Seconds_behind_master is now only sent when running.
Master module
  • New trigger for binlog_format = MIXED and replication filtering added.
  • Severity increased on STATEMENT based filtering added.
  • Regexp bug fixed.
  • Master without binary log fixed.
MySQL module
  • Old broken triggers fixed.
Server module
  • IOPS graph added.
  • Device sda5 removed.
  • I/O statistics calculation improved.
  • I/O r/w wait experimental items implemented.
  • CPU count added.
  • NUMA and virtualization information added.
InnoDB module
  • innodb_flush_method item added.
  • Trigger for innodb_flush_method added.
  • innodb_force_recovery trigger severity increased.
  • innodb_log_files_in_group item added for log traffic threshold.
  • InnoDB transaction log traffic trigger and graph added.

For subscriptions of commercial use of fpmmm please get in contact with us.

Max_used_connections per user/account

Shinguz - Thu, 2015-07-30 23:34
Taxonomy upgrade extras: max_used_connectionsuseraccountconnectionconfiguration

How many connections can be opened concurrently against my MySQL or MariaDB database can be configured and checked with the following command:

SHOW GLOBAL VARIABLES LIKE 'max_connections'; +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | max_connections | 505 | +-----------------+-------+

If this limit was ever reached in the past can be checked with:

SHOW GLOBAL STATUS LIKE 'max_use%'; +----------------------+-------+ | Variable_name | Value | +----------------------+-------+ | Max_used_connections | 23 | +----------------------+-------+

But on MySQL instances with many different applications (= databases/schemas) and thus many different users it is a bit more complicated to find out which of these users have connected how many times concurrently. We can configure how many connections one specific user can have at maximum at the same time with:

SHOW GLOBAL VARIABLES LIKE 'max_user_connections'; +----------------------+-------+ | Variable_name | Value | +----------------------+-------+ | max_user_connections | 500 | +----------------------+-------+

Further we can limit one specific user with:

GRANT USAGE ON *.* TO 'repl'@'%' WITH MAX_CONNECTIONS_PER_HOUR 100 MAX_USER_CONNECTIONS 10;

and check with:

SELECT User, Host, max_connections, max_user_connections FROM mysql.user; +------+---------------+-----------------+----------------------+ | User | Host | max_connections | max_user_connections | +------+---------------+-----------------+----------------------+ | root | localhost | 0 | 0 | | repl | % | 100 | 10 | | repl | 192.168.1.139 | 0 | 0 | +------+---------------+-----------------+----------------------+

But we have currently no chance to check if this limit was reached or nearly reached in the past...

A feature request for this was opened at MySQL wit bug #77888

Solution

If you cannot wait for the implementation here we have a little workaround:

DROP TABLE IF EXISTS mysql.`max_used_connections`; CREATE TABLE mysql.`max_used_connections` ( `USER` char(16) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL, `HOST` char(60) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL, `MAX_USED_CONNECTIONS` bigint(20) NOT NULL, PRIMARY KEY (`USER`, `HOST`) USING HASH ) ENGINE=MEMORY DEFAULT CHARSET=utf8 ; DROP EVENT IF EXISTS mysql.gather_max_used_connections; -- event_scheduler = on CREATE DEFINER=root@localhost EVENT mysql.gather_max_used_connections ON SCHEDULE EVERY 10 SECOND DO INSERT INTO mysql.max_used_connections SELECT user, host, current_connections FROM performance_schema.accounts WHERE user IS NOT NULL AND host IS NOT NULL ON DUPLICATE KEY UPDATE max_used_connections = IF(current_connections > max_used_connections, current_connections, max_used_connections) ; SELECT * FROM mysql.max_used_connections; +--------+-----------+----------------------+ | USER | HOST | MAX_USED_CONNECTIONS | +--------+-----------+----------------------+ | root | localhost | 4 | | zabbix | localhost | 21 | +--------+-----------+----------------------+

Caution: Because we used a MEMORY table those values are reset at every MySQL restart (as it happens with the PERFORMANCE_SCHEMA or the INFORMATION_SCHEMA).

MySQL Environment MyEnv 1.2.1 has been released

FromDual.en - Mon, 2015-07-27 16:11
Taxonomy upgrade extras: myenvoperationMySQL Operationsmulti instanceconsolidationtestingupgrade

FromDual has the pleasure to announce the release of the new version 1.2.1 of its popular MySQL, Galera Cluster, MariaDB and Percona Server multi-instance environment MyEnv.

The new MyEnv can be downloaded here.

In the inconceivable case that you find a bug in the MyEnv please report it to our bug tracker.

Any feedback, statements and testimonials are welcome as well! Please send them to feedback@fromdual.com.

Upgrade from 1.1.x to 1.2.1 # cd ${HOME}/product # tar xf /download/myenv-1.2.1.tar.gz # rm -f myenv # ln -s myenv-1.2.1 myenv

If you are using plug-ins for showMyEnvStatus create all the links in the new directory structure:

cd ${HOME}/product/myenv ln -s ../../utl/oem_agent.php plg/showMyEnvStatus/
Changes in MyEnv 1.2.1 MyEnv
  • Bug in myenv.server fixed (chmod user:).
  • Distribution check for CentOS 7.1 fixed (bug report Jörg).
  • Directory /var/run/mysqld is created by myenv.server
  • Missing function output added.
  • Output changes unified, execute with LC_ALL=C made language independent.
MyEnv Installer
  • Template my.cnf extended by hostname and instance name.
  • Skip in init script implemented, (bug report Jörg).
  • MyEnv my.cnf.template merged with website.
  • Template AUTO_INCREMENT values fixed.
  • Galera Cluster variable causal read in my.cnf template updated.
  • Functions separated into own library.
  • All templates moved from etc to tpl.
  • my.cnf template provided with hostname tag.
MyEnv Utilities
  • Skript alter_engine.php now supports socket.
  • Check in alter_engine.php for Primary Key length of 767 bytes was removed because it was wrong.
  • Skript decrypt_mylogin_cnf.php added.
  • Script log_maintenance.php added.
  • Usage and --help added to block_galera_node.sh.

For subscriptions of commercial use of MyEnv please get in contact with us.

The Upcoming Leap Second

Jörg Brühe - Mon, 2015-06-29 17:56

The press, be it the general daily newspaper or the computer magazines, is currently informing the public about an upcoming leap second, which will be taken in the night from June 30 to July 1 at 00:00:00 UTC. While we Europeans will enjoy our well-deserved sleep then, this will be at 5 PM (17:00) local time on June 30 for Califormia people, and during the morning of July 1 for people in China, Japan, Korea, or Australia. (Other countries not mentioned for the sake of brevity.) This is different from last time, when the leap second was taken in the night from Saturday to Sunday (2012-July-1 00:00:00 UTC), so it was a weekend everywhere on the globe.

We have got several requests from our customers about this upcoming leap second, whether they need to take any special precautions or whether they "are safe". Well, obviously nobody is "safe" from the leap second in the sense that it would circumvent them, everybody will encounter it on their systems. The concern is whether they have to expect any trouble.

For the people operating MySQL (or any other DBMS), this issue is threefold:

  • How will the operating system behave?
  • How will the database system behave?
  • How will the applications behave?
  • Let us look at the operating system first, dealing with Linux only. (All other operating systems don't show up with significant numbers in our customer base.)
    Linux measures the time in seconds (since Jan 1, 1970, 00:00:00 UTC), and it does not include the leap seconds in this counting. When the leap second is taken, the timestamp value (those seconds) will simply not be advanced at the end of the regular second, but it will re-use its current value in the leap second. As a result, the conversion of timestamps into common time reckoning will still produce values from 0 to 59 for the minute as well as for the second, there will not be a 60. Another consequence is that there is no way to tell the leap second from the preceding regular one.

    MySQL always takes the time information from the Linux kernel, so it will also use the same timestamp value (or "now()" result) for both the regular and the leap second. The MySQL manual describes this on its own leap second page, which has become inaccurate by some recent code changes: We could not reproduce the results given there (and will probably file a documentation bug about this). However, that difference does not affect the principle of the page's first paragraph.

    About the application, it is hard to claim anything - there are too many of them. However, it is obvious that an application might run into trouble if it managed to store a new timestamp value every second and assumed they are distinct: they will not be (unless the application manages to skip the leap second). Let's hope any application programmer creating such a high-resolution application was aware of the problem.

    So does it all look fine? Not completely: Following the last leap second (just three years ago), several administrators noticed that their machines became extraordinarily busy, which even let the power consumption rise significantly. This was caused by a bug in the Linux kernel, it let user processes resume immediately if they were trying to wait on a high-resolution timer. The exact details are beyond the scope of this article, your favourite search engine will provide you with more than enough references if you ask it.
    For our purposes, the important fact is that this also happened to MySQL server processes ("mysqld") because InnoDB was doing such operations.

    Back then, Sheeri K. Cabral (well-known in the MySQL blogosphere) published a cure which her team had discovered:
    This loop can be broken by simply setting the Linux kernel's clock to the current time.
    date -s "`date`"
    While this looks like a no-op at first sight, I assume that it will reset the sub-second time information and so will have a small effect, which obviously is sufficient to terminate that loop. (In practice, you should stop your NTP daemon before changing the date, and restart it afterwards. The exact command will depend on your Linux distribution.)

    Well, this was three years ago. The issue was reported to kernel developers, a fix was developed (which gives credit to Sheeri's report) and applied to newer kernels, and it w as also backported to older kernels. From my search, it seems that all reasonably maintained installations should have received that fix. For example, I have seen notices that Ubuntu 12.04 (since kernel 3.2.0-29.46) and 14.04 do have it, as does RedHat 6.4 (since kernel 2.6.32-298); for other distributions, I did not search.

    In addition to a current kernel, you obviously need current packages including the leap second information. Typically, this would be "ntp", "ntpdate", "tzdata", and related ones. Don't forget to restart your NTP daemon after installing these updates!

    So I wish all our readers that the leap second may not get them into trouble, or that (if worst comes to worst) the cure published by Sheeri may get them out. However, I have to remind you of the old truth which is attributed to Mark Twain (sometimes also to Niels Bohr):
    "It is difficult to make predictions, especially about the future."

    FromDual Backup Manager for MySQL 1.2.2 has been released

    Shinguz - Tue, 2015-06-23 11:33

    FromDual has the pleasure to announce the release of the new version 1.2.2 of the popular Backup Manager for MySQL and MariaDB (fromdual_bman).

    You can download the FromDual Backup Manager from here.

    In the inconceivable case that you find a bug in the Backup Manager please report it to our Bugtracker.

    Any feedback, statements and testimonials are welcome as well! Please send them to feedback@fromdual.com.

    Upgrade from 1.2.x to 1.2.2 # cd ${HOME}/product # tar xf /download/fromdual_brman-1.2.2.tar.gz # rm -f fromdual_brman # ln -s fromdual_brman-1.2.2 fromdual_brman
    Changes in FromDual Backup Manager 1.2.2 FromDual Backup Manager

    It contains mainly fixes with brman catalog and physical backups.

    You can verify your current FromDual Backup Manager version with the following command:

    fromdual_bman --version
    • Archiving with physical backup bug fixed.
    • Connect replaced by OO style and error exit fixed.
    • Create catalog fixed.
    • Archivedir without archive option does not make sense.

    Wir suchen Dich: MySQL/MariaDB DBA für FromDual Support

    Shinguz - Mon, 2015-06-22 13:51
    Taxonomy upgrade extras: jobDBAsupportWer sind wir?

    FromDual ist das führende unabhängige Beratungs- und Dienstleistungsunternehmen für MySQL, Galera Cluster, MariaDB und Percona Server in Europa mit Hauptsitz in der Schweiz.

    Unsere Kunden stammen hauptsächlich aus Europa und reichen vom kleinen Start-Up bis zur europäischen Top-500 Firma. Sie erhalten von uns Support bei Datenbank-Problemen, direkte Eingriffe als remote-DBA, Schulung für ihre DBAs und Entwickler sowie Beratung bei Architektur- und Design-Entscheidungen. Ausserdem entwickeln wir Tools rund um MySQL, schreiben Blog-Artikel und halten Vorträge bei Konferenzen.

    Da unsere qualitativ guten Dienstleistungen immer mehr Kunden anziehen, brauchen wir Kollegen (m/w), welche selbst und mit uns wachsen wollen.

    Stellenbeschreibung

    Wir suchen deutschsprachige Mitarbeiter (Sie oder Ihn) auf Junior- oder Senior-Level für Dienstleistungen rund um MySQL (hauptsächlich Support und remote-DBA Arbeiten) in Vollzeit. Primär solltest Du sicherstellen, dass die geschäftskritischen MySQL-Datenbanken unserer Kunden wie am Schnürchen laufen - und falls nicht, diese schnell wieder ans Laufen kriegen...


    Unser/e "Wunschkandidat/in"

    • hat Erfahrung im Betrieb kritischer und hoch verfügbarer produktiver Datenbanken hauptsächlich auf Linux,
    • kennt Replikation in allen Variationen aus der täglichen Arbeit,
    • weiß, wie die meist verbreiteten MySQL-HA-Setups funktionieren und wie man sie wieder effizient repariert, wenn ein Problem auftritt,
    • ist sattelfest in SQL,
    • bringt Erfahrung mit Galera Cluster mit,
    • kann Bash skripten und einfache Programme in mindestens einer verbreiteten Programmier-/Skripting-Sprache (PHP, Bash, ...) erstellen.

    Wir suchen Verstärkung, die von soliden Grundlagen aus auf dem Weg zu diesem Ideal ist.


    Was wir von Dir erwarten:

    • Kenntnisse in MySQL, Percona Server oder MariaDB oder Bereitschaft, sich diese anzueignen
    • wissen, wie man kritische Datenbank-Systeme betreibt
    • Verständnis, was beim Betrieb von Datenbanken falsch laufen kann
    • selbständige Arbeitsweise (remote) mit Kommunikation über IRC, Skype, Mail und Telefon
    • Kenntnisse des Linux Systems

    DBA- oder DevOps-Erfahrungen wären z.B. eine gute fachliche Basis.


    Du schätzt den direkten Kontakt mit Kunden, hast ein gutes Gespür für deren Probleme, kannst zuhören und findest schnell die eigentlichen Probleme. Du bist gewohnt, proaktiv zu handeln bevor etwas passiert, und führst den Kunden wieder auf den richtigen Pfad zurück.


    Um Deine Arbeit erledigen zu können, arbeitest Du in einer europäischen Zeitzone. Deine Arbeitszeit kannst Du, der betrieblichen Situation entsprechend, flexibel gestalten. Wir erwarten, dass Du Deinen Beitrag zum Bereitschaftsdienst leistest. FromDual hat voraussichtlich keine Büroräumlichkeiten in Deinem Wohnort. Ein Umzug ist jedoch nicht notwendig: Wir ermöglichen Dir das Arbeiten von zu Hause aus oder unterstützen Dich bei der Suche einer geeigneten Arbeitsräumlichkeit in Deiner Nähe. Gute schriftliche und mündliche Englischkenntnisse sind erforderlich.

    Was wir Dir bieten:
    • Deinen Leistungen angemessenes Gehalt.
    • Möglichkeit Dich zum Top MySQL-Datenbankspezialisten zu entwickeln.
    • Selbständiges Arbeiten.
    • Verantwortung für Deine Projekte und Kunden zu übernehmen.
    • Gute Kameradschaft im Team, sowie lockerer und angenehmer Umgang.
    • Stellenbezogene Weiterbildungsmöglichkeiten.
    • Teilnahme an Open Source Anlässen.
    • Arbeit von Deinem bevorzugten Wohnort aus.

    Du solltest in der Lage sein, die meiste Zeit selbständig zu arbeiten, zu denken und zu handeln und Dir neues Wissen selbständig anzueignen (durch Web-Suche, die MySQL-Dokumentation, Ausprobieren, etc.). Solltest Du dennoch einmal nicht weiterkommen, 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.


    Wie geht es weiter

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


    Bitte schicke Deinen ungeschönten Lebenslauf mit Deinen Gehaltsvorstellungen 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 Du uns Deinen Lebenslauf zugeschickt hast, darfst Du Deine Fähigkeiten in einem kleinen MySQL-Test unter Beweis zu stellen. Nach bestandenem Test laden wir Dich für die finalen Interviews ein.

    FromDual Performance Monitor for MySQL and MariaDB 0.10.4 has been released

    FromDual.en - Sat, 2015-05-16 14:29
    Taxonomy upgrade extras: mysqlperformancemonitormonitoringfpmmmmaasperformance monitormpm

    FromDual has the pleasure to announce the release of the new version 0.10.4 of its popular Database Performance Monitor for MySQL, MariaDB, Galera Cluster and Percona Server fpmmm.

    You can download fpmmm from here.

    In the inconceivable case that you find a bug in fpmmm please report it to our Bug-tracker.

    Any feedback, statements and testimonials are welcome as well! Please send them to feedback@fromdual.com.

    This release contains various minor bug fixes and improvements.

    New installation of fpmmm v0.10.4

    Please follow our mpm installation guide. A specific fpmmm installation guide will follow with the next version.

    Prerequisites CentOS 6 # yum install php-cli php-process php-mysqli # cat << _EOF >/etc/php.d/fpmmm.ini variables_order = "EGPCS" date.timezone = 'Europe/Zurich' _EOF rpm -Uvh http://repo.zabbix.com/zabbix/2.2/rhel/6/x86_64/zabbix-release-2.2-1.el6.noarch.rpm yum update yum install zabbix-sender
    CentOS 7 # yum install php-cli php-process php-mysqli # cat << _EOF >/etc/php.d/fpmmm.ini variables_order = "EGPCS" date.timezone = 'Europe/Zurich' _EOF rpm -Uvh http://repo.zabbix.com/zabbix/2.2/rhel/7/x86_64/zabbix-release-2.2-1.el7.noarch.rpm yum update yum install zabbix-sender
    Ubuntu 14.04 # apt-get install php5-cli php5-mysqlnd # cat << _EOF >/etc/php5/cli/conf.d/fpmmm.ini variables_order = "EGPCS" date.timezone = 'Europe/Zurich' _EOF apt-get install zabbix-agent
    OpenSuSE 13.1 # zypper install php5 php5-posix php5-mysql php5-pcntl php5-curl #cat << _EOF >/etc/php5/conf.d/fpmmm.ini variables_order = "EGPCS" date.timezone = 'Europe/Zurich' _EOF zypper addrepo http://download.opensuse.org/repositories/server:/monitoring/openSUSE_13.1 server_monitoring zypper update zypper install zabbix-agent
    Upgrade from fpmmm 0.10.x to fpmmm 0.10.4 # cd /opt # tar xf /download/fpmmm-0.10.4.tar.gz # rm -f fpmmm # ln -s fpmmm-0.10.4 fpmmm
    Changes in fpmmm v0.10.4 Security module
    • Privilege problem in security module caught and error message written.
    Changes in fpmmm v0.10.3 fpmmm agent
    • preg_replace error fixed (FromDualMySQLagent.inc).
    Master module
    • Bug in master module fixed.
    InnoDB module
    • Deadlock and foreign key error files move from /tmp to cacheBase.
    • Deadlock and foreign key error catching fixed (bug #162).
    Changes in fpmmm v0.10.2 fpmmm agent
    • fpmmm version check added in template.
    • fpmmm templates upgrade to Zabbix version 2.0.9. This means, they do not work with Zabix 1.8 any more!
    • zabbix_sender return code 0 caught correctly now.
    • Minor bug fixes and typos fixed.
    • Bug in caching data fixed.

    For subscriptions of commercial use of fpmmm please get in contact with us.

    Controlling worldwide manufacturing plants with MySQL

    Shinguz - Thu, 2015-05-14 21:43
    Taxonomy upgrade extras: multi-source replicationmysql-replicationreplicationMulti-Master Replicationfan-in replicationrow filteringGTID

    A MySQL customer of FromDual has different manufacturing plants spread across the globe. They are operated by local companies. FromDuals customer wants to maintain the manufacturing receipts centralized in a MySQL database in the Head Quarter in Europe. Each manufacturing plant should only see their specific data.

    Manufacturing log information should be reported backup to European Head Quarter MySQL database.

    The process was designed as follows:

    Preparation of Proof of Concept (PoC)

    To simulate all cases we need different schemas. Some which should be replicated, some which should NOT be replicated:

    CREATE DATABASE finance; CREATE TABLE finance.accounting ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `data` varchar(255) DEFAULT NULL, `ts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `data_rename` (`data`) ); CREATE DATABASE crm; CREATE TABLE crm.customer ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `data` varchar(255) DEFAULT NULL, `ts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `data_rename` (`data`) ); CREATE DATABASE erp; -- Avoid specifying Storage Engine here!!! CREATE TABLE erp.manufacturing_data ( id INT UNSIGNED NOT NULL AUTO_INCREMENT , manufacture_plant VARCHAR(32) , manufacture_info VARCHAR(255) , PRIMARY KEY (id) , KEY (manufacture_plant) ); CREATE TABLE erp.manufacturing_log ( id INT UNSIGNED NOT NULL AUTO_INCREMENT , manufacture_plant VARCHAR(32) , log_data VARCHAR(255) , PRIMARY KEY (id) , KEY (manufacture_plant) );
    MySQL replication architecture

    Before you start with such complicated MySQL set-ups it is recommended to make a little sketch of what you want to build:

    Preparing the Production Master database (Prod M1)

    To make use of all the new and cool features of MySQL we used the new GTID replication. First we set up a Master (Prod M1) and its fail-over System (Prod M2) in the customers Head Quarter:

    # /etc/my.cnf [mysqld] binlog_format = row # optional log_bin = binary-log # mandatory, also on Slave! log_slave_updates = on # mandatory gtid_mode = on # mandatory enforce_gtid_consistency = on # mandatory server-id = 39 # mandatory

    This step requires a system restart (one minute downtime).

    Preparing the Production Master standby database (Prod M2)

    On Master (Prod M1):

    GRANT REPLICATION SLAVE ON *.* TO 'replication'@'192.168.1.%' IDENTIFIED BY 'secret'; mysqldump -u root --set-gtid-purged=on --master-data=2 --all-databases --triggers --routines --events > /tmp/full_dump.sql

    On Slave (Prod M2):

    CHANGE MASTER TO MASTER_HOST='192.168.1.39', MASTER_PORT=3306 , MASTER_USER='replication', MASTER_PASSWORD='secret' , MASTER_AUTO_POSITION=1; RESET MASTER; -- On SLAVE! system mysql -u root < /tmp/full_dump.sql START SLAVE;

    To make it easier for a Slave to connect to its master we set a VIP in front of those 2 database servers (VIP Prod). This VIP should be used by all applications in the head quarter and also the filter engines.

    Set-up filter engines (Filter BR and Filter CN)

    To make sure every manufacturing plant sees only the data it is allowed to see we need a filtering engine between the production site and the manufacturing plant (Filter BR and Filter CN).

    To keep this filter engine lean we use a MySQL instance with all tables converted to the Blackhole Storage Engine:

    # /etc/my.cnf [mysqld] binlog_format = row # optional log_bin = binary-log # mandatory, also on Slave! log_slave_updates = on # mandatory gtid_mode = on # mandatory enforce_gtid_consistency = on # mandatory server-id = 36 # mandatory default_storage_engine = blackhole

    On the production master (Prod M1) we get the data as follows:

    mysqldump -u root --set-gtid-purged=on --master-data=2 --triggers --routines --events --no-data --databases erp > /tmp/erp_dump_nd.sql

    The Filter Engines (Filter BR and CN) are set-up as follows::

    -- Here we can use the VIP! CHANGE MASTER TO master_host='192.168.1.33', master_port=3306 , master_user='replication', master_password='secret' , master_auto_position=1; RESET MASTER; -- On SLAVE! system cat /tmp/erp_dump_nd.sql | sed 's/ ENGINE=[a-zA-Z]*/ ENGINE=blackhole/' | mysql -u root START SLAVE;

    Do not forget to also create the replication user on the filter engines.

    GRANT REPLICATION SLAVE ON *.* TO 'replication'@'192.168.1.%' IDENTIFIED BY 'secret';
    Filtering out all non ERP schemata

    We only want the erp schema to be replicated to the manufacturing plants, not the crm or the finance application. This we achieve with the following option on the filter engines:

    # /etc/my.cnf [mysqld] replicate_do_db = erp replicate_ignore_table = erp.manufacturing_log
    MySQL row filtering

    To achieve row filtering we use TRIGGERS. Make sure they are not replicated further down the hierarchy:

    SET SESSION SQL_LOG_BIN = 0; use erp DROP TRIGGER IF EXISTS filter_row; delimiter // CREATE TRIGGER filter_row BEFORE INSERT ON manufacturing_data FOR EACH ROW BEGIN IF ( NEW.manufacture_plant != 'China' ) THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Row was filtered out.' , CLASS_ORIGIN = 'FromDual filter trigger' , SUBCLASS_ORIGIN = 'filter_row' , CONSTRAINT_SCHEMA = 'erp' , CONSTRAINT_NAME = 'filer_row' , SCHEMA_NAME = 'erp' , TABLE_NAME = 'manufacturing_data' , COLUMN_NAME = '' , MYSQL_ERRNO = 1644 ; END IF; END; // delimiter ; SET SESSION SQL_LOG_BIN = 0;

    Up to now this would cause to stop replication for every filtered row. To avoid this we tell the Filtering Slaves to skip this error number:

    # /etc/my.cnf [mysqld] slave_skip_errors = 1644
    Attaching production manufacturing Slaves (Man BR M1 and Man CN M1)

    When we have finished everything on our head quarter site. We can start with the manufacturing sites (BR and CN):

    On Master (Prod M1):

    mysqldump -u root --set-gtid-purged=on --master-data=2 --triggers --routines --events --where='manufacture_plant="Brazil"' --databases erp > /tmp/erp_dump_br.sql mysqldump -u root --set-gtid-purged=on --master-data=2 --triggers --routines --events --where='manufacture_plant="China"' --databases erp > /tmp/erp_dump_cn.sql

    On the Manufacturing Masters (Man BR M1 and Man BR M2). Here we do NOT use a VIP because we think a blackhole storage engine is robust enough as master:

    CHANGE MASTER TO master_host='192.168.1.43', master_port=3306 , master_user='replication', master_password='secret' , master_auto_position=1; RESET MASTER; -- On SLAVE! system cat /tmp/erp_dump_br.sql | mysql -u root START SLAVE;

    The standby manufacturing (Man BR M2 and Man CN M2) database is created in the same way as the production manufacturing database on the master.

    Testing replication from HQ to manufacturing plants

    First we make sure, crm and finance is not replicated out and replication also does not stop (on Prod M1):

    INSERT INTO finance.accounting VALUES (NULL, 'test data over VIP', NULL); INSERT INTO finance.accounting VALUES (NULL, 'test data over VIP', NULL); INSERT INTO crm.customer VALUES (NULL, 'test data over VIP', NULL); INSERT INTO crm.customer VALUES (NULL, 'test data over VIP', NULL); UPDATE finance.accounting SET data = 'Changed data'; UPDATE crm.customer SET data = 'Changed data'; DELETE FROM finance.accounting WHERE id = 1; DELETE FROM crm.customer WHERE id = 1; SELECT * FROM finance.accounting; SELECT * FROM crm.customer; SHOW SLAVE STATUS\G

    The schema filter seems to work correctly. Then we check if also the row filter works correctly. For this we have to run the queries in statement based replication (SBR)! Otherwise the trigger would not fire:

    use mysql INSERT INTO erp.manufacturing_data VALUES (NULL, 'China', 'Highly secret manufacturing info as RBR.'); INSERT INTO erp.manufacturing_data VALUES (NULL, 'Brazil', 'Highly secret manufacturing info as RBR.'); -- This needs SUPER privilege... :-( SET SESSION binlog_format = STATEMENT; -- Caution those rows will NOT be replicated!!! -- See filter rules for SBR INSERT INTO erp.manufacturing_data VALUES (NULL, 'China', 'Highly secret manufacturing info as SBR lost.'); INSERT INTO erp.manufacturing_data VALUES (NULL, 'Brazil', 'Highly secret manufacturing info as SBR lost.'); use erp INSERT INTO manufacturing_data VALUES (NULL, 'China', 'Highly secret manufacturing info as SBR.'); INSERT INTO manufacturing_data VALUES (NULL, 'Brazil', 'Highly secret manufacturing info as SBR.'); INSERT INTO manufacturing_data VALUES (NULL, 'Germany', 'Highly secret manufacturing info as SBR.'); INSERT INTO manufacturing_data VALUES (NULL, 'Switzerland', 'Highly secret manufacturing info as SBR.'); SET SESSION binlog_format = ROW; SELECT * FROM erp.manufacturing_data;
    Production data back to head quarter

    Now we have to take care about the production data on their way back to the HQ. To achieve this we use the new MySQL 5.7 feature called multi source replication. For multi source replication the replication repositories must be kept in tables instead of files:

    # /etc/my.cnf [mysqld] master_info_repository = TABLE # mandatory relay_log_info_repository = TABLE # mandatory

    Then we have to configure 2 replication channels from Prod M1 to their specific manufacturing masters over the VIP (VIP BR and VIP CN):

    CHANGE MASTER TO MASTER_HOST='192.168.1.98', MASTER_PORT=3306 , MASTER_USER='replication', MASTER_PASSWORD='secret' , MASTER_AUTO_POSITION=1 FOR CHANNEL "manu_br"; CHANGE MASTER TO MASTER_HOST='192.168.1.99', MASTER_PORT=3306 , MASTER_USER='replication', MASTER_PASSWORD='secret' , MASTER_AUTO_POSITION=1 FOR CHANNEL "manu_cn"; START SLAVE FOR CHANNEL 'manu_br'; START SLAVE FOR CHANNEL 'manu_cn'; SHOW SLAVE STATUS FOR CHANNEL 'manu_br'\G SHOW SLAVE STATUS FOR CHANNEL 'manu_cn'\G

    Avoid to configure and activate the channels on Prod M2 as well.

    Testing back replication from manufacturing plants

    Brazil on Man BR M1:

    INSERT INTO manufacturing_log VALUES (1, 'Production data from Brazil', 'data');

    China on Man CN M1:

    INSERT INTO manufacturing_log VALUES (2, 'Production data from China', 'data');

    For testing:

    SELECT * FROM manufacturing_log;

    Make sure you do not run into conflicts (Primary Key, AUTO_INCREMENTS). Make sure filtering is defined correctly!

    To check the different channel states you can use the following command:

    SHOW SLAVE STATUS\G or SELECT ras.channel_name, ras.service_state AS 'SQL_thread', ras.remaining_delay , CONCAT(user, '@', host, ':', port) AS user , rcs.service_state AS IO_thread, REPLACE(received_transaction_set, '\n', '') AS received_transaction_set FROM performance_schema.replication_applier_status AS ras JOIN performance_schema.replication_connection_configuration AS rcc ON rcc.channel_name = ras.channel_name JOIN performance_schema.replication_connection_status AS rcs ON ras.channel_name = rcs.channel_name ;
    Troubleshooting Inject empty transaction

    If you try to skip a transaction as you did earlier (SQL_SLAVE_SKIP_COUNTER) you will face some problems:

    STOP SLAVE; ERROR 1858 (HY000): sql_slave_skip_counter can not be set when the server is running with @@GLOBAL.GTID_MODE = ON. Instead, for each transaction that you want to skip, generate an empty transaction with the same GTID as the transaction

    To skip the next transaction you have find the ones applied so far:

    SHOW SLAVE STATUS\G ... Executed_Gtid_Set: c3611091-f80e-11e4-99bc-28d2445cb2e9:1-20

    then tell MySQL to skip this by injecting a new empty transaction:

    SET SESSION GTID_NEXT='c3611091-f80e-11e4-99bc-28d2445cb2e9:21'; BEGIN; COMMIT; SET SESSION GTID_NEXT='AUTOMATIC'; SHOW SLAVE STATUS\G ... Executed_Gtid_Set: c3611091-f80e-11e4-99bc-28d2445cb2e9:1-21 START SLAVE;
    Revert from GTID-based replication to file/position-based replication

    If you want to fall-back from MySQL GTID-based replication to file/position-based replication this is quite simple:

    CHANGE MASTER TO MASTER_AUTO_POSITION = 0;
    MySQL Support and Engineering

    If you need some help or support our MySQL support and engineering team is happy to help you.

    FromDual Performance Monitor for MySQL and MariaDB 0.10.1 has been released

    FromDual.en - Sun, 2015-04-19 16:11
    Taxonomy upgrade extras: mysqlperformancemonitormonitoringfpmmmmaasperformance monitormpm

    FromDual has the pleasure to announce the release of the new version 0.10.1 of its popular Database Performance Monitor for MySQL, MariaDB, Galera Cluster and Percona Server fpmmm.

    You can download fpmmm from here.

    In the inconceivable case that you find a bug in fpmmm please report it to our Bug-tracker.

    Any feedback, statements and testimonials are welcome as well! Please send them to feedback@fromdual.com.

    This release contains various minor bug fixes and improvements. Mainly it was a rewrite from Perl into PHP.

    New installation of fpmmm v0.10.1

    Please follow our mpm installation guide. A specific fpmmm installation guide will follow with the next version.

    Prerequisites CentOS 6 # yum install php-cli php-process php-mysqli # cat << _EOF >/etc/php.d/fpmmm.ini variables_order = "EGPCS" date.timezone = 'Europe/Zurich' _EOF rpm -Uvh http://repo.zabbix.com/zabbix/2.2/rhel/6/x86_64/zabbix-release-2.2-1.el6.noarch.rpm yum update yum install zabbix-sender
    CentOS 7 # yum install php-cli php-process php-mysqli # cat << _EOF >/etc/php.d/fpmmm.ini variables_order = "EGPCS" date.timezone = 'Europe/Zurich' _EOF rpm -Uvh http://repo.zabbix.com/zabbix/2.2/rhel/7/x86_64/zabbix-release-2.2-1.el7.noarch.rpm yum update yum install zabbix-sender
    Ubuntu 14.04 # apt-get install php5-cli php5-mysqlnd # cat << _EOF >/etc/php5/cli/conf.d/fpmmm.ini variables_order = "EGPCS" date.timezone = 'Europe/Zurich' _EOF apt-get install zabbix-agent
    OpenSuSE 13.1 # zypper install php5 php5-posix php5-mysql php5-pcntl php5-curl #cat << _EOF >/etc/php5/conf.d/fpmmm.ini variables_order = "EGPCS" date.timezone = 'Europe/Zurich' _EOF zypper addrepo http://download.opensuse.org/repositories/server:/monitoring/openSUSE_13.1 server_monitoring zypper update zypper install zabbix-agent
    Upgrade from mpm 0.x to fpmmm 0.10.1 # cd /opt # tar xf /download/fpmmm-0.10.1.tar.gz # rm -f fpmmm # ln -s fpmmm-0.10.1 fpmmm

    You further have to replace all mysql_performance_monitor_agent.pl hooks (in Zabbix agent) by bin/fpmmm.

    Changes in fpmmm v0.10.1 fpmmm agent
    • Defaults in fpmmm.conf.template adapted.
    • Item sending prepared for empty strings.
    • Log of cachedData more verbose.
    • zabbix_sender stuff fixed and made more robust.
    • New naming convention fpmmm implemented.
    • Connection problems and error catching fixed.
    • NDB cluster and PBXT stuff removed and locking made more robust.
    • zabbix-sender on SuSE should work now as well. Bug #149.
    • exec/system replaced by my_exec.
    • Debug parameter replaced by LogLevel parameter, including all templates and warning for deprecation.
    • export LC_ALL=C added to all O/S calls to make it language independent.
    • Usage added (--help).
    • All Perl code replaced by PHP code.
    • Bug fix on cache clean-up on corruption.
    • Mac OSX (darwin) support added, partially.
    • Changed defaults away from /tmp This is no good location for persistent things because of RedHat tmpcleaner job.
    • Debugging info added for missing lock file.
    fpmmm agent and MaaS
    • none.
    Various modules
    • Regexp pattern fixed for mr_versions.
    MySQL module
    • Trailing / from datadir is removed.
    InnoDB module
    • Innodb buffer pool hit ratio rounded to 2 digits.
    • Innodb_os_log_written item added.
    • InnoDB hash searches item fixed.
    Galera module
    • Galera status now gathered with causal reads off.
    Memcached module
    • Memcached stuff activated.
    DRBD module
    • Bug report on new DRBD fixed.
    fpmmm templates for Zabbix
    • Security template data typo fixed.
    • Templates moved from xml folder to tpl folder and other file structure and renaming.
    • InnoDB Flush Log at Transaction Commit Serverity lowered from Warning to Information.

    For subscriptions of commercial use of fpmmm please get in contact with us.

    MySQL Environment MyEnv 1.2.0 has been released

    FromDual.en - Sat, 2015-04-18 15:30
    Taxonomy upgrade extras: myenvoperationMySQL Operationsmulti instanceconsolidationtestingupgrade

    FromDual has the pleasure to announce the release of the new version 1.2.0 of its popular MySQL, Galera Cluster, MariaDB and Percona Server multi-instance environment MyEnv.

    The new MyEnv can be downloaded here.

    In the inconceivable case that you find a bug in the MyEnv please report it to our bug tracker.

    Any feedback, statements and testimonials are welcome as well! Please send them to feedback@fromdual.com.

    Upgrade from 1.1.x to 1.2.0 # cd ${HOME}/product # tar xf /download/myenv-1.2.0.tar.gz # rm -f myenv # ln -s myenv-1.2.0 myenv

    If you are using plug-ins for showMyEnvStatus create all the links in the new directory structure:

    cd ${HOME}/product/myenv ln -s ../../utl/oem_agent.php plg/showMyEnvStatus/
    Changes in MyEnv 1.2.0 MyEnv
    • Some minor fixes on init script.
    • Introduction of states production, quality, testing and development.
    • Colored prompt added for stage production databases.
    • All /tmp/*sock moved to /var/run/mysqld.
    • up output prepared for bind-address awareness.
    • lsb_release dummy implemented.
    MyEnv Installer
    • Advice for 2 sudo commands in row was wrong.
    • Port conflict resolution more verbose.
    • Init script replacement check added. Replace init script is distribution aware and auto executable.
    • Installer made mode modular and prepared for automatization.
    • Installer allows now to run as other user than mysql.
    • Bugs in preparing myenv.conf fixed and instance name removed.
    • Install routine made more distribution aware.
    MyEnv Utilities
    • Split partition (split_partition.php) improved.
    • Fix of DROP PARTITION (drop_partition.php) was executed in wrong order (new before old).
    • Alter Engine script rewritten into PHP (alter_engine.php).
    • Alter Engine script handles ROW_FORMAT=FIXED problem correctly now.
    • Alter Engine script handles too large Primary Key better.
    • Alter Engine script recognizes tables with AUTO_INCREMENT column not at 1st position.
    • Purge Binary Log rewritten into PHP (purge_binary_log.php).
    • compare_status_files.pl added to compare output of 2 SHOW GLOBAL STATUS.

    For subscriptions of commercial use of MyEnv please get in contact with us.

    Logging Galera Cluster conflicts

    Shinguz - Sat, 2015-04-11 12:30
    Taxonomy upgrade extras: logginggaleraclusterconflictdeadlockerror logerror

    We typically suggest our customers to use our MySQL/Galera Cluster my.cnf configuration template to avoid MySQL configuration and performance problems.

    And we are paranoid as well. Thus we enable all useful logging:

    wsrep_log_conflicts = 1

    But this has also some consequences of more visibility...

    If you monitor carefully your Galera Cluster for example with the FromDual Performance Monitor for MySQL and MariaDB, you might probably see some strange values increasing from time to time:

    mysql< SHOW GLOBAL STATUS LIKE 'wsrep_local_%r_s'; +---------------------------+-------+ | Variable_name | Value | +---------------------------+-------+ | wsrep_local_cert_failures | 42 | | wsrep_local_bf_aborts | 13 | +---------------------------+-------+

    Those values are indicators that some transactions (Galera write sets) did to not succeed and were aborted by Galera. In this case the paranoid logging helps to find, what exactly was aborted and possibly helps to find out, if this can or should be fixed:

    150410 1:44:18 [Note] WSREP: cluster conflict due to certification failure for threads: 150410 1:44:18 [Note] WSREP: Victim thread: THD: 151856, mode: local, state: executing, conflict: cert failure, seqno: 30399304 SQL: UPDATE login SET lTsexpire = UNIX_TIMESTAMP(NOW()) + lTimeout WHERE lSessionId = 'va3ta7besku82k56ncv3bnhlj5' *** Priority TRANSACTION: TRANSACTION 464359568, ACTIVE 0 sec starting index read mysql tables in use 1, locked 1 1 lock struct(s), heap size 360, 0 row lock(s) MySQL thread id 4, OS thread handle 0x7f1c0916c700, query id 8190690 Update_rows_log_event::find_row(30399302) *** Victim TRANSACTION: TRANSACTION 464359562, ACTIVE 0 sec mysql tables in use 1, locked 1 2 lock struct(s), heap size 360, 1 row lock(s), undo log entries 1 MySQL thread id 151856, OS thread handle 0x7f1c09091700, query id 8190614 172.20.100.11 sam_angiz query end UPDATE login SET lTsexpire = UNIX_TIMESTAMP(now()) + lTimeout WHERE lSessionId = 'va3ta7besku82k56ncv3bnhlj5' *** WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 835205 page no 3 n bits 72 index `PRIMARY` of table `fromdual`.`login` trx table locks 1 total table locks 2 trx id 464359562 lock_mode X locks rec but not gap lock hold time 0 wait time before grant 0 150410 1:44:18 [Note] WSREP: cluster conflict due to high priority abort for threads: 150410 1:44:18 [Note] WSREP: Winning thread: THD: 4, mode: applier, state: executing, conflict: no conflict, seqno: 30399302 SQL: (null) 150410 1:44:18 [Note] WSREP: Victim thread: THD: 151856, mode: local, state: committing, conflict: no conflict, seqno: -1 SQL: UPDATE login SET lTsexpire = UNIX_TIMESTAMP(now()) + lTimeout WHERE lSessionId = 'va3ta7besku82k56ncv3bnhlj5'

    In the above Galera conflict 2 login transactions where running at the same time. They both come with the same Session ID and want to update the expiry timestamp. Now how to solve or fix this:

    • First check, if this table has a Primary Key (tables without a PK causes full table scans which can last for long time, increasing the chance for conflicts).
    • Second check, if there is a (UNIQUE?) index on lSessionId. A missing index leads to full table scans which increases the chance for conflicts.
    • Third check WHY 2 logins from the same Session ID can arrive at the same time (within 1 second) on 2 different Galera nodes (Ajax requests, etc...). Try to avoid such situations.

    Galera Cluster last inactive check and VMware snapshots

    Shinguz - Sat, 2015-04-11 11:46
    Taxonomy upgrade extras: galeravmwaresnapshot

    From time to time we see at Galera Cluster customer engagements the following, for me scary, warning in the MySQL error log:

    [Warning] WSREP: last inactive check more than PT1.5S ago (PT7.06159S), skipping check

    We mostly see this in VMware set-ups. Some further enquiry with the Galera developers did not give a satisfying answer:

    This can be seen on bare metal as well - with poorly configured mysqld, O/S, or simply being overloaded. All it means is that this thread could not get CPU time for 7.1 seconds. You can imagine that access to resources in virtual machines is even harder (especially I/O) than on bare metal, so you will see this in virtual machines more often.

    This is not a Galera specific issue (it just reports being stuck, other mysqld threads are equally stuck) so there is no configuration options for that. You simply must make sure that your system and mysqld are properly configured, that there is enough RAM (buffer pool not over provisioned), that there is swap, that there are proper I/O drivers installed on guest and so on.

    Basically, Galera runs in virtual machines as well as well virtual machines approximates bare metal.

    We were still suspecting that this is somehow VMware related. This week we had the chance to investigate... At 01:36 am node Galera2 lost connection to the Cluster and became NON-PRIMARY. This is basically a bad sign:

    150401 1:36:15 [Warning] WSREP: last inactive check more than PT1.5S ago (PT5.08325S), skipping check 150401 1:36:15 [Note] WSREP: (09c6b2f2, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://192.168.42.2:4567 150401 1:36:16 [Note] WSREP: view(view_id(NON_PRIM,09c6b2f2,30) memb { 09c6b2f2,0 } joined { } left { } partitioned { ce6bf2e1,0 d1f9bee0,0 }) 150401 1:36:16 [Note] WSREP: view(view_id(NON_PRIM,09c6b2f2,31) memb { 09c6b2f2,0 } joined { } left { } partitioned { ce6bf2e1,0 d1f9bee0,0 }) 150401 1:36:16 [Note] WSREP: New COMPONENT: primary = no, bootstrap = no, my_idx = 0, memb_num = 1 150401 1:36:16 [Note] WSREP: Flow-control interval: [16, 16] 150401 1:36:16 [Note] WSREP: Received NON-PRIMARY. 150401 1:36:16 [Note] WSREP: Shifting SYNCED -> OPEN (TO: 26304132) 150401 1:36:16 [Note] WSREP: New COMPONENT: primary = no, bootstrap = no, my_idx = 0, memb_num = 1 150401 1:36:16 [Note] WSREP: Flow-control interval: [16, 16] 150401 1:36:16 [Note] WSREP: Received NON-PRIMARY. 150401 1:36:16 [Warning] WSREP: Send action {(nil), 328, TORDERED} returned -107 (Transport endpoint is not connected) 150401 1:36:16 [Note] WSREP: New cluster view: global state: dcca768c-b5ad-11e3-bbc0-fb576fb3c451:26304132, view# -1: non-Primary, number of nodes: 1, my index: 0, protocol version 3 150401 1:36:17 [Note] WSREP: (09c6b2f2, 'tcp://0.0.0.0:4567') reconnecting to d1f9bee0 (tcp://192.168.42.1:4567), attempt 0

    I suspected, after some investigation with the FromDual Performance Monitor for MySQL and MariaDB, that the database backup (mysqldump) could be the reason. It was not. But the customer explained, that after the database backup they do a VMware snapshot.

    And when we compared our problem with the backup log file:

    2015/04/01 01:35:08 [3] backup.fromdual.com: Creating a snapshot of galera3 2015/04/01 01:35:16 [3] backup.fromdual.com: Created a snapshot of galera3 2015/04/01 01:35:23 [3] backup.fromdual.com: galera3: backup the changed blocks of disk 'Festplatte 1' using NBD transport 2015/04/01 01:36:10 [3] backup.fromdual.com: galera3: saving the Change Block Tracking's reference for disk 'Festplatte 1' 2015/04/01 01:36:10 [3] backup.fromdual.com: Removing Arkeia's snapshot of galera3

    we can see that our problem pretty much started with the end of the WMware snapshot (01:36:10 + 5.08 = 1:36:15). By the way: For such kind of investigations it is always good to have a ntp daemon for time synchronization running. Otherwise problem investigation becomes much harder...

    Some more and deeper investigation shows that we loose from time to time nodes during VMware snapshots (galera3). But they recover quickly because they can do an IST. In worst case we can loose 2 nodes and then the whole Galera Cluster has gone.

    192.168.42.3 / node Galera3 2015-04-10 01:44:00 [3] backup.fromdual.com: Creating a snapshot of galera3 2015-04-10 01:44:08 [3] backup.fromdual.com: Created a snapshot of galera3 2015-04-10 01:44:15 [3] backup.fromdual.com: galera3: backup the changed blocks of disk 'Festplatte 1' using NBD transport 2015-04-10 01:45:39 [3] backup.fromdual.com: galera3: saving the Change Block Tracking's reference for disk 'Festplatte 1' 2015-04-10 01:45:39 [3] backup.fromdual.com: Removing Arkeia's snapshot of galera3
    150410 1:44:07 [Note] WSREP: (158f71de, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://galera1:4567 tcp://galera2:4567 150410 1:44:07 [Warning] WSREP: last inactive check more than PT1.5S ago (PT7.06159S), skipping check 150410 1:44:08 [Note] WSREP: Received NON-PRIMARY. 150410 1:44:10 [Note] WSREP: Shifting OPEN -> PRIMARY (TO: 30399299) 150410 1:44:11 [Warning] WSREP: Gap in state sequence. Need state transfer. 150410 1:44:11 [Note] WSREP: Prepared IST receiver, listening at: tcp://galera3:4568 150410 1:44:11 [Note] WSREP: Member 0.0 (galera3) requested state transfer from '*any*'. Selected 2.0 (galera2)(SYNCED) as donor. 150410 1:44:11 [Note] WSREP: Shifting PRIMARY -> JOINER (TO: 30399309) 150410 1:44:11 [Note] WSREP: Requesting state transfer: success, donor: 2 150410 1:44:11 [Note] WSREP: 2.0 (galera2): State transfer to 0.0 (galera3) complete. 150410 1:44:11 [Note] WSREP: Member 2.0 (galera2) synced with group. 150410 1:44:11 [Note] WSREP: Receiving IST: 8 writesets, seqnos 30399291-30399299 150410 1:44:11 [Note] WSREP: IST received: dcca768c-b5ad-11e3-bbc0-fb576fb3c451:30399299 150410 1:44:11 [Note] WSREP: 0.0 (galera3): State transfer from 2.0 (galera2) complete. 150410 1:44:11 [Note] WSREP: Shifting JOINER -> JOINED (TO: 30399309) 150410 1:44:11 [Note] WSREP: Member 0.0 (galera3) synced with group. 150410 1:44:11 [Note] WSREP: Shifting JOINED -> SYNCED (TO: 30399309) 150410 1:44:11 [Note] WSREP: Synchronized with group, ready for connections 150410 1:44:13 [Note] WSREP: (158f71de, 'tcp://0.0.0.0:4567') turning message relay requesting off 150410 1:45:42 [Warning] WSREP: last inactive check more than PT1.5S ago (PT2.47388S), skipping check 150410 1:45:43 [Note] WSREP: (158f71de, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://galera1:4567 tcp://galera2:4567 150410 1:45:44 [Note] WSREP: (158f71de, 'tcp://0.0.0.0:4567') reconnecting to 54de92f8 (tcp://galera1:4567), attempt 0 150410 1:45:44 [Note] WSREP: (158f71de, 'tcp://0.0.0.0:4567') reconnecting to c9d964d3 (tcp://galera2:4567), attempt 0 150410 1:45:48 [Note] WSREP: (158f71de, 'tcp://0.0.0.0:4567') turning message relay requesting off 150410 1:47:26 [Note] WSREP: (158f71de, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://galera1:4567 150410 1:47:27 [Note] WSREP: (158f71de, 'tcp://0.0.0.0:4567') reconnecting to 54de92f8 (tcp://galera1:4567), attempt 0 150410 1:47:31 [Note] WSREP: (158f71de, 'tcp://0.0.0.0:4567') turning message relay requesting off
    192.168.42.1 / node Galera1 2015-04-10 01:47:24 [3] backup.fromdual.com: Creating a snapshot of galera1 2015-04-10 01:47:29 [3] backup.fromdual.com: Created a snapshot of galera1 2015-04-10 01:47:40 [3] backup.fromdual.com: galera1: backup the changed blocks of disk 'Festplatte 1' using NBD transport 2015-04-10 01:48:43 [3] backup.fromdual.com: galera1: saving the Change Block Tracking's reference for disk 'Festplatte 1' 2015-04-10 01:48:44 [3] backup.fromdual.com: Removing Arkeia's snapshot of galera1 150410 1:44:02 [Note] WSREP: (54de92f8, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://galera3:4567 150410 1:44:04 [Note] WSREP: (54de92f8, 'tcp://0.0.0.0:4567') reconnecting to 158f71de (tcp://galera3:4567), attempt 0 150410 1:44:12 [Note] WSREP: Member 0.0 (galera3) requested state transfer from '*any*'. Selected 2.0 (galera2)(SYNCED) as donor. 150410 1:45:43 [Note] WSREP: (54de92f8, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://galera3:4567 150410 1:45:44 [Note] WSREP: (54de92f8, 'tcp://0.0.0.0:4567') reconnecting to 158f71de (tcp://galera3:4567), attempt 0 150410 1:45:48 [Note] WSREP: (54de92f8, 'tcp://0.0.0.0:4567') turning message relay requesting off 150410 1:47:27 [Warning] WSREP: last inactive check more than PT1.5S ago (PT3.66452S), skipping check 150410 1:47:27 [Note] WSREP: (54de92f8, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://galera3:4567 150410 1:47:30 [Note] WSREP: (54de92f8, 'tcp://0.0.0.0:4567') turning message relay requesting off
    192.168.42.2 / node Galera2 2015-04-10 02:09:55 [3] backup.fromdual.com: Creating a snapshot of galera2 2015-04-10 02:09:58 [3] backup.fromdual.com: Created a snapshot of galera2 2015-04-10 02:10:05 [3] backup.fromdual.com: galera2: backup the changed blocks of disk 'Festplatte 1' using NBD transport 2015-04-10 02:10:53 [3] backup.fromdual.com: galera2: saving the Change Block Tracking's reference for disk 'Festplatte 1' 2015-04-10 02:10:54 [3] backup.fromdual.com: Removing Arkeia's snapshot of galera2
    150410 1:44:02 [Note] WSREP: (c9d964d3, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://galera3:4567 150410 1:44:03 [Note] WSREP: (c9d964d3, 'tcp://0.0.0.0:4567') reconnecting to 158f71de (tcp://galera3:4567), attempt 0 150410 1:44:08 [Warning] WSREP: discarding established (time wait) 158f71de (tcp://192.168.42.3:4567) 150410 1:44:11 [Note] WSREP: Member 0.0 (galera3) requested state transfer from '*any*'. Selected 2.0 (galera2)(SYNCED) as donor. 150410 1:44:13 [Note] WSREP: (c9d964d3, 'tcp://0.0.0.0:4567') turning message relay requesting off 150410 1:45:43 [Note] WSREP: (c9d964d3, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://galera3:4567 150410 1:45:44 [Note] WSREP: (c9d964d3, 'tcp://0.0.0.0:4567') reconnecting to 158f71de (tcp://galera3:4567), attempt 0 150410 1:45:48 [Note] WSREP: (c9d964d3, 'tcp://0.0.0.0:4567') turning message relay requesting off 150410 1:47:26 [Note] WSREP: (c9d964d3, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://galera1:4567 150410 1:47:27 [Note] WSREP: (c9d964d3, 'tcp://0.0.0.0:4567') reconnecting to 54de92f8 (tcp://galera1:4567), attempt 0 150410 1:47:30 [Note] WSREP: (c9d964d3, 'tcp://0.0.0.0:4567') turning message relay requesting off 150410 2:09:57 [Warning] WSREP: last inactive check more than PT1.5S ago (PT1.83618S), skipping check

    The backups are done with the 2 options:

    enabled.

    Possibly this is the reason and one should disable those features in combination with Galera. Further investigation is going on. In worst case VMware snapshotting with Galera should be avoided.

    Rename MySQL Partition

    Shinguz - Fri, 2015-03-06 15:00
    Taxonomy upgrade extras: partitionrenameDDL

    Before I forget it and have to search again here a short note about how to rename a MySQL Partition:

    My dream:

    ALTER TABLE history RENAME PARTITION p2015_kw10 INTO p2015_kw09;
    In reality: ALTER TABLE history REORGANIZE PARTITION p2015_kw10 INTO ( PARTITION p2015_kw09 VALUES LESS THAN (UNIX_TIMESTAMP('2015-03-02 00:00:00')) );

    Caution: REORGANIZE PARTITION causes a full copy of the whole partition!

    Hint: I assume it would be very easy for MySQL or MariaDB to make this DDL command an in-place operation...

    MySQL Partitioning was introduced in MySQL 5.1.

    Nagios and Icinga plug-ins for MySQL/MariaDB released

    FromDual.en - Wed, 2015-03-04 13:03
    Taxonomy upgrade extras: nagiosicingaplug-inmysqlmariadbpercona serverGalera Clusterrelease

    FromDual is pleased to announce the release of a new version 1.0.0 of the Nagios and Icinga plug-ins for MySQL, MariaDB, Percona Server and Galera Cluster.


    Any information about the changes and the new functions of the Nagios and Icinga plug-ins you can find here.

    If you have any problems with the new version you can reach us by e-mail at: contact@fromdual.com or by phone on +41 44 940 24 82.



    Your FromDual Team

    MySQL Enterprise Incremental Backup simplified

    Shinguz - Wed, 2015-02-25 19:41
    Taxonomy upgrade extras: mebMySQL Enterprise BackupenterpriseBackupincremental backup

    MySQL Enterprise Backup (MEB) has the capability to make real incremental (differential and cumulative?) backups. The actual releases are quite cool and you should really look at it...

    Unfortunately the original MySQL documentation is much too complicated for my simple mind. So I did some testing and simplified it a bit for our customers...

    If you want to dive into the original documentation please look here: Making an Incremental Backup .

    If you want to use MySQL Enterprise Backup please let us know and we send you a quote...

    Prepare MySQL Backup infrastructure mkdir /backup/full /backup/incremental1 /backup/incremental2
    Full MySQL Backup mysqlbackup --defaults-file=/etc/my.cnf --user=root --backup-dir=/backup/full backup mysqlbackup --defaults-file=/etc/my.cnf --user=root --backup-dir=/backup/full apply-log
    First MySQL Incremental Backup mysqlbackup --defaults-file=/etc/my.cnf --user=root --incremental --incremental-base=dir:/backup/full --incremental-backup-dir=/backup/incremental1 backup mysqlbackup --defaults-file=/etc/my.cnf --user=root --backup-dir=/backup/full --incremental-backup-dir=/backup/incremental1 apply-incremental-backup
    Second MySQL Incremental Backup mysqlbackup --defaults-file=/etc/my.cnf --user=root --incremental --incremental-base=dir:/backup/full --incremental-backup-dir=/backup/incremental2 backup mysqlbackup --defaults-file=/etc/my.cnf --user=root --backup-dir=/backup/full --incremental-backup-dir=/backup/incremental2 apply-incremental-backup

    and so on...

    MySQL Restore mysqlbackup --defaults-file=/etc/my.cnf --user=root --backup-dir=/backup/full copy-back

    Have fun with MySQL Enterprise Backup. If you need any help with your MySQL Backup concept, please let us know.

    Creating Event Handlers with MySQL Enterprise Monitor

    Shinguz - Tue, 2015-02-17 13:57
    Taxonomy upgrade extras: MySQL Enterprise Monitormonitoringeventhandlermpmperformance monitor

    MySQL Enterprise Monitor (MEM) has by default no Event Handlers created and activated. These Event Handlers you have to define yourself according to your needs.

    In this article we discuss how to create MySQL Enterprise Monitor Event Handlers with MEM v.3.0.18. For other (older) versions the steps may vary...

    Task: Event Handler for maximum Connections reached

    We would like to be notified by MySQL Enterprise Monitor when the number of connections is near to max_connections.

    For this we search first which Advisors are available at all: Configuration -> Advisors -> Availability.


    Here we can see that we have an Advisor called Maximum Connection Limit Nearing Or Reached which is scheduled for every 5 minutes and has thresholds at 75, 85, 95 and 100%:


    Now we know which Advisor should create and Event. As a next step we have to create and Event which should be triggered: Configuration -> Event Handling -> Create Event Handler.


    Here we can create and Event with all its needed configuration: Events -> All -> server.


    If we look at the Events we can even see the detailed description and how the values for the Event are collected:


    Task: Event Handler for used disk space

    For this Event Handler we need the Advisor Filesystem Free Space under Operating System:


    In this advisor we can configure the Threshold as well:


    In the Event Handler we can define which Assets shall be monitored. For example the mountpoint: /.


    Local disks can only be monitored, if a local MySQL Enterprise Monitor Agent is installed. An agent-less MySQL Enterprise Monitor cannot monitor local disk resources...

    Have fun using the MySQL Enterprise Monitor. If you need any help in installing or configuring MEM do not hesitate to contact us.

    All these functions are also implemented in the FromDual Performance Monitor for MySQL. If you want to relay on Open Source technology only you should consider our Performance Monitor.

    MySQL Environment MyEnv 1.1.4 has been released

    FromDual.en - Wed, 2015-02-11 08:18
    Taxonomy upgrade extras: myenvoperationMySQL Operationsmulti instanceconsolidationtestingupgrade

    FromDual has the pleasure to announce the release of the new version 1.1.4 of its popular MySQL, Galera Cluster, MariaDB and Percona Server multi-instance environment MyEnv.

    The new MyEnv can be downloaded here.

    In the inconceivable case that you find a bug in the MyEnv please report it to our bug tracker.

    Any feedback, statements and testimonials are welcome as well! Please send them to feedback@fromdual.com.

    Upgrade from 1.1.x to 1.1.4 # cd ${HOME}/product # tar xf /download/myenv-1.1.4.tar.gz # rm -f myenv # ln -s myenv-1.1.4 myenv

    If you are using plug-ins for showMyEnvStatus create all the links in the new directory structure:

    cd ${HOME}/product/myenv ln -s ../../utl/oem_agent.php plg/showMyEnvStatus/
    Changes in MyEnv 1.1.4

    Because an ugly but non-dangerous bugs we skipped the announcement of version 1.1.3.

    All changes since MyEnv 1.1.2 are listed here. We recommend to skip version 1.1.3

    MyEnv
    • Error messages are sent to stderr instead of stdout, start error messages are tested after up test.
    • Error message if wrong user wants to stop database.
    • MyEnv init script slightly improved.
    • False positive error message in start fixed.
    • Variable parsing in my.cnf made more robust.
    • Error messages and warnings made more verbose/clear.
    • Bug during stopping database with dummy instance fixed (MGB).
    • Cgroups functionality added.
    • PHP debug message is now just displayed in debug mode.
    MyEnv Installer
    • installMyEnv cleans up my.cnf in basedir if it did not exists before to avoid nasty warning message.
    • Move [client] and [mysqldump] section to top to not forget them later.
    • Bug with empty myenv.conf fixed (KN).
    • Install advice for SuSE was wrong for runlevels for MyEnv.
    • my.cnf template updated.
    • /tmp as location for socket removed because of RedHat tmpcleaner.
    • datadir redundancy removed.
    • lost+found folder was added to hideschema.
    • installMyEnv.sh replaced by installMyEnv.
    MyEnv Utilities
    • Partitioning tools error output is now written to stderr correctly.
    • log_maintenance.sh script contribution added (TS).
    • HAproxy check added.
    • purge_binary_log.py added.
    • insert_test.sh improved.
    • lb.monitor skript added.

    For subscriptions of commercial use of MyEnv please get in contact with us.

    Nagios and Icinga plug-ins for MySQL 1.0.0 have been released

    Shinguz - Wed, 2015-02-04 22:02
    Taxonomy upgrade extras: nagiosicingaplug-inmonitorperformancealert

    FromDual has the pleasure to announce the release of the new version 1.0.0 of its widely used Nagios and Icinga plug-ins for MySQL, Galera Cluster, MariaDB and Percona Server.

    All plug-ins are basically renewed and should now work all correctly.

    The new Nagios/Icinga plug-ins can be downloaded here.

    In the inconceivable case that you find a bug in the Nagios/Icinga plug-ins please report it to our bug tracker.

    Any feedback, statements and testimonials are welcome as well! Please send them to feedback@fromdual.com.

    Description of the current functionality

    Details about the functionality and the usage of each plug-in you get with the option: --help.

    The following Nagios/Icinga plug-in for MySQL and MariaDB are currently available:

    check_db_mysql.pl

    This Nagios/Icinga plug-in alerts you if your MySQL database is not up and running.

    check_errorlog_mysql.pl and errorLogFilterRules.pm

    This Nagios/Icinga plug-in alerts you if it finds some suspicious messages in the MySQL error log.
    The rules which messages should be ignored can be found in the file errorLogFilterRules.pm. If you want to add your own filter rules please add them in this file as well.

    check_galera_nodes.pl

    This Nagios/Icinga plug-in alerts you if the actual number of nodes in your a Galera Cluster is not the expected one.

    check_repl_mysql_cnt_slave_hosts.pl

    This Nagios/Icinga plug-in alerts you if your MySQL Slaves have not reported to their Master properly their existence with the report_host variable.

    check_repl_mysql_heartbeat.pl

    This Nagios/Icinga plug-in alerts you if your MySQL Slave is too many heartbeats behind its Master.

    check_repl_mysql_io_thread.pl

    This Nagios/Icinga plug-in alerts you if your MySQL Slaves IO thread is not up an running.

    check_repl_mysql_read_exec_pos.pl

    This Nagios/Icinga plug-in alerts you if your MySQL Slaves read and execution positions differ too much.

    check_repl_mysql_readonly.pl

    This Nagios/Icinga plug-in alerts you if your MySQL Slave is NOT set to readonly.

    check_repl_mysql_seconds_behind_master.pl

    This Nagios/Icinga plug-in alerts you if your MySQL Slave falls too many seconds behind its Master.

    check_repl_mysql_sql_thread.pl

    This Nagios/Icinga plug-in alerts you if your Slaves SQL thread is not up an running.

    perf_mysql.pl

    This Nagios/Icinga plug-in gathers MySQL and MariaDB performance data.

    Changes in FromDual Nagios/Icinga plug-ins 1.0.0 All plug-ins
    • Usage was improved. The usage can be shown with the --help option.
    • Usage states now which GRANT privileges are needed for a specific plug-in.
    • Examples added how to use each plug-in.
    • Default socket location moved from /tmp/mysql.sock to /var/run/mysqld/mysqld.sock.
    • New host/socket convention implemented in all scripts similar to MySQL client tools.
    • -epn tag added for Icinga.
    check_errorlog_mysql.pl
    • Some bugs fixed.
    • More filtering rules added.
    • Filtering rules separated into own file.
    • Entry point finding problem fixed.
    check_repl_mysql_heartbeat.pl
    • Script name fixed.
    check_db.pl
    • Unknown command problem with Galera Cluster caught.
    • mysqladmin ping removed and implemented in Perl.
    Support and Subscription for commercial use

    For subscriptions for commercial use of this software please get in contact with us.

    Linuxtag: Knowledge and People - and New Colleagues?

    Jörg Brühe - Wed, 2015-02-04 10:49

    At FromDual, we are currently preparing for our participation in the "Chemnitzer Linux-Tage" in March.
    While we don't yet know whether the programme committee accepted our proposed talks, we will have a booth and hope for interesting exchanges with others from the MySQL, database, Linux, ... world. Of course, we will also mention that we are looking for additional colleagues - there are so many tasks that we need more people to handle them all. (In case you got curious, look here: http://www.fromdual.com/mysql-dba-2014-12-de )

    While I attended the Chemnitzer Linux-Tage already last year (thank you, Frank Hofmann, for recommending them!), it will be the first time there for FromDual as a company. I enjoyed the informal atmosphere, which made it easy to get into contact with new people, to learn, and to discuss both facts and opinions.

    To those of you who didn't yet attend such events, I can only say: You are missing some great experiences! It is good to get stimulated by others, by their problems and their experiences, so that one's thoughts are broadened and start considering new fields. Often, they lead to insights that are helpful for one's own daily work.

    In the opposite direction, we at FromDual hope that during the Linux-Tage we can help others to make (better) use of MySQL in all its variants, with its surrounding tools and products, so that everybody will profit.

    The Chemnitzer Linux-Tage will take place on March 21 and 22, 2015, in Chemnitz, Germany. Parts of the programme will probably be delivered in English, so even those of you who don't understand German might enjoy coming there. If you now consider a visit, you will find further information here:
    https://chemnitzer.linux-tage.de/2015/de

    We will be happy to meet you in Chemnitz - to talk about whatever interests both you and us, maybe even about you joining us?

    Pages

    Subscribe to MySQL, Galera Cluster and MariaDB support and services aggregator - FromDual all (en)