You are here

FromDual TechFeed (de)

FromDual Schulungen trotz Corona - einfach online und remote

Oli Sennhauser - Mon, 2020-03-23 15:43

Aufgrund der aktuellen Corona-Pandemie sind sämtliche FromDual vor Ort Schulungen, Schulungen bei unseren Schulungspartnern sowie FromDual Beratungseinsätze bis auf weiteres sistiert.

Damit Sie diesen Frühling aber nicht ganz ohne Weiterbildung auskommen müssen, sind wir bereits seit letzter Woche daran, alternative Möglichkeiten mittels online Schulungen zu testen. Erste Testschulungen wurden bereits Ende letzter Woche und anfangs dieser Woche durchgeführt.

Möglicherweise bietet sich Ihnen in den nächsten Wochen die Möglichkeit, aus dem Homeoffice die eine oder andere unserer online-Schulungen zu besuchen. Voraussichtlich betroffen sind die folgenden Schulungstermine:

  • 2. bis 4. April: Galera Cluster für MariaDB/MySQL im Linuxhotel in Essen
  • 23. bis 24. April: Galera Cluster für MariaDB/MySQL in der Heinlein Academy in Berlin
  • 4. bis 8. Mai: MariaDB/MySQL für Fortgeschrittene bei der GfU Cyrus in Köln
  • 11. bis 15. Mai: MariaDB/MySQL für Fortgeschrittene in der Heinlein Academy in Berlin

Ob es auch noch spätere Schulungstermine betrifft werden wir sehen...

Remote geht es besser - FromDual remote-DBA Dienstleistungen

Die Corona-Pandemie verursacht möglicherweise auch ein anderes oder neues Lastmuster auf Ihrer Datenbank.

  • Buchungen werden storniert (Reiseportale),
  • Rabatt-Aktionen gestartet (Outdoor-Aktivitäten),
  • es wird vermehrt online eingekauft (Webshops),
  • es wird vermehrt kommuniziert (VoIP, Video-Conferencing, Screen Sharing) oder auch
  • die Plattformen des Gesundheitswesen werden heftiger als sonst in Anspruch genommen.
  • etc.

Falls diese Situation bei Ihnen zu betrieblichen Problemen oder Performance-Engpässen führt, helfen wir Ihnen auch gerne mit einem remote-DBA Einsatz anstelle eines vor Ort Beratungseinsatzes weiter. Wir haben diese Technologien bereits seit Jahren im Einsatz und zeigen Ihnen auch gerne remote, wie Sie Ihre Probleme in den Griff kriegen.

Taxonomy upgrade extras: schulungremote-dbaremoteberatungconsultingtraining

Eher Finger weg: innodb_deadlock_detect

Oli Sennhauser - Fri, 2020-03-06 15:27

Kürzlich haben wir bei einem unserer Kunden, der gelegentlich massive Datenbankprobleme hat, bei der Durchsicht der MySQL Konfigurationsdatei (my.cnf) festgestellt, dass er die InnoDB Deadlock-Erkennung (innodb_deadlock_detect) deaktiviert hatte.

Da wir davon bisher immer abgeraten haben, ich aber noch nie konkret über dieses Problem gestolpert bin, bin ich der Sache noch etwas nachgegangen und habe zur Variable innodb_deadlock_detect recherchiert.

Die MySQL Dokumentation sagt dazu folgendes [1]:

Disabling Deadlock Detection
On high concurrency systems, deadlock detection can cause a slowdown when numerous threads wait for the same lock. At times, it may be more efficient to disable deadlock detection and rely on the innodb_lock_wait_timeout setting for transaction rollback when a deadlock occurs. Deadlock detection can be disabled using the innodb_deadlock_detect configuration option.

Und zum Parameter innodb_deadlock_detect selbst [2]:

This option is used to disable deadlock detection. On high concurrency systems, deadlock detection can cause a slowdown when numerous threads wait for the same lock. At times, it may be more efficient to disable deadlock detection and rely on the innodb_lock_wait_timeout setting for transaction rollback when a deadlock occurs.

Das Problem ist, dass jedes mal, wenn MySQL einen (Row) Lock oder Table Lock macht, überprüft wird, ob dieser Lock einen Deadlock verursacht. Was entsprechend teuer ist. Diese Feature wurde übrigens von Facebook entwickelt [3].

Die entsprechenden Funktionen sind in [4] zu finden:

class DeadlockChecker, method check_and_resolve (DeadlockChecker::check_and_resolve) Every InnoDB (row) Lock (for mode LOCK_S or LOCK_X) and type ORed with LOCK_GAP or LOCK_REC_NOT_GAP, ORed with LOCK_INSERT_INTENTION Enqueue a waiting request for a lock which cannot be granted immediately. lock_rec_enqueue_waiting()

und

Every (InnoDB) Table Lock Enqueues a waiting request for a table lock which cannot be granted immediately. Checks for deadlocks. lock_table_enqueue_waiting()

Das heisst jetzt, wenn die Variable innodb_deadlock_detect eingeschaltet ist (= default) wird bei jedem Lock (Row oder Table) überprüft, ob dadurch ein Deadlock entsteht. Wenn die Variable ausgeschaltet ist, wird diese Überprüfung NICHT ausgeführt (was schneller ist) und die Transaktion bleibt im (Dead-)Lock hängen bis der Lock frei gegeben wird oder die Zeit innodb_lock_wait_timeout (default 50 Sekunden) überschritten ist. Dann schlägt der InnoDB Lock Wait Timeout (Detektor?) zu.

SQL> SHOW GLOBAL VARIABLES LIKE 'innodb_lock_wait%'; +--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | innodb_lock_wait_timeout | 50 | +--------------------------+-------+

Das bedeutet, das Deaktivieren der InnoDB Deadlock Detektion ist interessant, wenn Sie sehr viele (wie Facebook!?!) kurze/kleine Transaktionen haben, bei welchen wenig bis keine Konflikte auftreten.
Im Weiteren wird empfohlen, gleichzeitig die innodb_lock_wait_timeout auf einen sehr geringen Wert (wenige Sekunden) einzustellen.

Da die meisten unserer Kunden aber nicht in die Kragenweite Facebook passen und tendenziell eher nicht viele gleichzeitige kurze/kleine Transaktionen haben sondern wenig lange Transaktionen (mit wahrscheinlich vielen Locks und daher einer grossen Deadlock-Wahrscheinlichkeit), kann ich mir durchaus vorstellen, dass das deaktivieren diese Parameters für das Verschlucken (Locks stauen auf) des Kundensystems verantwortlich ist, was anschliessen dazu führt, dass max_connections erreicht wird und schliesslich gar nichts mehr geht.

Daher würde ich dringend empfehlen, die InnoDB Deadlock Detektierung aktiviert zu lassen. Ausser man weiss genau, was man tut (nach ca. 2 Wochen testen und messen).

Literatur Taxonomy upgrade extras: innodbdeadlocklockperformancelockingblock

FromDual ist 10 Jahre alt

Oli Sennhauser - Mon, 2020-03-02 10:01

Am 1. März 2020 wurde die FromDual GmbH 10 Jahre alt! Wir möchten allen Kunden, Partnern und Interessenten herzlich für die Unterstützung und gute Zusammenarbeit in den vergangenen 10 Jahren danken. Es würde uns freuen, Euch auch in den kommenden 10 Jahren kompetent beraten und betreuen zu dürfen.

Euer FromDual Team

Bild von kalhh auf Pixabay

Taxonomy upgrade extras: fromdual

FromDual mit Galera Cluster und SQL Query Tuning an den Chemnitzer Linux-Tagen 2020

Oli Sennhauser - Tue, 2020-02-11 09:55

Zum 22. mal finden am 14. und 15. März 2020 die Chemnitzer Linux-Tage an der Technische Universität Chemnitz statt.

FromDual ist am Samstag, 14. März das erste mal mit einem Workshop "MariaDB Galera Cluster ganz einfach" und am Sonntag, 15. März wieder einmal mit einem Vortrag, diesmal zum Thema MariaDB Performance Tuning: "MariaDB SQL Query Tuning für Applikations-Entwickler", präsent.

Falls Sie also einmal unter Anleitung einen MariaDB Galera Cluster aufsetzen oder sich mit SQL Query Tuning unter MariaDB vertraut machen wollen, besuchen Sie doch einfach die Chemnitzer Linux-Tage 2020 und sitzen Sie in unseren Vortrag rein oder melden Sie sich für unseren Workshop an.

Bild von Génesis Gabriella auf Pixabay

FromDual wird offizieller MariaDB Partner

Oli Sennhauser - Tue, 2020-02-11 08:51

Nach Jahren der losen Zusammenarbeit wird FromDual jetzt, im Frühjahr 2020, offizieller MariaDB Partner.

Schon seit Beginn der MariaDB Erfolgsgeschichte befasst sich FromDual mit der Open Source Datenbank MariaDB und hat ihre Kunden mit Rat und Tat beim Betrieb der Datenbank unterstützt.

Da die Nachfrage nach MariaDB in den letzten Jahren laufend zu nahm, bietet FromDual schon seit längerem Schulungen, vor Ort Beratungen (Consulting), und remote-DBA Dienstleistungen für die MariaDB Datenbank an.

Der nächste Schritt, die offizielle Zusammenarbeit, ist somit schon längst fällig: Daher ist FromDual nun offizieller MariaDB Partner geworden.

Dieser Schritt ermöglicht es FromDual ihren Kunden auch beim Erwerb, der Nutzung und der Implementierung der MariaDB Enterprise Edition Subskription tatkräftig zu unterstützen um den grössten Nutzen aus dieser Datenbank zu ziehen.

Zudem wurden sämtliche FromDual Tools und die Monitoring-as-a-Service Dienstleistung für die MariaDB Datenbank funktionsfähig gemacht und werden schon seit einiger Zeit vollständig unterstützt.

Taxonomy upgrade extras: mariadbPartnerschaftpartnerenterprisesupportconsultingberatung

FromDual Performance Monitor 1.1.0 für MariaDB und MySQL freigegeben

Oli Sennhauser - Thu, 2020-02-06 14:19

FromDual hat die Version 1.1.0 des Performance Monitors für MariaDB, MySQL und Galera Cluster (fpmmm) freigegeben.

Dieser Performance Monitor ermöglicht es DBAs und Systemadministratoren einen tiefen Einblick in das Innenleben der Datenbank und des Servers, auf dem sich die Datenbank befindet, zu erhalten.

Die neue Version steht hier zum Download bereit.

Falls Sie sich die Mühe sparen wollen, eine eigene Monitoring-Infrastruktur aufzubauen, nutzen Sie doch einfach unsere kostengünstige Monitoring-as-a-Service Lösung. Gerne schicken wir Ihnen ein Angebot.

Wichtige Neuerungen

  • fpmmm steht jetzt paketiert für CentOS mit RPM und Ubuntu mit DEB Paketen zur Verfügung.
  • MariaDB 10.4 wird ab sofort offiziell durch fpmmm unterstützt.
  • fpmmm unterstützt ab sofort ausschliesslich PHP Version 7+.
  • Sämtliche Zabbix Templates wurden auf die Version 4.0 upgegraded.
  • Ein Backup-Hook wurde eingeführt. Sie können somit Ihr eigenes Backup-System oder den FromDual Backup Manager in fpmmm einbinden.
  • Graphen für InnoDB Buffer Pool flushing und InnoDB Files wurden hinzugefügt.
  • MariaDB Thread Pool Monitoring, für Anwendungen welche extrem viele Verbindungen zu Datenbank aufbauen, wurde hinzugefügt.
  • Die Graphen für den Aria Pagecache wurde verbessert.

Eine vollständige Liste der Verbesserungen finden Sie hier.

Eine detaillierte Anleitung zum fpmmm finden Sie im fpmmm Installation Guide.

Viel Spass beim Überwachen Ihrer MariaDB/MySQL Datenbank,
Ihr FromDual Team

Taxonomy upgrade extras: fpmmmreleasemonitoringmonitor

MariaDB und MySQL Schulungsprogramm 2020

Oli Sennhauser - Fri, 2019-12-13 16:02

Hiermit präsentieren wir Ihnen das FromDual Schulungsprogramm 2020 für MariaDB und MySQL. Auch nächstes Jahr führen wir wieder zahlreiche MariaDB und MySQL Schulungen für Anfänger und Fortgeschrittene bei unseren 3 Partnern in Essen, Köln und Berlin durch.

Die Liste mit Schulungsterminen 2020 finden Sie hier.

Welches für Sie das richtige Schulungsmodul ist, erläutern wir unter der Seite Schulungsmodule.

Gleich richtig los geht es anfangs Januar mit MariaDB und MySQL für Einsteiger. Dieser Kurs ist schon fast ausgebucht und findet daher sicher statt. Sichern Sie sich also noch die letzten Plätze!

FromDual Technik-Blog

Im FromDual Blog berichten wir regelmässig darüber, mit welchen Themen wir unser Wissen erweitert haben. Diese Artikel sind frei verfügbar und somit auch Ihnen zugänglich:


Werkzeuge für den täglichen Datenbankbetrieb

FromDual bietet Ihnen auch eine breite Palette von nützlichen Werkzeuge für den täglichen Betrieb und die Pflege Ihrer MariaDB und MySQL Datenbanken an:


Monitoring as a Service

Falls Sie sich keine eigene Monitoring Lösung antun wollen, bieten wir Ihnen auch gerne unsere preiswerte Monitoring-as-a-Service (MaaS) Lösung an. Nehmen Sie hierzu einfach mit uns Kontakt auf. Wir unterbreiten Ihnen gerne ein Angebot.

Ich denke, hiermit haben Sie genügend zu tun, damit Ihnen über die Feiertag nicht langweilig wird... :-)

Schöne Weihnachten und einen gute Rutsch ins neue Jahr wünscht Ihnen
Ihr FromDual Schulungsteam

Taxonomy upgrade extras: 2020schulungtrainingmysql-trainingmariadb traininggalera cluster trainingmariadb schulunggalera cluster schulung

MySQL Enterprise Schulung für Fortgeschrittene von FromDual

Oli Sennhauser - Tue, 2018-02-06 15:33

Aufgrund der gestiegen Nachfrage hat FromDual eine MySQL Enterprise Schulung für Fortgeschrittene MySQL DBAs und DevOps entwickelt. Nachdem wir diese Schulung im letzten Jahr zusammen mit ausgewählten Kunden ausführlich getestet haben bieten wir sie 2018 für eine breite Kundschaft an.

Die MySQL Enterprise Schulung richtet sich an MySQL DBA's und DevOps, welche bereits mit MySQL vertraut sind und nun vor der Herausforderung stehen, eine ernsthafte MySQL Enterprise Infrastruktur zu betreiben.

Die Liste der Themen, welche während der dreitägigen Schulung behandelt werden finden sie hier.

Es bietet sich zudem die Möglichkeit, 2 Tage MySQL Performance Tuning aus der MySQL für Fortgeschrittene Schulung anzuhängen.

Gerne führen wir diese Schulung bei ihnen vor Ort oder bei einem unserer Schulungspartner in Essen, Berlin oder Köln durch.

Bei Fragen stehen wir Ihnen auch gerne per eMail zur Verfügung.

Taxonomy upgrade extras: mysqlenterpriseschulungfortgeschrittene

MySQL Enterprise Schulung für Fortgeschrittene von FromDual

Oli Sennhauser - Tue, 2018-02-06 15:33

Aufgrund der gestiegen Nachfrage hat FromDual eine MySQL Enterprise Schulung für Fortgeschrittene MySQL DBAs und DevOps entwickelt. Nachdem wir diese Schulung im letzten Jahr zusammen mit ausgewählten Kunden ausführlich getestet haben bieten wir sie 2018 für eine breite Kundschaft an.

Die MySQL Enterprise Schulung richtet sich an MySQL DBA's und DevOps, welche bereits mit MySQL vertraut sind und nun vor der Herausforderung stehen, eine ernsthafte MySQL Enterprise Infrastruktur zu betreiben.

Die Liste der Themen, welche während der dreitägigen Schulung behandelt werden finden sie hier.

Es bietet sich zudem die Möglichkeit, 2 Tage MySQL Performance Tuning aus der MySQL für Fortgeschrittene Schulung anzuhängen.

Gerne führen wir diese Schulung bei ihnen vor Ort oder bei einem unserer Schulungspartner in Essen, Berlin oder Köln durch.

Bei Fragen stehen wir Ihnen auch gerne per eMail zur Verfügung.

Taxonomy upgrade extras: mysqlenterpriseschulungfortgeschrittene

Schulung MySQL und MariaDB für Fortgeschrittene in Köln 2018

Oli Sennhauser - Wed, 2018-01-17 16:02

Ende Februar, genauer vom 26. Februar bis 2. März (5 Tage), bietet FromDual eine weitere Schulung für DBAs und DevOps an, unsere häufigst besuchte Schulung: MySQL und MariaDB für Fortgeschrittene.

Diese MySQL/MariaDB Schulung findet in den Räumlichkeiten des FromDual Schulungspartners der GFU Cyrus GmbH in Köln-Deutz statt.

Es haben sich bereits genügend Teilnehmer angemeldet, sodass diese Schulung sicher statt findet. Es hat aber noch Platz für mindestens 3 weitere Teilnehmer.

Die Schulung findet in deutscher Sprache statt.

Den Inhalt dieser fünftägigen MySQL/MariaDB Schulung finden Sie hier.

Bei weiteren Fragen nehmen Sie bitte mit uns Kontakt auf.

Taxonomy upgrade extras: schulungkölnfortgeschrittene

Schulung MySQL und MariaDB für Fortgeschrittene in Köln 2018

Oli Sennhauser - Wed, 2018-01-17 16:02

Ende Februar, genauer vom 26. Februar bis 2. März (5 Tage), bietet FromDual eine weitere Schulung für DBAs und DevOps an, unsere häufigst besuchte Schulung: MySQL und MariaDB für Fortgeschrittene.

Diese MySQL/MariaDB Schulung findet in den Räumlichkeiten des FromDual Schulungspartners der GFU Cyrus GmbH in Köln-Deutz statt.

Es haben sich bereits genügend Teilnehmer angemeldet, sodass diese Schulung sicher statt findet. Es hat aber noch Platz für mindestens 3 weitere Teilnehmer.

Die Schulung findet in deutscher Sprache statt.

Den Inhalt dieser fünftägigen MySQL/MariaDB Schulung finden Sie hier.

Bei weiteren Fragen nehmen Sie bitte mit uns Kontakt auf.

Taxonomy upgrade extras: schulungkölnfortgeschrittene

Abbrechende MariaDB/MySQL Verbindungen

Oli Sennhauser - Sun, 2017-04-23 14:48
Translate to your preferred language:

Wer sich etwas vertieft mit den MariaDB Status Zählern (SHOW GLOBAL STATUS;) auseinander setzt, wird früher oder später auf den Zähler Aborted_clients stossen:

mariadb> SHOW GLOBAL STATUS LIKE 'aborted_clients'; +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | Aborted_clients | 5392 | +-----------------+-------+

Wenn man sich dann die MariaDB Dokumentation anschaut, steht da folgendes:

Number of aborted client connections. This can be due to the client not calling mysql_close() before exiting, the client sleeping without issuing a request to the server for more seconds than specified by wait_timeout or interactive_timeout, or by the client program ending in the midst of transferring data.

Also:

  • Vergessener Aufruf von mysql_close().
  • Inaktive Verbindung (Sleep) für mehr als wait_timeout oder interactive_timeout Sekunden.
  • Unerwartete Beendigung der Applikation.

Der erste Punkt geht unter die Kategorie: Unsauber programmiert und somit ein Fehler in der Anwendung.

Der zweite Punkt ist eher ein Konfigurationsproblem sei es auf Datenbankseite oder auf Applikationsseite.

Hier stellt sich die Frage: Warum sind die Timeouts so eingestellt, wenn die Timeouts kurz sind? Default für beide Timeouts ist 28800 Sekunden, also 8 Stunden.

mariadb> SHOW GLOBAL VARIABLES LIKE '%timeout'; +---------------------------+-------+ | Variable_name | Value | +---------------------------+-------+ | interactive_timeout | 28800 | | wait_timeout | 28800 | +---------------------------+-------+

Oder aber: Warum schickt die Anwendung so lange keine Daten über eine geöffnete Verbindung (hat die Anwendung die Verbindung verloren)?

Der zweite Fall trifft üblicherweise dann ein, wenn persistente Verbindungen verwendet werden (Java Connection Pool, Ruby on Rails, PHP Persistent Database Connections, etc.). Dann sollten die Entwickler den Connector so konfigurieren, dass er alle paar Sekunden einen Ping über die Verbindung schickt.

Der dritte Fall hat sehr viel Ähnlichkeit mit dem ersten Fall: Die Applikation beendet sich früher als erwartet. Das kann zum Beispiel auftreten, wenn:

  • exit() vor mysql_close() (Fall 1 von oben)
  • Applikation wurde unerwartet von aussen beendet (kill, OOM Killer, systemd, etc.)
  • Firewalls oder LoadBalancer die eine idelnde Verbindung nach einer bestimmten Zeit terminieren (z.B. 300 Sekunden).

Feststellen, wen es betrifft

Eigentlich sollte die Applikation in den meisten Fällen selber merken, wenn sie unerwartet beendet wurde (Fall 2 und 3). Sehr oft tut sie dies aber nicht. Daher müssen wir als Datenbankverantwortliche der Applikation manchmal auf die Sprünge helfen, und Ihr mitteilen, dass unerwartete Abbrüche überhaupt vorkommen und wo im Applikationscode das ungefähr geschieht.

Das erste Anzeichen dafür ist, wie oben Beschrieben, ein Status Zähler von Aborted_clients grösser 0. Spannend wir das ganze aber erst wenn wir Aborted_clients in Relation zur Uptime setzen. Wenn wir nur 10 Aborted_clients über die letzten 100 Tage haben, dann kann man diesen Zähler getrost vernachlässigen. Wenn Aborted_clients im Minutentakt hochgezählt wird, sollte man sich das Ganze schon genauer anschauen:

mariadb> SHOW GLOBAL STATUS WHERE Variable_name = 'aborted_clients' OR Variable_name = 'uptime'; +-----------------+--------+ | Variable_name | Value | +-----------------+--------+ | Aborted_clients | 5438 | | Uptime | 257991 | +-----------------+--------+ mariadb> SELECT 257991/5438 AS Abort_every_s; +---------------+ | Abort_every_s | +---------------+ | 47.4423 | +---------------+

Die nächste Frage, die sich stellt, ist, welcher Applikationsuser ist davon betroffen? Diese Frage kann auf 2 verschiedene Wege beantwortet werden. Entweder über das PERFORMANCE_SCHEMA mit der Abfrage nach Accounts, welche die Verbindung nicht sauber schliessen:

mariadb> SELECT ess.user, ess.host , (a.total_connections - a.current_connections) - ess.count_star as not_closed , ((a.total_connections - a.current_connections) - ess.count_star) * 100 / (a.total_connections - a.current_connections) as pct_not_closed FROM performance_schema.events_statements_summary_by_account_by_event_name ess JOIN performance_schema.accounts a on (ess.user = a.user and ess.host = a.host) WHERE ess.event_name = 'statement/com/quit' AND (a.total_connections - a.current_connections) > ess.count_star ; +-----------+---------------+------------+----------------+ | user | host | not_closed | pct_not_closed | +-----------+---------------+------------+----------------+ | applicat | 10.0.246.74 | 31 | 0.0001 | | applicat | 10.0.246.73 | 59 | 0.0003 | | replicate | 10.0.246.72 | 1 | 100.0000 | | applicat | 10.0.246.76 | 4 | 0.0024 | | root | localhost | 3 | 0.0053 | | applicat | localhost | 51880 | 0.2991 | | applicat | 10.0.246.77 | 1 | 100.0000 | +-----------+---------------+------------+----------------+

Oder über das Error Log, wenn die die Variable log_warnings auf 2 gesetzt ist:

mariadb> SHOW GLOBAL VARIABLES LIKE 'log_warn%'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | log_warnings | 2 | +---------------+-------+

Bei MySQL 5.7 und neuer wird hierzu die Variable log_error_verbosity auf 3 gesetzt:

mysql> SHOW GLOBAL VARIABLES LIKE '%verbosity%'; +---------------------+-------+ | Variable_name | Value | +---------------------+-------+ | log_error_verbosity | 3 | +---------------------+-------+

Ein Eintrag ins Error Log sieht dann in etwa wie folgt aus:

[Warning] Aborted connection 411 to db: 'app_production' user: 'app_prod' host: 'mysql_LB' (Got an error writing communication packets) [Warning] Aborted connection 417 to db: 'app_production' user: 'app_prod' host: 'mysql_LB' (Got an error writing communication packets) [Warning] Aborted connection 424 to db: 'billing' user: 'billing' host: 'mysql_LB' (Got an error reading communication packets) [Warning] Aborted connection 433 to db: 'app_production' user: 'app_prod' host: 'mysql_LB' (Got an error reading communication packets) [Warning] Aborted connection 449 to db: 'app_production' user: 'app_prod' host: 'mysql_LB' (Got an error reading communication packets)

Somit wissen wir jetzt also bereits etwas genauer, welchen User von welchem Host mit Zugriff auf welches Schema es erwischt hat. Zudem haben wir noch die Connection ID welche eindeutig und aufsteigen ist.

Feststellen wo im Code es ungefähr passiert

Um festzustellen, wo im Applikationscode der unerwartete Abbruch ungefähr passiert haben wir wiederum 2 Möglichkeiten.

Wir können dazu das General Query Log einschalten (Achtung: kann sehr rasant anwachsen!) und dann die enstprechende Verbindung suchen:

mariadb> SET GLOBAL general_log = 1; mariadb> SHOW GLOBAL VARIABLES LIKE '%general%'; +------------------+----------------------------------------------------------------------+ | Variable_name | Value | +------------------+----------------------------------------------------------------------+ | general_log | ON | | general_log_file | /home/mysql/database/mariadb-10.2/log/chef_mariadb-10.2_general.log | +------------------+----------------------------------------------------------------------+

Eine sauber abgebaute Verbindung sieht darin wie folgt aus:

Time Id Command Argument 2017-04-20T10:26:05.613569Z 26 Connect app@localhost on test using TCP/IP 2017-04-20T10:26:05.613629Z 26 Query SELECT ... 2017-04-20T10:26:05.613681Z 26 Quit

Eine unsauber abgebaute oder noch offene Verbindung wie folgt:

Time Id Command Argument 2017-04-20T10:26:17.165585Z 27 Connect app@localhost on test using TCP/IP 2017-04-20T10:26:17.165785Z 27 Query SELECT ... Fehlendes Quit

Die zweite Möglichkeit besteht darin, die Sequenz von Abfragen über das PERFORMANCE_SCHEMA zu ermitteln. Hierzu müssen wir als erstes herausfinden, wie gross der Unterschied zwischen der Processlist ID und der Datenbankserver internen Thread ID ist:

mariadb> SELECT thread_id, processlist_id, thread_id-processlist_id AS diff FROM performance_schema.threads WHERE processlist_id IS NOT NULL ORDER BY thread_id DESC LIMIT 3; +-----------+----------------+------+ | thread_id | processlist_id | diff | +-----------+----------------+------+ | 436 | 433 | 3 | | 427 | 424 | 3 | | 420 | 417 | 3 | +-----------+----------------+------+

In einem zweiten Schritt können wir über das PERFORMANCE_SCHEMA herausfinden welche Befehle von der Applikation ausgeführt wurden:

UPDATE performance_schema.setup_consumers SET enabled = 1 WHERE name = 'events_statements_history_long'; mariadb> SELECT thread_id, event_name, sql_text, current_schema FROM performance_schema.events_statements_history_long WHERE thread_id = 433 + 3; +-----------+---------------------------------+----------------------------------------------------------+----------------+ | THREAD_ID | EVENT_NAME | SQL_TEXT | CURRENT_SCHEMA | +-----------+---------------------------------+----------------------------------------------------------+----------------+ | 436 | statement/sql/set_option | SET NAMES utf8, @@SESSION.sql_mode = 'STRICT_ALL_TABLES' | app_production | | 436 | statement/com/Ping | NULL | app_production | | 436 | statement/sql/select | select @@character_set_database as 'Value' | app_production | | 436 | statement/sql/show_tables | SHOW TABLES LIKE 'schema_migrations' | app_production | | 436 | statement/sql/show_tables | SHOW TABLES LIKE 'schema_migrations' | app_production | | 436 | statement/sql/select | SELECT `schema_migrations`.* FROM `schema_migrations` | app_production | | 436 | statement/sql/show_fields | SHOW FULL FIELDS FROM `schema_migrations` | app_production | | 436 | statement/sql/show_fields | SHOW FULL FIELDS FROM `settings` | app_production | +-----------+---------------------------------+----------------------------------------------------------+----------------+

Nun sollte es in Zusammenarbeit mit den Entwicklern nicht mehr allzu schwer fallen, die entsprechenden Stellen im Applikationscode zu finden und die Fehler zu beheben.

Taxonomy upgrade extras: verbindungaborted_clientsoom

Abbrechende MariaDB/MySQL Verbindungen

Oli Sennhauser - Sun, 2017-04-23 14:48
Translate to your preferred language:

Wer sich etwas vertieft mit den MariaDB Status Zählern (SHOW GLOBAL STATUS;) auseinander setzt, wird früher oder später auf den Zähler Aborted_clients stossen:

mariadb> SHOW GLOBAL STATUS LIKE 'aborted_clients'; +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | Aborted_clients | 5392 | +-----------------+-------+

Wenn man sich dann die MariaDB Dokumentation anschaut, steht da folgendes:

Number of aborted client connections. This can be due to the client not calling mysql_close() before exiting, the client sleeping without issuing a request to the server for more seconds than specified by wait_timeout or interactive_timeout, or by the client program ending in the midst of transferring data.

Also:

  • Vergessener Aufruf von mysql_close().
  • Inaktive Verbindung (Sleep) für mehr als wait_timeout oder interactive_timeout Sekunden.
  • Unerwartete Beendigung der Applikation.

Der erste Punkt geht unter die Kategorie: Unsauber programmiert und somit ein Fehler in der Anwendung.

Der zweite Punkt ist eher ein Konfigurationsproblem sei es auf Datenbankseite oder auf Applikationsseite.

Hier stellt sich die Frage: Warum sind die Timeouts so eingestellt, wenn die Timeouts kurz sind? Default für beide Timeouts ist 28800 Sekunden, also 8 Stunden.

mariadb> SHOW GLOBAL VARIABLES LIKE '%timeout'; +---------------------------+-------+ | Variable_name | Value | +---------------------------+-------+ | interactive_timeout | 28800 | | wait_timeout | 28800 | +---------------------------+-------+

Oder aber: Warum schickt die Anwendung so lange keine Daten über eine geöffnete Verbindung (hat die Anwendung die Verbindung verloren)?

Der zweite Fall trifft üblicherweise dann ein, wenn persistente Verbindungen verwendet werden (Java Connection Pool, Ruby on Rails, PHP Persistent Database Connections, etc.). Dann sollten die Entwickler den Connector so konfigurieren, dass er alle paar Sekunden einen Ping über die Verbindung schickt.

Der dritte Fall hat sehr viel Ähnlichkeit mit dem ersten Fall: Die Applikation beendet sich früher als erwartet. Das kann zum Beispiel auftreten, wenn:

  • exit() vor mysql_close() (Fall 1 von oben)
  • Applikation wurde unerwartet von aussen beendet (kill, OOM Killer, systemd, etc.)
  • Firewalls oder LoadBalancer die eine idelnde Verbindung nach einer bestimmten Zeit terminieren (z.B. 300 Sekunden).

Feststellen, wen es betrifft

Eigentlich sollte die Applikation in den meisten Fällen selber merken, wenn sie unerwartet beendet wurde (Fall 2 und 3). Sehr oft tut sie dies aber nicht. Daher müssen wir als Datenbankverantwortliche der Applikation manchmal auf die Sprünge helfen, und Ihr mitteilen, dass unerwartete Abbrüche überhaupt vorkommen und wo im Applikationscode das ungefähr geschieht.

Das erste Anzeichen dafür ist, wie oben Beschrieben, ein Status Zähler von Aborted_clients grösser 0. Spannend wir das ganze aber erst wenn wir Aborted_clients in Relation zur Uptime setzen. Wenn wir nur 10 Aborted_clients über die letzten 100 Tage haben, dann kann man diesen Zähler getrost vernachlässigen. Wenn Aborted_clients im Minutentakt hochgezählt wird, sollte man sich das Ganze schon genauer anschauen:

mariadb> SHOW GLOBAL STATUS WHERE Variable_name = 'aborted_clients' OR Variable_name = 'uptime'; +-----------------+--------+ | Variable_name | Value | +-----------------+--------+ | Aborted_clients | 5438 | | Uptime | 257991 | +-----------------+--------+ mariadb> SELECT 257991/5438 AS Abort_every_s; +---------------+ | Abort_every_s | +---------------+ | 47.4423 | +---------------+

Die nächste Frage, die sich stellt, ist, welcher Applikationsuser ist davon betroffen? Diese Frage kann auf 2 verschiedene Wege beantwortet werden. Entweder über das PERFORMANCE_SCHEMA mit der Abfrage nach Accounts, welche die Verbindung nicht sauber schliessen:

mariadb> SELECT ess.user, ess.host , (a.total_connections - a.current_connections) - ess.count_star as not_closed , ((a.total_connections - a.current_connections) - ess.count_star) * 100 / (a.total_connections - a.current_connections) as pct_not_closed FROM performance_schema.events_statements_summary_by_account_by_event_name ess JOIN performance_schema.accounts a on (ess.user = a.user and ess.host = a.host) WHERE ess.event_name = 'statement/com/quit' AND (a.total_connections - a.current_connections) > ess.count_star ; +-----------+---------------+------------+----------------+ | user | host | not_closed | pct_not_closed | +-----------+---------------+------------+----------------+ | applicat | 10.0.246.74 | 31 | 0.0001 | | applicat | 10.0.246.73 | 59 | 0.0003 | | replicate | 10.0.246.72 | 1 | 100.0000 | | applicat | 10.0.246.76 | 4 | 0.0024 | | root | localhost | 3 | 0.0053 | | applicat | localhost | 51880 | 0.2991 | | applicat | 10.0.246.77 | 1 | 100.0000 | +-----------+---------------+------------+----------------+

Oder über das Error Log, wenn die die Variable log_warnings auf 2 gesetzt ist:

mariadb> SHOW GLOBAL VARIABLES LIKE 'log_warn%'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | log_warnings | 2 | +---------------+-------+

Bei MySQL 5.7 und neuer wird hierzu die Variable log_error_verbosity auf 3 gesetzt:

mysql> SHOW GLOBAL VARIABLES LIKE '%verbosity%'; +---------------------+-------+ | Variable_name | Value | +---------------------+-------+ | log_error_verbosity | 3 | +---------------------+-------+

Ein Eintrag ins Error Log sieht dann in etwa wie folgt aus:

[Warning] Aborted connection 411 to db: 'app_production' user: 'app_prod' host: 'mysql_LB' (Got an error writing communication packets) [Warning] Aborted connection 417 to db: 'app_production' user: 'app_prod' host: 'mysql_LB' (Got an error writing communication packets) [Warning] Aborted connection 424 to db: 'billing' user: 'billing' host: 'mysql_LB' (Got an error reading communication packets) [Warning] Aborted connection 433 to db: 'app_production' user: 'app_prod' host: 'mysql_LB' (Got an error reading communication packets) [Warning] Aborted connection 449 to db: 'app_production' user: 'app_prod' host: 'mysql_LB' (Got an error reading communication packets)

Somit wissen wir jetzt also bereits etwas genauer, welchen User von welchem Host mit Zugriff auf welches Schema es erwischt hat. Zudem haben wir noch die Connection ID welche eindeutig und aufsteigen ist.

Feststellen wo im Code es ungefähr passiert

Um festzustellen, wo im Applikationscode der unerwartete Abbruch ungefähr passiert haben wir wiederum 2 Möglichkeiten.

Wir können dazu das General Query Log einschalten (Achtung: kann sehr rasant anwachsen!) und dann die enstprechende Verbindung suchen:

mariadb> SET GLOBAL general_log = 1; mariadb> SHOW GLOBAL VARIABLES LIKE '%general%'; +------------------+----------------------------------------------------------------------+ | Variable_name | Value | +------------------+----------------------------------------------------------------------+ | general_log | ON | | general_log_file | /home/mysql/database/mariadb-10.2/log/chef_mariadb-10.2_general.log | +------------------+----------------------------------------------------------------------+

Eine sauber abgebaute Verbindung sieht darin wie folgt aus:

Time Id Command Argument 2017-04-20T10:26:05.613569Z 26 Connect app@localhost on test using TCP/IP 2017-04-20T10:26:05.613629Z 26 Query SELECT ... 2017-04-20T10:26:05.613681Z 26 Quit

Eine unsauber abgebaute oder noch offene Verbindung wie folgt:

Time Id Command Argument 2017-04-20T10:26:17.165585Z 27 Connect app@localhost on test using TCP/IP 2017-04-20T10:26:17.165785Z 27 Query SELECT ... Fehlendes Quit

Die zweite Möglichkeit besteht darin, die Sequenz von Abfragen über das PERFORMANCE_SCHEMA zu ermitteln. Hierzu müssen wir als erstes herausfinden, wie gross der Unterschied zwischen der Processlist ID und der Datenbankserver internen Thread ID ist:

mariadb> SELECT thread_id, processlist_id, thread_id-processlist_id AS diff FROM performance_schema.threads WHERE processlist_id IS NOT NULL ORDER BY thread_id DESC LIMIT 3; +-----------+----------------+------+ | thread_id | processlist_id | diff | +-----------+----------------+------+ | 436 | 433 | 3 | | 427 | 424 | 3 | | 420 | 417 | 3 | +-----------+----------------+------+

In einem zweiten Schritt können wir über das PERFORMANCE_SCHEMA herausfinden welche Befehle von der Applikation ausgeführt wurden:

UPDATE performance_schema.setup_consumers SET enabled = 1 WHERE name = 'events_statements_history_long'; mariadb> SELECT thread_id, event_name, sql_text, current_schema FROM performance_schema.events_statements_history_long WHERE thread_id = 433 + 3; +-----------+---------------------------------+----------------------------------------------------------+----------------+ | THREAD_ID | EVENT_NAME | SQL_TEXT | CURRENT_SCHEMA | +-----------+---------------------------------+----------------------------------------------------------+----------------+ | 436 | statement/sql/set_option | SET NAMES utf8, @@SESSION.sql_mode = 'STRICT_ALL_TABLES' | app_production | | 436 | statement/com/Ping | NULL | app_production | | 436 | statement/sql/select | select @@character_set_database as 'Value' | app_production | | 436 | statement/sql/show_tables | SHOW TABLES LIKE 'schema_migrations' | app_production | | 436 | statement/sql/show_tables | SHOW TABLES LIKE 'schema_migrations' | app_production | | 436 | statement/sql/select | SELECT `schema_migrations`.* FROM `schema_migrations` | app_production | | 436 | statement/sql/show_fields | SHOW FULL FIELDS FROM `schema_migrations` | app_production | | 436 | statement/sql/show_fields | SHOW FULL FIELDS FROM `settings` | app_production | +-----------+---------------------------------+----------------------------------------------------------+----------------+

Nun sollte es in Zusammenarbeit mit den Entwicklern nicht mehr allzu schwer fallen, die entsprechenden Stellen im Applikationscode zu finden und die Fehler zu beheben.

Taxonomy upgrade extras: verbindungaborted_clients

DOAG Datenbank Konferenz 2016

Oli Sennhauser - Tue, 2016-05-10 19:43

Heute war ich auf der DOAG Datenbank 2016 Konferenz in Düsseldorf. Der einzige Vortrag zum Thema MySQL war mein eigener: MySQL für Oracle DBAs. Daher hatte ich die Möglichkeit wieder mal etwas über den Zaun zu linsen. Hier meine Notizen:

Oracle Database in-Memory - What's new and what's comming

Von Andy Rivenes, Senior Principal Product Manager, Oracle Corporation

  • Ist NICHT eine one size fits all Lösung.
  • Für Analytics-Abfragen (DWH, Datamart, BI).
  • Beschleunigt OLTP Workload NICHT.
  • Ist ein Column-Store.
  • In-Memory heisst: weiteren Cache (RAM). Mehr Speicher (RAM) hinzufügen. Column-Store Size. Daten werden partiell doppelt vorgehalten.
  • Beide Formate Row und Column sind vorhanden.
  • Optimizer entscheidet ob Row-Store oder Column-Store verwendet wird.
  • Wird vom DBA pro Tabelle, Partition, Subpartition oder Materialized View festgelegt. 2 - 20 x Kompression.
  • Column-Store wird on demand aufgebaut. Wenn nicht verfügbar, fallback auf Row-Store.
  • Column-Store Advisor.
  • Jeder Core scannt eine Spalte aus dem Column-Store.
  • Geschwindigkeit: Mia rows/s. Wenn man bedenkt, dass ein Core nur ca. 3 Mia CPU Zyklen pro Sekunde hat, frage ich mich, wie das gerechnet wird...
  • Eliminiere Indices und nutze Column-Store für grosse OLAP Tabellen.
  • Schreiben ist langsam. Wie kriegt man denn die Daten schnell in die DB bei grossen Datenmengen?
  • Scale-out und Scale-Up: Parallelisieren über mehrere Server hinweg.
  • Spiegeln von Duplikaten über Server hinweg. Somit können Joins lokal gemacht werden.
  • In-Memory Workload on (Oracle) Chips möglich: DAX, Database Accelleration Engine.
  • JSON BLOB.
  • Heatmap: Schlaue Guestimates (in der Zukunft).
  • When not to use Oracle in-Memory Database: Siehe Slides.

Die Folien muss ich mir noch organisieren. Klingt total cool. Ich frage mich nur, wie gross/breit ist dieser Anwendungsfall? Ich werde mich wohl bald mal mit dem MariaDB Column Store befassen müssen/wollen.

Oracle ACFS / CloudFS zuverlässig nutzbar?

Ralf Appelbaum und Claudia Gabriel, TEAM GmbH

  • CFS im ASM
  • ACFS = ASM CFS
  • für RAC
  • ASM ~ LVM
  • TS im ASM (somit erinnert mich das ein bissen an etwas clevere Raw-Devices).
  • Backup, Dumps, etc. ins ACFS. Somit sind sie O/S sichtbar und zugreifbar.
  • Fazit war: Nein, ist es nicht!

Ich frage mich nur, warum, man sich das antun will...? Das ist nur wieder ein neues proprietäres Feature, welches nicht KISS ist!

Datenbanken in der Oracle Cloud - Überblick und Best Practices

Manuel Hossfeld, Oracle Deutschland B.V. & Co KG

  • Oracle Cloud ist eine Public Cloud.
  • Arbeitet nur mit ssh Keys.
  • SQL*Net über ssh-Tunnel. Will man das? Kann den SQL*Net kein SSL???
  • Keine Hybrid-Cloud damit machen!
  • Managed MySQL in der Oracle Cloud ist immer noch nicht vorgesehen.
  • Einsatzgebiete: Er sprach nie von produktiver Nutzung...

Wozu braucht man das?

cgroups im Einsatz - Ressource Management mal anders rum

Florian Feicht, Trivadis GmbH

  • Oracle selber scheint das vorzusehen. Siehe Oracle Dokumentation.
  • systemd-cgtop
  • systemd-cgls
  • Oracle init.ora Parameter processor_group_name
  • systemd/code> service!
  • Oracle schreibt ins Alert Log, wenn es nicht klappt. Die Oracle Oracle Instanz fährt nicht hoch, wenn man die Cgroup nicht angelegt hat.

Die Oracle Cracks fanden das cool, hatten aber einige Bedenken (betreffen Optimizer und so). MyEnv für MySQL und MariaDB kann das schon seit Oktober 2014. Wir sind also gut vorn mit dabei.

Taxonomy upgrade extras: mysqlOraclein-memorymemorycgroups

DOAG Datenbank Konferenz 2016

Oli Sennhauser - Tue, 2016-05-10 19:43

Heute war ich auf der DOAG Datenbank 2016 Konferenz in Düsseldorf. Der einzige Vortrag zum Thema MySQL war mein eigener: MySQL für Oracle DBAs. Daher hatte ich die Möglichkeit wieder mal etwas über den Zaun zu linsen. Hier meine Notizen:

Oracle Database in-Memory - What's new and what's comming

Von Andy Rivenes, Senior Principal Product Manager, Oracle Corporation

  • Ist NICHT eine one size fits all Lösung.
  • Für Analytics-Abfragen (DWH, Datamart, BI).
  • Beschleunigt OLTP Workload NICHT.
  • Ist ein Column-Store.
  • In-Memory heisst: weiteren Cache (RAM). Mehr Speicher (RAM) hinzufügen. Column-Store Size. Daten werden partiell doppelt vorgehalten.
  • Beide Formate Row und Column sind vorhanden.
  • Optimizer entscheidet ob Row-Store oder Column-Store verwendet wird.
  • Wird vom DBA pro Tabelle, Partition, Subpartition oder Materialized View festgelegt. 2 - 20 x Kompression.
  • Column-Store wird on demand aufgebaut. Wenn nicht verfügbar, fallback auf Row-Store.
  • Column-Store Advisor.
  • Jeder Core scannt eine Spalte aus dem Column-Store.
  • Geschwindigkeit: Mia rows/s. Wenn man bedenkt, dass ein Core nur ca. 3 Mia CPU Zyklen pro Sekunde hat, frage ich mich, wie das gerechnet wird...
  • Eliminiere Indices und nutze Column-Store für grosse OLAP Tabellen.
  • Schreiben ist langsam. Wie kriegt man denn die Daten schnell in die DB bei grossen Datenmengen?
  • Scale-out und Scale-Up: Parallelisieren über mehrere Server hinweg.
  • Spiegeln von Duplikaten über Server hinweg. Somit können Joins lokal gemacht werden.
  • In-Memory Workload on (Oracle) Chips möglich: DAX, Database Accelleration Engine.
  • JSON BLOB.
  • Heatmap: Schlaue Guestimates (in der Zukunft).
  • When not to use Oracle in-Memory Database: Siehe Slides.

Die Folien muss ich mir noch organisieren. Klingt total cool. Ich frage mich nur, wie gross/breit ist dieser Anwendungsfall? Ich werde mich wohl bald mal mit dem MariaDB Column Store befassen müssen/wollen.

Oracle ACFS / CloudFS zuverlässig nutzbar?

Ralf Appelbaum und Claudia Gabriel, TEAM GmbH

  • CFS im ASM
  • ACFS = ASM CFS
  • für RAC
  • ASM ~ LVM
  • TS im ASM (somit erinnert mich das ein bissen an etwas clevere Raw-Devices).
  • Backup, Dumps, etc. ins ACFS. Somit sind sie O/S sichtbar und zugreifbar.
  • Fazit war: Nein, ist es nicht!

Ich frage mich nur, warum, man sich das antun will...? Das ist nur wieder ein neues proprietäres Feature, welches nicht KISS ist!

Datenbanken in der Oracle Cloud - Überblick und Best Practices

Manuel Hossfeld, Oracle Deutschland B.V. & Co KG

  • Oracle Cloud ist eine Public Cloud.
  • Arbeitet nur mit ssh Keys.
  • SQL*Net über ssh-Tunnel. Will man das? Kann den SQL*Net kein SSL???
  • Keine Hybrid-Cloud damit machen!
  • Managed MySQL in der Oracle Cloud ist immer noch nicht vorgesehen.
  • Einsatzgebiete: Er sprach nie von produktiver Nutzung...

Wozu braucht man das?

cgroups im Einsatz - Ressource Management mal anders rum

Florian Feicht, Trivadis GmbH

  • Oracle selber scheint das vorzusehen. Siehe Oracle Dokumentation.
  • systemd-cgtop
  • systemd-cgls
  • Oracle init.ora Parameter processor_group_name
  • systemd/code> service!
  • Oracle schreibt ins Alert Log, wenn es nicht klappt. Die Oracle Oracle Instanz fährt nicht hoch, wenn man die Cgroup nicht angelegt hat.

Die Oracle Cracks fanden das cool, hatten aber einige Bedenken (betreffen Optimizer und so). MyEnv für MySQL und MariaDB kann das schon seit Oktober 2014. Wir sind also gut vorn mit dabei.

Taxonomy upgrade extras: mysqlOraclein-memorymemorycgroups

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

Oli Sennhauser - Fri, 2015-05-29 18:12
Wer 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. Außerdem 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 meistverbreiteten 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.

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

Oli Sennhauser - Fri, 2015-05-29 18:12
Wer 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. Außerdem 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 meistverbreiteten 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.

Wir suchen Dich: MySQL DBA für FromDual Support

Oli Sennhauser - Sun, 2014-12-21 21:40
Wer sind wir?

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


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


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


Stellenbeschreibung

Wir suchen einen deutschsprachigen Mitarbeiter (Sie oder Ihn) für Dienstleistungen rund um MySQL (hauptsächlich Support und remote-DBA Arbeiten) in Vollzeit. Primär solltest Du unseren Kunden helfen, ihre MySQL-Installationen zu betreiben.


Du bist fit in MySQL und:


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

Was wir zudem von Dir erwarten:


  • Kenntnisse über MySQL, Percona Server oder MariaDB aufweisen oder Bereitschaft sich diese anzueignen
  • mit dem Open-Source Ökosystem vertraut sein und Beiträge dazu geleistet haben
  • als DBA oder DevOps wissen, wie man Datenbank-Systeme betreibt
  • verstehen, was beim Betrieb von Datenbanken falsch gemacht werden kann
  • Freude an selbständig remote arbeiten und der Kommunikation über IRC, Skype, Mail und Telefon
  • gute Kenntnisse des Linux Systems
  • dass Du Deine Ideen rund um MySQL einbringst.

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


Um Deine Arbeit erledigen zu können, arbeitest Du in einer europäischen Zeitzone. Deine Arbeitszeit kannst Du, 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, aber ein Umzug ist nicht notwendig: Wir ermöglichen das Arbeiten von zu hause oder unterstützen bei der Suche einer geeigneten Arbeitsräumlichkeit. Gute schriftliche und mündliche Englischkenntnisse sind zwingend.


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


Du solltest in der Lage sein, die meiste Zeit selbständig zu arbeiten, 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 weiterkommst, werden Dir Deine Kollegen von FromDual gerne helfen.


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


Wie geht es weiter

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


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


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


Wir suchen Dich: MySQL DBA für FromDual Support

Oli Sennhauser - Sun, 2014-12-21 21:40
Wer sind wir?

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


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


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


Stellenbeschreibung

Wir suchen einen deutschsprachigen Mitarbeiter (Sie oder Ihn) für Dienstleistungen rund um MySQL (hauptsächlich Support und remote-DBA Arbeiten) in Vollzeit. Primär solltest Du unseren Kunden helfen, ihre MySQL-Installationen zu betreiben.


Du bist fit in MySQL und:


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

Was wir zudem von Dir erwarten:


  • Kenntnisse über MySQL, Percona Server oder MariaDB aufweisen oder Bereitschaft sich diese anzueignen
  • mit dem Open-Source Ökosystem vertraut sein und Beiträge dazu geleistet haben
  • als DBA oder DevOps wissen, wie man Datenbank-Systeme betreibt
  • verstehen, was beim Betrieb von Datenbanken falsch gemacht werden kann
  • Freude an selbständig remote arbeiten und der Kommunikation über IRC, Skype, Mail und Telefon
  • gute Kenntnisse des Linux Systems
  • dass Du Deine Ideen rund um MySQL einbringst.

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


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


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


Du solltest in der Lage sein, die meiste Zeit selbständig zu arbeiten, 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 weiterkommst, werden Dir Deine Kollegen von FromDual gerne helfen.


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


Wie geht es weiter

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


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


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


Ugly way to install MySQL Galera Cluster 5.6 on Ubuntu 14.04

Oli Sennhauser - Mon, 2014-10-20 21:26

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

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

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

Now we have to download Galera 5.6 from Coderships website:

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

And then the ugly part:

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

Finally:

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

And to activate the changes:

service mysql restart

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

Taxonomy upgrade extras: galeraGalera Clusterinstallationubuntu

Pages

Subscribe to FromDual aggregator - FromDual TechFeed (de)