Agrégateur de flux

Taxonomy upgrade extras: mysqlschulungmariadbtraining

Vom Montag, 09. bis Freitag 13. Februar 2015 findet im Linux Hotel in Essen eine MySQL/MariaDB Schulung für Fortgeschrittene statt.

Falls Sie Interesse haben, an dieser Schulung teilzunehmen, bitten wir Sie, Sich schnell anzumelden, um Sich Ihren Platz zu sichern. Es sind nur noch wenige Plätze vorhanden.

Anmelden für die MySQL Schulung für Fortgeschrittene können Sie Sich hier.

Bitte vermerken Sie unter Anmerkungen, dass Sie über den FromDual Newsletter auf das Angebot aufmerksam gemacht wurden.

Alle übrigen Schulungstermine finden Sie unter MySQL/MariaDB Schulung.

Oracle will nach einer Meldung des amerikanischen Magazins „Business Insider“ eine grössere Zahl Support-Mitarbeiter in Deutschland, Spanien, den Niederlanden und der Schweiz entlassen und die offenen Stellen mit jungen Leuten aus Rumänien besetzen. Grund seien die geringeren Personalkosten in dem osteuropäischen Land. Dr. Dietmar Neugebauer, Vorstandsvorsitzender der DOAG, hat dafür kein Verständnis: „Die aktuelle Umfrage der DOAG zeigt, dass die Kunden weiterhin Probleme mit dem Oracle-Support haben. Deshalb habe ich grosse Bedenken bei dieser Massnahme. Wir werden diese Aktion kritisch begleiten.“

Ob diese Umstellung auch den MySQL Support betrifft ist uns zurzeit nicht bekannt, nichts desto trotz bieten wir Ihnen deutschsprachigen MySQL-Support an. Ihr FromDual Support-Team steht Ihnen bei Fragen und Problemen jederzeit gerne kompetent zur Seite.

Taxonomy upgrade extras: mysqlmysql-supportsupportOracledoag

Oracle will nach einer Meldung des amerikanischen Magazins „Business Insider“ eine grössere Zahl Support-Mitarbeiter in Deutschland, Spanien, den Niederlanden und der Schweiz entlassen und die offenen Stellen mit jungen Leuten aus Rumänien besetzen. Grund seien die geringeren Personalkosten in dem osteuropäischen Land. Dr. Dietmar Neugebauer, Vorstandsvorsitzender der DOAG, hat dafür kein Verständnis: „Die aktuelle Umfrage der DOAG zeigt, dass die Kunden weiterhin Probleme mit dem Oracle-Support haben. Deshalb habe ich grosse Bedenken bei dieser Massnahme. Wir werden diese Aktion kritisch begleiten.“

Ob diese Umstellung auch den MySQL Support betrifft ist uns zurzeit nicht bekannt, nichts desto trotz bieten wir Ihnen deutschsprachigen MySQL-Support an. Ihr FromDual Support-Team steht Ihnen bei Fragen und Problemen jederzeit gerne kompetent zur Seite.

Taxonomy upgrade extras: mysqlmysql-supportsupportOracledoag

Taxonomy upgrade extras: mysqlmysql-supportsupportOracledoagOracle will nach einer Meldung des amerikanischen Magazins „Business Insider“ eine grössere Zahl Support-Mitarbeiter in Deutschland, Spanien, den Niederlanden und der Schweiz entlassen und die offenen Stellen mit jungen Leuten aus Rumänien besetzen. Grund seien die geringeren Personalkosten in dem osteuropäischen Land. Dr. Dietmar Neugebauer, Vorstandsvorsitzender der DOAG, hat dafür kein Verständnis: „Die aktuelle Umfrage der DOAG zeigt, dass die Kunden weiterhin Probleme mit dem Oracle-Support haben. Deshalb habe ich grosse Bedenken bei dieser Massnahme. Wir werden diese Aktion kritisch begleiten.“

Ob diese Umstellung auch den MySQL Support betrifft ist uns zurzeit nicht bekannt, nichts desto trotz bieten wir Ihnen deutschsprachigen MySQL-Support an. Ihr FromDual Support-Team steht Ihnen bei Fragen und Problemen jederzeit gerne kompetent zur Seite.

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.

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.

Herbst = Budget-Zeit

Jedes Jahr im Herbst kommt die Zeit des Budgetierens. Habe Sie Ihren Support für MySQL, MariaDB oder Percona Server für 2015 schon eingeplant?

FromDual bietet Ihnen effizienten und kostengünstigen Support in deutscher Sprache für Ihre kritischen MySQL, MariaDB und Percona Server Datenbanken sowie Ihre Galera Cluster.
Wenn Sie bei Problemen nicht mehr weiter wissen, hilft Ihnen unser Team schnell, kompetent und unkompliziert weiter, damit Sie vor Ihrem Management immer nur im besten Licht dastehen.

FromDual bietet Ihnen preiswert Office-Hour Support und 7x24-Support mit garantierten, kurzen Antwortzeiten (SLA).

Melden Sie sich bitte bei uns, wenn Sie ein Angebot wünschen.

MySQL Schulungsprogramm 2015

Benötigen Sie oder Ihre Mitarbeiter noch mehr MySQL Know-How? In unseren Schulungszentren in Essen, Berlin und Zürich können Sie Ihre Kenntnisse vertiefen und Praxiserfahrung aufbauen. Sämtliche Kurse finden Sie in unserem Schulungsprogramm 2015.

Folgende Kurse finden Sie in unserem Angebot:

• MySQL Kurse für Einsteiger (3 Tage)
• MySQL Betrieb (1 Tag)
• Architekturen und Hochverfügbarkeit (2 Tage)
• Performance Tuning (2 Tage)
• MySQL für Fortgeschrittene (5 Tage)
• Galera Cluster (2 Tage)

Neu bieten wir 2015 auch MySQL Kurse für Einsteiger an. In diesen Kursen vermitteln wir die Kenntnisse, welche Sie benötigen, wenn Sie sich das erste Mal mit MySQL und/oder anderen SQL-Datenbanken auseinander setzen wollen.

Für eine spezifische Schulung bei Ihnen in-haus oder die Schulungstermine in Zürich nehmen Sie bitte mit uns Kontakt auf.

Einfache Backups mit dem FromDual Backup Manager für MySQL

Mit den Bordmitteln von MySQL ist es sehr einfach möglich, Backups falsch zu machen. Deshalb haben wir in Zusammenarbeit mit unseren Kunden den Backup Manager für MySQL entwickelt. Mit ihm können Sie folgende Backups ganz einfach ausführen:

• Logische und physische Voll-Backups
• Binary-Log-Backups
• Konfigurations-Backups
• Struktur-Backups
• Schema-Backups und
• Privilegien-Backups

Natürlich darf auch der Cleanup-Job für daily, weekly, monthly und quarterly Backups nicht fehlen. Informationen über alle Backups können in einem Backup Manager Katalog abgelegt werden. Die neue Version zeichnet sich zudem durch eine 300 - 400% höhere Backup-Performance aus. Zudem läuft Sie jetzt auch auf Mac OSX.

Für die nächsten Releases planen wir die direkte Anbindung an Netbackup (Symantec) und den Tivoli Storage Manager (IBM) sowie einen dazu passenden Recovery Manager.

Ein Backup mit dem MySQL Backup Manager kann einfach wie folgt gestartet werden:

fromdual_bman --target=root@localhost --catalog=bman@catdb --type=schema --schema=-test,-mysql --policy=daily --compression-level=3

Wenn Sie den FromDual Backup Manager kostenlos ausprobieren wollen, können Sie Ihn gerne von der FromDual Webseite herunterladen.

November ist DOAG Konferenz Zeit

Auch dieses Jahr findet die grösste Oracle User Konferenz (DOAG) in Europa wieder in Nürnberg statt. Und MySQL ist natürlich auch vertreten mit einem eigenen Vortrags-Programm.

FromDual ist mit 2 Vorträgen vertreten: Konsolidieren von MySQL Landschaften und Backup und PiTR mit MySQL. Zudem haben wir dieses Jahr das erste mal einen eigenen Stand. Kommen Sie uns doch Besuchen um sich über die neusten MySQL Trends zu informieren. Sie finden uns im 3. Stock am Stand Nummer 308 gleich neben dem Oracle und dem SuSE Stand.

MyEnv - Umgebung für MySQL

Nach intensiven Arbeiten und der Umsetzung etlicher Kundenwünschen konnten wir kürzlich MyEnv Version 1.1 freigeben. MyEnv wird eingesetzt, wenn mehrere MySQL-Instanzen gemeinsam direkt auf einem Server konsolidiert werden sollen, aber keine Virtualisierung (wie z.B. VMware, Xen oder KVM) gewünscht wird.
Mit solchen multi-Instanz-Setups kann der Bedarf an Servern im produktiven Betrieb stark reduziert werden, auch das Testen von verschiedenen MySQL-Versionen in der Qualitätssicherung wird durch MyEnv stark vereinfacht.

Das MyEnv können Sie Ihn gerne von der FromDual Webseite herunterladen.

Sollten Sie bei Ihren MySQL Konsoldierungs-Projekten Unterstützung benötigen, helfen wir Ihnen gerne mit unserer Erfahrung weiter, welche wir bei unseren Kunden gesammelt haben. Nehmen Sie doch einfach mit uns Kontakt auf!

Ihr FromDual-Team

Wenn Sie über FromDual auf dem Laufenden gehalten werden wollen, folgen Sie am besten unseren Tweets auf Twitter.

Gerne nehmen wir auch Ihre Rückmeldungen entgegen.

Wir freuen uns, von Ihnen zu hören.

Taxonomy upgrade extras: MyEnvBackupmonitoringsupportschulungdoagfromdual_brmanbrman

Herbst = Budget-Zeit

Jedes Jahr im Herbst kommt die Zeit des Budgetierens. Habe Sie Ihren Support für MySQL, MariaDB oder Percona Server für 2015 schon eingeplant?

FromDual bietet Ihnen effizienten und kostengünstigen Support in deutscher Sprache für Ihre kritischen MySQL, MariaDB und Percona Server Datenbanken sowie Ihre Galera Cluster.
Wenn Sie bei Problemen nicht mehr weiter wissen, hilft Ihnen unser Team schnell, kompetent und unkompliziert weiter, damit Sie vor Ihrem Management immer nur im besten Licht dastehen.

FromDual bietet Ihnen preiswert Office-Hour Support und 7x24-Support mit garantierten, kurzen Antwortzeiten (SLA).

Melden Sie sich bitte bei uns, wenn Sie ein Angebot wünschen.

MySQL Schulungsprogramm 2015

Benötigen Sie oder Ihre Mitarbeiter noch mehr MySQL Know-How? In unseren Schulungszentren in Essen, Berlin und Zürich können Sie Ihre Kenntnisse vertiefen und Praxiserfahrung aufbauen. Sämtliche Kurse finden Sie in unserem Schulungsprogramm 2015.

Folgende Kurse finden Sie in unserem Angebot:

• MySQL Kurse für Einsteiger (3 Tage)
• MySQL Betrieb (1 Tag)
• Architekturen und Hochverfügbarkeit (2 Tage)
• Performance Tuning (2 Tage)
• MySQL für Fortgeschrittene (5 Tage)
• Galera Cluster (2 Tage)

Neu bieten wir 2015 auch MySQL Kurse für Einsteiger an. In diesen Kursen vermitteln wir die Kenntnisse, welche Sie benötigen, wenn Sie sich das erste Mal mit MySQL und/oder anderen SQL-Datenbanken auseinander setzen wollen.

Für eine spezifische Schulung bei Ihnen in-haus oder die Schulungstermine in Zürich nehmen Sie bitte mit uns Kontakt auf.

Einfache Backups mit dem FromDual Backup Manager für MySQL

Mit den Bordmitteln von MySQL ist es sehr einfach möglich, Backups falsch zu machen. Deshalb haben wir in Zusammenarbeit mit unseren Kunden den Backup Manager für MySQL entwickelt. Mit ihm können Sie folgende Backups ganz einfach ausführen:

• Logische und physische Voll-Backups
• Binary-Log-Backups
• Konfigurations-Backups
• Struktur-Backups
• Schema-Backups und
• Privilegien-Backups

Natürlich darf auch der Cleanup-Job für daily, weekly, monthly und quarterly Backups nicht fehlen. Informationen über alle Backups können in einem Backup Manager Katalog abgelegt werden. Die neue Version zeichnet sich zudem durch eine 300 - 400% höhere Backup-Performance aus. Zudem läuft Sie jetzt auch auf Mac OSX.

Für die nächsten Releases planen wir die direkte Anbindung an Netbackup (Symantec) und den Tivoli Storage Manager (IBM) sowie einen dazu passenden Recovery Manager.

Ein Backup mit dem MySQL Backup Manager kann einfach wie folgt gestartet werden:

fromdual_bman --target=root@localhost --catalog=bman@catdb --type=schema --schema=-test,-mysql --policy=daily --compression-level=3

Wenn Sie den FromDual Backup Manager kostenlos ausprobieren wollen, können Sie Ihn gerne von der FromDual Webseite herunterladen.

November ist DOAG Konferenz Zeit

Auch dieses Jahr findet die grösste Oracle User Konferenz (DOAG) in Europa wieder in Nürnberg statt. Und MySQL ist natürlich auch vertreten mit einem eigenen Vortrags-Programm.

FromDual ist mit 2 Vorträgen vertreten: Konsolidieren von MySQL Landschaften und Backup und PiTR mit MySQL. Zudem haben wir dieses Jahr das erste mal einen eigenen Stand. Kommen Sie uns doch Besuchen um sich über die neusten MySQL Trends zu informieren. Sie finden uns im 3. Stock am Stand Nummer 308 gleich neben dem Oracle und dem SuSE Stand.

MyEnv - Umgebung für MySQL

Nach intensiven Arbeiten und der Umsetzung etlicher Kundenwünschen konnten wir kürzlich MyEnv Version 1.1 freigeben. MyEnv wird eingesetzt, wenn mehrere MySQL-Instanzen gemeinsam direkt auf einem Server konsolidiert werden sollen, aber keine Virtualisierung (wie z.B. VMware, Xen oder KVM) gewünscht wird.
Mit solchen multi-Instanz-Setups kann der Bedarf an Servern im produktiven Betrieb stark reduziert werden, auch das Testen von verschiedenen MySQL-Versionen in der Qualitätssicherung wird durch MyEnv stark vereinfacht.

Das MyEnv können Sie Ihn gerne von der FromDual Webseite herunterladen.

Sollten Sie bei Ihren MySQL Konsoldierungs-Projekten Unterstützung benötigen, helfen wir Ihnen gerne mit unserer Erfahrung weiter, welche wir bei unseren Kunden gesammelt haben. Nehmen Sie doch einfach mit uns Kontakt auf!

Ihr FromDual-Team

Wenn Sie über FromDual auf dem Laufenden gehalten werden wollen, folgen Sie am besten unseren Tweets auf Twitter.

Gerne nehmen wir auch Ihre Rückmeldungen entgegen.

Wir freuen uns, von Ihnen zu hören.

Taxonomy upgrade extras: MyEnvBackupmonitoringsupportschulungdoagfromdual_brmanbrman

Taxonomy upgrade extras: myenvBackupmonitoringsupportschulungdoagHerbst = Budget-Zeit

Jedes Jahr im Herbst kommt die Zeit des Budgetierens. Habe Sie Ihren Support für MySQL, MariaDB oder Percona Server für 2015 schon eingeplant?

FromDual bietet Ihnen effizienten und kostengünstigen Support in deutscher Sprache für Ihre kritischen MySQL, MariaDB und Percona Server Datenbanken sowie Ihre Galera Cluster.
Wenn Sie bei Problemen nicht mehr weiter wissen, hilft Ihnen unser Team schnell, kompetent und unkompliziert weiter, damit Sie vor Ihrem Management immer nur im besten Licht dastehen.

FromDual bietet Ihnen preiswert Office-Hour Support und 7x24-Support mit garantierten, kurzen Antwortzeiten (SLA).

Melden Sie sich bitte bei uns, wenn Sie ein Angebot wünschen.

MySQL Schulungsprogramm 2015

Benötigen Sie oder Ihre Mitarbeiter noch mehr MySQL Know-How? In unseren Schulungszentren in Essen, Berlin und Zürich können Sie Ihre Kenntnisse vertiefen und Praxiserfahrung aufbauen. Sämtliche Kurse finden Sie in unserem Schulungsprogramm 2015.

Folgende Kurse finden Sie in unserem Angebot:

• MySQL Kurse für Einsteiger (3 Tage)
• MySQL Betrieb (1 Tag)
• Architekturen und Hochverfügbarkeit (2 Tage)
• Performance Tuning (2 Tage)
• MySQL für Fortgeschrittene (5 Tage)
• Galera Cluster (2 Tage)

Neu bieten wir 2015 auch MySQL Kurse für Einsteiger an. In diesen Kursen vermitteln wir die Kenntnisse, welche Sie benötigen, wenn Sie sich das erste Mal mit MySQL und/oder anderen SQL-Datenbanken auseinander setzen wollen.

Für eine spezifische Schulung bei Ihnen in-haus oder die Schulungstermine in Zürich nehmen Sie bitte mit uns Kontakt auf.

Einfache Backups mit dem FromDual Backup Manager für MySQL

Mit den Bordmitteln von MySQL ist es sehr einfach möglich, Backups falsch zu machen. Deshalb haben wir in Zusammenarbeit mit unseren Kunden den Backup Manager für MySQL entwickelt. Mit ihm können Sie folgende Backups ganz einfach ausführen:

• Logische und physische Voll-Backups
• Binary-Log-Backups
• Konfigurations-Backups
• Struktur-Backups
• Schema-Backups und
• Privilegien-Backups

Natürlich darf auch der Cleanup-Job für daily, weekly, monthly und quarterly Backups nicht fehlen. Informationen über alle Backups können in einem Backup Manager Katalog abgelegt werden. Die neue Version zeichnet sich zudem durch eine 300 - 400% höhere Backup-Performance aus. Zudem läuft Sie jetzt auch auf Mac OSX.

Für die nächsten Releases planen wir die direkte Anbindung an Netbackup (Symantec) und den Tivoli Storage Manager (IBM) sowie einen dazu passenden Recovery Manager.

Ein Backup mit dem MySQL Backup Manager kann einfach wie folgt gestartet werden:

fromdual_bman --target=root@localhost --catalog=bman@catdb --type=schema --schema=-test,-mysql --policy=daily --compression-level=3

Wenn Sie den FromDual Backup Manager kostenlos ausprobieren wollen, können Sie Ihn gerne von der FromDual Webseite herunterladen.

November ist DOAG Konferenz Zeit

Auch dieses Jahr findet die grösste Oracle User Konferenz (DOAG) in Europa wieder in Nürnberg statt. Und MySQL ist natürlich auch vertreten mit einem eigenen Vortrags-Programm.

FromDual ist mit 2 Vorträgen vertreten: Konsolidieren von MySQL Landschaften und Backup und PiTR mit MySQL. Zudem haben wir dieses Jahr das erste mal einen eigenen Stand. Kommen Sie uns doch Besuchen um sich über die neusten MySQL Trends zu informieren. Sie finden uns im 3. Stock am Stand Nummer 308 gleich neben dem Oracle und dem SuSE Stand.

MyEnv - Umgebung für MySQL

Nach intensiven Arbeiten und der Umsetzung etlicher Kundenwünschen konnten wir kürzlich MyEnv Version 1.1 freigeben. MyEnv wird eingesetzt, wenn mehrere MySQL-Instanzen gemeinsam direkt auf einem Server konsolidiert werden sollen, aber keine Virtualisierung (wie z.B. VMware, Xen oder KVM) gewünscht wird.
Mit solchen multi-Instanz-Setups kann der Bedarf an Servern im produktiven Betrieb stark reduziert werden, auch das Testen von verschiedenen MySQL-Versionen in der Qualitätssicherung wird durch MyEnv stark vereinfacht.

Das MyEnv können Sie Ihn gerne von der FromDual Webseite herunterladen.

Sollten Sie bei Ihren MySQL Konsoldierungs-Projekten Unterstützung benötigen, helfen wir Ihnen gerne mit unserer Erfahrung weiter, welche wir bei unseren Kunden gesammelt haben. Nehmen Sie doch einfach mit uns Kontakt auf!

Ihr FromDual-Team

Wenn Sie über FromDual auf dem Laufenden gehalten werden wollen, folgen Sie am besten unseren Tweets auf Twitter.

Gerne nehmen wir auch Ihre Rückmeldungen entgegen.

Wir freuen uns, von Ihnen zu hören.

Taxonomy upgrade extras: temporary tablediskselectquery tuning

For processing SELECT queries MySQL needs some times the help of temporary tables. These temporary tables can be created either in memory or on disk.

The number of creations of such temporary tables can be found with the following command:

mysql> SHOW GLOBAL STATUS LIKE 'created_tmp%tables'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 4 | | Created_tmp_tables | 36 | +-------------------------+-------+
There are 2 different reasons why MySQL is creating a temporary disk table instead of a temporary memory table:

• The result is bigger than the smaller one of the MySQL variables max_heap_table_size and tmp_table_size.
• The result contains columns of type BLOB or TEXT.

In the following example we can see how the temporary disk table can be avoided without changing the column types: mysql> CREATE TABLE test ( id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY , data TEXT , type TINYINT UNSIGNED ); mysql> INSERT INTO test VALUES (NULL, 'State is green', 1), (NULL, 'State is green', 1) , (NULL, 'State is red', 3), (NULL, 'State is red', 3) , (NULL, 'State is red', 3), (NULL, 'State is orange', 2); mysql> EXPLAIN SELECT data, COUNT(*) FROM test GROUP BY data; +----+-------------+-------+------+---------------+------+---------+------+------+---------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+------+---------------+------+---------+------+------+---------------------------------+ | 1 | SIMPLE | test | ALL | NULL | NULL | NULL | NULL | 6 | Using temporary; Using filesort | +----+-------------+-------+------+---------------+------+---------+------+------+---------------------------------+ mysql> SHOW SESSION STATUS LIKE 'created_tmp%tables'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 0 | | Created_tmp_tables | 3 | +-------------------------+-------+ mysql> SELECT data, COUNT(*) FROM test GROUP BY data; +-----------------+----------+ | data | count(*) | +-----------------+----------+ | State is green | 2 | | State is orange | 1 | | State is red | 3 | +-----------------+----------+ mysql> SHOW SESSION STATUS LIKE 'created_tmp%tables'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 1 | | Created_tmp_tables | 4 | +-------------------------+-------+ mysql> SELECT SUBSTR(data, 1, 32), COUNT(*) FROM test GROUP BY SUBSTR(data, 1, 32); mysql> SHOW SESSION STATUS LIKE 'created_tmp%tables'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 1 | | Created_tmp_tables | 5 | +-------------------------+-------+

This method can be used if changing the table structure from TEXT to VARCHAR or the use of a RAM disk are not possible solutions.

Taxonomy upgrade extras: HAProxyload balancerGalera ClusterVIPvirtual IPHigh Availabilityha

After properly installing and testing a Galera Cluster we see that the set-up is not finished yet. It needs something in front of the Galera Cluster that balances the load over all nodes.
So we install a load balancer in front of the Galera Cluster. Typically nowadays HAProxy is chosen for this purpose. But then we find, that the whole Galera Cluster is still not high available in case the load balancer fails or dies. So we need a second load balancer for high availability.
But how should we properly fail-over when the HAProxy load balancer dies? For this purpose we put a Virtual IP (VIP) in front of the HAProxy load balancer pair. The Virtual IP is controlled and fail-overed with Keepalived.

Installation of HAProxy and Keepalived

First some preparations: For installing socat we need the repoforge repository:

shell> cd /tmp shell> wget http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm shell> yum localinstall rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm shell> yum update shell> yum install socat

Then we can start installing HAProxy and Keepalived:

shell> yum install haproxy keepalived shell> chkconfig haproxy on shell> chkconfig keepalived on

We can check the installed HAProxy and Keepalived versions as follows:

shell> haproxy -v HA-Proxy version 1.5.2 2014/07/12 shell> keepalived --version Keepalived v1.2.13 (10/15,2014)
Configuration of HAProxy

More details you can find in the HAProxy documentation.

shell> cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak shell> cat << _EOF >/etc/haproxy/haproxy.cfg # # /etc/haproxy/haproxy.cfg # #--------------------------------------------------------------------- # Global settings #--------------------------------------------------------------------- global # to have these messages end up in /var/log/haproxy.log you will # need to: # # 1) configure syslog to accept network log events. This is done # by adding the '-r' option to the SYSLOGD_OPTIONS in # /etc/sysconfig/syslog # # 2) configure local2 events to go to the /var/log/haproxy.log # file. A line like the following can be added to # /etc/sysconfig/syslog # # local2.* /var/log/haproxy.log # log 127.0.0.1 local2 chroot /var/lib/haproxy pidfile /var/run/haproxy.pid maxconn 1020 # See also: ulimit -n user haproxy group haproxy daemon # turn on stats unix socket stats socket /var/lib/haproxy/stats.sock mode 600 level admin stats timeout 2m #--------------------------------------------------------------------- # common defaults that all the 'frontend' and 'backend' sections will # use if not designated in their block #--------------------------------------------------------------------- defaults mode tcp log global option dontlognull option redispatch retries 3 timeout queue 45s timeout connect 5s timeout client 1m timeout server 1m timeout check 10s maxconn 1020 #--------------------------------------------------------------------- # HAProxy statistics backend #--------------------------------------------------------------------- listen haproxy-monitoring *:80 mode http stats enable stats show-legends stats refresh 5s stats uri / stats realm Haproxy\ Statistics stats auth monitor:AdMiN123 stats admin if TRUE frontend haproxy1 # change on 2nd HAProxy bind *:3306 default_backend galera-cluster backend galera-cluster balance roundrobin server nodeA 192.168.1.61:5201 maxconn 151 check server nodeB 192.168.1.61:5202 maxconn 151 check server nodeC 192.168.1.61:5203 maxconn 151 check _EOF
Starting and testing HAProxy

The HAProxy can be started as follows:

shell> service haproxy start

and then be checked either over the socket:

shell> socat /var/lib/haproxy/stats.sock readline prompt > show info > show stat > help

or over your favourite web browser entering the username and password (monitor:AdMiN123) specified in the configuration file above:

To check the application over the load balancer we can run the following command:

shell> mysql --user=app --password=secret --host=192.168.1.38 --port=3306 --exec="SELECT @@wsrep_node_name;" +-------------------+ | @@wsrep_node_name | +-------------------+ | Node C | +-------------------+ shell> mysql --user=app --password=secret --host=192.168.1.38 --port=3306 --exec="SELECT @@wsrep_node_name;" +-------------------+ | @@wsrep_node_name | +-------------------+ | Node A | +-------------------+ shell> mysql --user=app --password=secret --host=192.168.1.38 --port=3306 --exec="SELECT @@wsrep_node_name;" +-------------------+ | @@wsrep_node_name | +-------------------+ | Node B | +-------------------+
Configuration a Virtual IP (VIP) with Keepalived

Now we have 2 HAProxy load balancers. But what happens if one of them fails. Then we do not want to reconfigure our application to work properly again. The fail-over should happen automatically. For this we need a Virtual IP which should automatically fail-over.

More details you can find in the Keepalived documentation and the keepalived user guide.

shell> cp /etc/keepalived/keepalived.conf /etc/keepalived/keepalived.conf.bak cat << _EOF >/etc/keepalived/keepalived.conf # # /etc/keepalived/keepalived.conf # global_defs { notification_email { remote-dba@fromdual.com root@localhost } # Change email from on lb2: notification_email_from lb1@haproxy1 router_id HAPROXY } vrrp_script chk_haproxy { script "killall -0 haproxy" interval 2 weight 2 } vrrp_instance GALERA_VIP { interface eth1 virtual_router_id 42 # Higher priority on other node priority 101 # 102 advert_int 1 # notify "/usr/local/bin/VRRP-notification.sh" virtual_ipaddress { 192.168.1.99/32 dev eth1 } track_script { chk_haproxy } authentication { auth_type PASS auth_pass secret } } _EOF
Starting and testing Keepalived

To test the keepalived we can run the following command:

shell> keepalived -f /etc/keepalived/keepalived.conf --dont-fork --log-console --log-detail ^C

To finally start it the following command will serve:

shell> service keepalived start

To check the Virtual IP the following command will help:

shell> ip addr show eth1

And then we can check our application over the VIP:

shell> mysql --user=app --password=secret --host=192.168.1.99 --port=3306 --exec="SELECT @@wsrep_node_name;"
Literature

• Brian Seitzer: Redundant Load Balancers – HAProxy and Keepalived

Am 5. und 6. Februar 2015 dreht sich wortwörtlich "from Noon to Noon" alles rund um die Oracle Datenbank und MySQL-Technologien. Von 12 bis 12 Uhr erfahren Sie in Nürnberg in spannenden Kurzvorträgen und Paneldiskussionen viele Praxistipps und -tricks aus erster Hand. Bei den interaktiven Sessions heisst es: Ärmel hochkrempeln und mitmachen!

Jetzt anmelden unter: Noon2Noon.

Am 5. und 6. Februar 2015 dreht sich wortwörtlich "from Noon to Noon" alles rund um die Oracle Datenbank und MySQL-Technologien. Von 12 bis 12 Uhr erfahren Sie in Nürnberg in spannenden Kurzvorträgen und Paneldiskussionen viele Praxistipps und -tricks aus erster Hand. Bei den interaktiven Sessions heisst es: Ärmel hochkrempeln und mitmachen!

Jetzt anmelden unter: Noon2Noon.

Am 5. und 6. Februar 2015 dreht sich wortwörtlich "from Noon to Noon" alles rund um die Oracle Datenbank und MySQL-Technologien. Von 12 bis 12 Uhr erfahren Sie in Nürnberg in spannenden Kurzvorträgen und Paneldiskussionen viele Praxistipps und -tricks aus erster Hand. Bei den interaktiven Sessions heisst es: Ärmel hochkrempeln und mitmachen!

Jetzt anmelden unter: Noon2Noon.

Taxonomy upgrade extras: galerareplicationDDLTOIRSU

We have recently seen a case where the following command was executed on a Galera Cluster node:

SQL> GRANT SUPER ON userdb.* TO root@127.0.0.111; ERROR 1221 (HY000): Incorrect usage of DB GRANT and GLOBAL PRIVILEGES
2014-12-09 14:53:55 7457 [Warning] Did not write failed 'GRANT SUPER ON userdb.* TO root@127.0.0.111' into binary log while granting/revoking privileges in databases. 2014-12-09 14:53:55 7457 [ERROR] Slave SQL: Error 'Incorrect usage of DB GRANT and GLOBAL PRIVILEGES' on query. Default database: ''. Query: 'GRANT SUPER ON userdb.* TO root@127.0.0.111', Error_code: 1221 2014-12-09 14:53:55 7457 [Warning] WSREP: RBR event 1 Query apply warning: 1, 17 2014-12-09 14:53:55 7457 [Warning] WSREP: Ignoring error for TO isolated action: source: c5e54ef5-7faa-11e4-97b0-5e5c695f08a5 version: 3 local: 0 state: APPLYING flags: 65 conn_id: 4 trx_id: -1 seqnos (l: 4, g: 17, s: 15, d: 15, ts: 113215863294782)

According to the error message it looks like this command is done in Total Order Isolation (TOI) mode during the Rolling Schema Upgrade (RSU).

Only on the nodes which did NOT receive this wrong command the error log message was written and further they have received a GRA_*.log file.

Analysis of the GRA_*.log (failed transactions) files:

hexdump -C GRA_2_16.log 00000000 f3 fe 86 54 02 53 14 00 00 76 00 00 00 76 00 00 |...T.S...v...v..| 00000010 00 00 00 04 00 00 00 00 00 00 00 00 00 00 2a 00 |..............*.| 00000020 00 00 00 00 00 01 00 00 00 40 00 00 00 00 06 03 |.........@......| 00000030 73 74 64 04 21 00 21 00 08 00 0b 04 72 6f 6f 74 |std.!.!.....root| 00000040 09 6c 6f 63 61 6c 68 6f 73 74 00 67 72 61 6e 74 |.localhost.grant| 00000050 20 53 55 50 45 52 20 6f 6e 20 75 73 65 72 64 62 | SUPER on userdb| 00000060 2e 2a 20 74 6f 20 72 6f 6f 74 40 31 32 37 2e 30 |.* to root@127.0| 00000070 2e 30 2e 31 31 31 |.0.111 |
dd if=bin-log.000001 of=binlog.header bs=1 count=120 cat binlog.header GRA_2_17.log > GRA_2_17.binlog_events mysqlbinlog GRA_2_17.binlog_events ... # at 120 #141209 15:04:54 server id 5201 end_log_pos 118 CRC32 0x3432312e Query thread_id=45 exec_time=0 error_code=0 SET TIMESTAMP=1418133894/*!*/; SET @@session.pseudo_thread_id=4/*!*/; SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/; SET @@session.sql_mode=1073741824/*!*/; SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/; /*!\C utf8 *//*!*/; SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/; SET @@session.lc_time_names=0/*!*/; SET @@session.collation_database=DEFAULT/*!*/; grant SUPER on userdb.* to root@127.0.0.111 /*!*/; DELIMITER ; # End of log file ROLLBACK /* added by mysqlbinlog */; /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/; /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

It further looks like this command was issues by Connection ID number 4: conn_id: 4.

Sometimes, MySQL tablespace file(s) might be deleted by mistake, e.g. delete the shared tablespace (ibdata1) or an individual tablespace (table_name.ibd).

In this post I will show you how to recover those files (on Linux OS) having only one condition, MySQL service should still be running. If MySQL service stopped after deleting that file, this method will not work, so it is extremely important to act as quick as possible to avoid data loss.

The following is a simple table creation (innodb_file_per_table is enabled) and the records count inside that table:

SQL> SHOW CREATE TABLE t\G *************************** 1. row *************************** Table: t Create Table: CREATE TABLE `t` ( `id` int(11) NOT NULL AUTO_INCREMENT, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=23 DEFAULT CHARSET=latin1 1 row in set (0.00 sec) SQL> SELECT COUNT(*) FROM t; +----------+ | COUNT(*) | +----------+ | 22 | +----------+ 1 row in set (0.02 sec)

Now, lets delete the individual tablespace for that table:

shell> rm -rf /var/lib/mysql/test/t.ibd

At this time, we can still select and modify that table!!

SQL> INSERT INTO t VALUES (NULL); Query OK, 1 row affected (0.00 sec) SQL> SELECT COUNT(*) FROM t; +----------+ | COUNT(*) | +----------+ | 23 | +----------+ 1 row in set (0.00 sec)

To be more accurate, rm does not actually delete the file, rather it removes the directory entry pointing to the file's inode. The inode - and in consequence the file - will be removed only if this is the last reference, but as long as the MySQL server process has the file opened, there is another reference which is the open file handle (that's why the "mysqld" server process must still be running).

To list the opened files we can use the Linux command lsof (we filter the output to get only the deleted tablespace information):

shell> lsof |grep t.ibd COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME mysqld 11401 mysql 25uW REG 7,0 98304 1010691 /var/lib/mysql/test/t.ibd (deleted)

The file has a tag of (deleted) which means that the directory entry pointing to the file's inode was deleted but there is another reference(s) to that inode, otherwise it won't be listed by the above command.
Now the question is, how can we get the on-disk path to that opened file if the directory entry was removed?

We can use the "/proc" interface to the running processes and their file handles by the following formula:

• File path = /proc/PID/fd/FD-number

According to the above formula and using the output of the "lsof" command, the file we just deleted is located here:

shell> ll /proc/11401/fd/25 lrwx------ 1 mysql mysql 64 Oct 28 16:14 /proc/11401/fd/25 -> /var/lib/mysql/test/t.ibd (deleted)

To make sure that this is the on-disk path for the file we deleted, check the reference: it still points to the original path.

How can we recover that file??

• First, we should make sure that no other queries are modifying that table: SQL> LOCK TABLE t READ; Query OK, 0 rows affected (0.00 sec)
• Then we copy the data blocks (/proc/11401/fd/25) to a new file (we use the original file path) and change the ownership to the MySQL system user (mysql): shell> cp /proc/11401/fd/25 /var/lib/mysql/test/t.ibd shell> chown mysql:mysql /var/lib/mysql/test/t.ibd
• Restart MySQL service (if we didn't restart MySQL service directly after recovering the tablespace all changes on that table will still be redirected to the open file handle not the just recovered copy and thus will be lost after the restart): shell> service mysql restart ..... SUCCESS! ..... SUCCESS!
• The tablespace is now recovered and we can modify the table normally: SQL> SELECT COUNT(*) FROM t; +----------+ | COUNT(*) | +----------+ | 23 | +----------+ 1 row in set (0.00 sec) SQL> INSERT INTO t VALUES (NULL); Query OK, 1 row affected (0.00 sec) SQL> INSERT INTO t VALUES (NULL); Query OK, 1 row affected (0.00 sec) SQL> select COUNT(*) from t; +----------+ | COUNT(*) | +----------+ | 25 | +----------+ 1 row in set (0.00 sec)

Notes:

• We can use the same procedures above to recover the shared tablespace (ibdata1) but we should lock all tables before the recovery process by using the SQL command "FLUSH TABLES WITH READ LOCK;"
• If the MySQL server had to deal with more files (.frm, .ibd, .MYI, .MYD, ...) than its "open_file_limit", it might happen that it will close this handle. In that case, the file will also cease to exist, even though the process is still running and that's why it is extremely important to act as quick as possible.
• The same procedure can be used to recover MyISAM files (.MYI and .MYD) but note that the file handle will be released if "FLUSH TABLES;" SQL command was executed.
• The same procedure can be used as well to recover binary logs, general logs, ... etc but note that the file handle will be released if "FLUSH LOGS;" SQL command was executed.
• This method can be used to recover any deleted file on Linux not only MySQL files but if the file's inode has other references (lsof).

Real life case:

One of our customers was enabling the general query log on his production system, he noticed that the file was continuously growing and to not to consume the available free disk space on his server he removed that file by "rm /path/to/general_query.log". However, the available free space was still being consumed while he couldn't see the general log file. The customer thought that the file was deleted but in fact, the file handle was still opened by MySQL server process.
To get the problem solved we only issued the SQL command "FLUSH LOGS;" - which the customer should have issued after removing the file - then the file handle was closed, thus the inode was deleted and the consumed disk space freed back to the system.

Taxonomy upgrade extras: innodbtablespaceibdata1general query log

Sometimes, MySQL tablespace file(s) might be deleted by mistake, e.g. delete the shared tablespace (ibdata1) or an individual tablespace (table_name.ibd).

In this post I will show you how to recover those files (on Linux OS) having only one condition, MySQL service should still be running. If MySQL service stopped after deleting that file, this method will not work, so it is extremely important to act as quick as possible to avoid data loss.

The following is a simple table creation (innodb_file_per_table is enabled) and the records count inside that table:

SQL> SHOW CREATE TABLE t\G *************************** 1. row *************************** Table: t Create Table: CREATE TABLE `t` ( `id` int(11) NOT NULL AUTO_INCREMENT, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=23 DEFAULT CHARSET=latin1 1 row in set (0.00 sec) SQL> SELECT COUNT(*) FROM t; +----------+ | COUNT(*) | +----------+ | 22 | +----------+ 1 row in set (0.02 sec)

Now, lets delete the individual tablespace for that table:

shell> rm -rf /var/lib/mysql/test/t.ibd

At this time, we can still select and modify that table!!

SQL> INSERT INTO t VALUES (NULL); Query OK, 1 row affected (0.00 sec) SQL> SELECT COUNT(*) FROM t; +----------+ | COUNT(*) | +----------+ | 23 | +----------+ 1 row in set (0.00 sec)

To be more accurate, rm does not actually delete the file, rather it removes the directory entry pointing to the file's inode. The inode - and in consequence the file - will be removed only if this is the last reference, but as long as the MySQL server process has the file opened, there is another reference which is the open file handle (that's why the "mysqld" server process must still be running).

To list the opened files we can use the Linux command lsof (we filter the output to get only the deleted tablespace information):

shell> lsof |grep t.ibd COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME mysqld 11401 mysql 25uW REG 7,0 98304 1010691 /var/lib/mysql/test/t.ibd (deleted)

The file has a tag of (deleted) which means that the directory entry pointing to the file's inode was deleted but there is another reference(s) to that inode, otherwise it won't be listed by the above command.
Now the question is, how can we get the on-disk path to that opened file if the directory entry was removed?

We can use the "/proc" interface to the running processes and their file handles by the following formula:

• File path = /proc/PID/fd/FD-number

According to the above formula and using the output of the "lsof" command, the file we just deleted is located here:

shell> ll /proc/11401/fd/25 lrwx------ 1 mysql mysql 64 Oct 28 16:14 /proc/11401/fd/25 -> /var/lib/mysql/test/t.ibd (deleted)

To make sure that this is the on-disk path for the file we deleted, check the reference: it still points to the original path.

How can we recover that file??

• First, we should make sure that no other queries are modifying that table: SQL> LOCK TABLE t READ; Query OK, 0 rows affected (0.00 sec)
• Then we copy the data blocks (/proc/11401/fd/25) to a new file (we use the original file path) and change the ownership to the MySQL system user (mysql): shell> cp /proc/11401/fd/25 /var/lib/mysql/test/t.ibd shell> chown mysql:mysql /var/lib/mysql/test/t.ibd
• Restart MySQL service (if we didn't restart MySQL service directly after recovering the tablespace all changes on that table will still be redirected to the open file handle not the just recovered copy and thus will be lost after the restart): shell> service mysql restart ..... SUCCESS! ..... SUCCESS!
• The tablespace is now recovered and we can modify the table normally: SQL> SELECT COUNT(*) FROM t; +----------+ | COUNT(*) | +----------+ | 23 | +----------+ 1 row in set (0.00 sec) SQL> INSERT INTO t VALUES (NULL); Query OK, 1 row affected (0.00 sec) SQL> INSERT INTO t VALUES (NULL); Query OK, 1 row affected (0.00 sec) SQL> select COUNT(*) from t; +----------+ | COUNT(*) | +----------+ | 25 | +----------+ 1 row in set (0.00 sec)

Notes:

• We can use the same procedures above to recover the shared tablespace (ibdata1) but we should lock all tables before the recovery process by using the SQL command "FLUSH TABLES WITH READ LOCK;"
• If the MySQL server had to deal with more files (.frm, .ibd, .MYI, .MYD, ...) than its "open_file_limit", it might happen that it will close this handle. In that case, the file will also cease to exist, even though the process is still running and that's why it is extremely important to act as quick as possible.
• The same procedure can be used to recover MyISAM files (.MYI and .MYD) but note that the file handle will be released if "FLUSH TABLES;" SQL command was executed.
• The same procedure can be used as well to recover binary logs, general logs, ... etc but note that the file handle will be released if "FLUSH LOGS;" SQL command was executed.
• This method can be used to recover any deleted file on Linux not only MySQL files but if the file's inode has other references (lsof).

Real life case:

One of our customers was enabling the general query log on his production system, he noticed that the file was continuously growing and to not to consume the available free disk space on his server he removed that file by "rm /path/to/general_query.log". However, the available free space was still being consumed while he couldn't see the general log file. The customer thought that the file was deleted but in fact, the file handle was still opened by MySQL server process.
To get the problem solved we only issued the SQL command "FLUSH LOGS;" - which the customer should have issued after removing the file - then the file handle was closed, thus the inode was deleted and the consumed disk space freed back to the system.

Sometimes, MySQL tablespace file(s) might be deleted by mistake, e.g. delete the shared tablespace (ibdata1) or an individual tablespace (table_name.ibd).

In this post I will show you how to recover those files (on Linux OS) having only one condition, MySQL service should still be running. If MySQL service stopped after deleting that file, this method will not work, so it is extremely important to act as quick as possible to avoid data loss.

The following is a simple table creation (innodb_file_per_table is enabled) and the records count inside that table:

SQL> SHOW CREATE TABLE t\G *************************** 1. row *************************** Table: t Create Table: CREATE TABLE `t` ( `id` int(11) NOT NULL AUTO_INCREMENT, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=23 DEFAULT CHARSET=latin1 1 row in set (0.00 sec) SQL> SELECT COUNT(*) FROM t; +----------+ | COUNT(*) | +----------+ | 22 | +----------+ 1 row in set (0.02 sec)

Now, lets delete the individual tablespace for that table:

shell> rm -rf /var/lib/mysql/test/t.ibd

At this time, we can still select and modify that table!!

SQL> INSERT INTO t VALUES (NULL); Query OK, 1 row affected (0.00 sec) SQL> SELECT COUNT(*) FROM t; +----------+ | COUNT(*) | +----------+ | 23 | +----------+ 1 row in set (0.00 sec)

To be more accurate, rm does not actually delete the file, rather it removes the directory entry pointing to the file's inode. The inode - and in consequence the file - will be removed only if this is the last reference, but as long as the MySQL server process has the file opened, there is another reference which is the open file handle (that's why the "mysqld" server process must still be running).

To list the opened files we can use the Linux command lsof (we filter the output to get only the deleted tablespace information):

shell> lsof |grep t.ibd COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME mysqld 11401 mysql 25uW REG 7,0 98304 1010691 /var/lib/mysql/test/t.ibd (deleted)

The file has a tag of (deleted) which means that the directory entry pointing to the file's inode was deleted but there is another reference(s) to that inode, otherwise it won't be listed by the above command.
Now the question is, how can we get the on-disk path to that opened file if the directory entry was removed?

We can use the "/proc" interface to the running processes and their file handles by the following formula:

• File path = /proc/PID/fd/FD-number

According to the above formula and using the output of the "lsof" command, the file we just deleted is located here:

shell> ll /proc/11401/fd/25 lrwx------ 1 mysql mysql 64 Oct 28 16:14 /proc/11401/fd/25 -> /var/lib/mysql/test/t.ibd (deleted)

To make sure that this is the on-disk path for the file we deleted, check the reference: it still points to the original path.

How can we recover that file??

• First, we should make sure that no other queries are modifying that table: SQL> LOCK TABLE t READ; Query OK, 0 rows affected (0.00 sec)
• Then we copy the data blocks (/proc/11401/fd/25) to a new file (we use the original file path) and change the ownership to the MySQL system user (mysql): shell> cp /proc/11401/fd/25 /var/lib/mysql/test/t.ibd shell> chown mysql:mysql /var/lib/mysql/test/t.ibd
• Restart MySQL service (if we didn't restart MySQL service directly after recovering the tablespace all changes on that table will still be redirected to the open file handle not the just recovered copy and thus will be lost after the restart): shell> service mysql restart ..... SUCCESS! ..... SUCCESS!
• The tablespace is now recovered and we can modify the table normally: SQL> SELECT COUNT(*) FROM t; +----------+ | COUNT(*) | +----------+ | 23 | +----------+ 1 row in set (0.00 sec) SQL> INSERT INTO t VALUES (NULL); Query OK, 1 row affected (0.00 sec) SQL> INSERT INTO t VALUES (NULL); Query OK, 1 row affected (0.00 sec) SQL> select COUNT(*) from t; +----------+ | COUNT(*) | +----------+ | 25 | +----------+ 1 row in set (0.00 sec)

Notes:

• We can use the same procedures above to recover the shared tablespace (ibdata1) but we should lock all tables before the recovery process by using the SQL command "FLUSH TABLES WITH READ LOCK;"
• If the MySQL server had to deal with more files (.frm, .ibd, .MYI, .MYD, ...) than its "open_file_limit", it might happen that it will close this handle. In that case, the file will also cease to exist, even though the process is still running and that's why it is extremely important to act as quick as possible.
• The same procedure can be used to recover MyISAM files (.MYI and .MYD) but note that the file handle will be released if "FLUSH TABLES;" SQL command was executed.
• The same procedure can be used as well to recover binary logs, general logs, ... etc but note that the file handle will be released if "FLUSH LOGS;" SQL command was executed.
• This method can be used to recover any deleted file on Linux not only MySQL files but if the inode files have other references (lsof).

Real life case:

One of our customers was enabling the general query log on his production system, he noticed that the file was continuously growing and to not to consume the available free disk space on his server he removed that file by "rm /path/to/general_query.log". However, the available free space was still being consumed while he couldn't see the general log file. The customer thought that the file was deleted but in fact, the file handle was still opened by MySQL server process.
To get the problem solved we only issued the SQL command "FLUSH LOGS;" - which the customer should have issued after removing the file - then the file handle was closed, thus the inode was deleted and the consumed disk space freed back to the system.

Global Transaction ID (GTID) is one of the major features that were introduced in MySQL 5.6 which provides a lot of benefits.
I have talked about the GTID concept, implementation and possible troubleshooting at Percona Live London 2014, you can download the slides from our presentations repository or from my session at Percona Live.

On the other hand, there are some important things you should consider before deploying GTID in production, I'm going to list them here in this blog post.

Table of Content

• Migration to GTID replication
• Non transactionally safe statement will raise errors now
• MySQL Performance in GTID
• mysql_upgrade script
• Errant transactions!
• Filtration on the slave
• Conclusion

Migration to GTID replication

It is required to shutdown MySQL service on all servers in the replication setup in order to perform the migration from classic replication (based on binary logs information) to the transaction-based (GTID) replication which means that the migration process requires downtime.

The online migration to GTID replication is not yet available.
Facebook and Booking.com provided some MySQL patches for this, but they are not yet contained in Oracle's binaries.
So, if you can't afford a downtime during the migration process, then you might not be able to make the change.

Non transactionally safe statement will raise errors now

It is required to enable the system variable (enforce_gtid_consistency) on all servers inside the GTID replication setup which prevent executing the non transactionally safe statements (check GTID restrictions) like:

• CREATE TABLE .. SELECT.
• CREATE TEMPORARY TABLE (inside a transaction).
• Statements that update non-transactional tables inside a transaction.

So, you will have to fix your application first if it contains any of the above statements before using GTID replication.

MySQL Performance in GTID

It is required to enable the variables (bin_log and log_slave_updates) on - at least - the slave servers which affects the performance on those slaves negatively.

So, the performance should be tested very well before the production migration to GTID replication.

mysql_upgrade script

The mysql_upgrade script's problem when executed on a server having gtid_mode=on has been fixed since MySQL 5.6.7, but it is still not recommended to execute mysql_upgrade when gtid_mode=on as it might change system tables that is using MyISAM, which is non transactional.

Errant transactions! Transactions which are executed on a slave apart from the replication transactions (i.e. not executed on the master) are called "Errant transactions", those transactions cause trouble if that slave later is promoted to be a new master in the a fail-over process.
Once the other slaves connect to the new master, they send the value of gtid_executed and the master in turn checks those values, compares it with its own gtid_executed set and sends back all missing transactions (the errant transactions) to the slaves which leads to one of the following problems:

• If those transactions still exist in the new master's binary log files, they will be replicated to the other slave which was not intentional when those were executed only on the slave (new master).
• If those transactions do no longer exist in the new master's binary log file, the replication will break on all slaves.

How to avoid such problem?

• Choose some slaves to be possible candidates for promotion in case of fail-over. Thus, stand alone transactions (which are not coming from the master) should NOT be executed there.
• Use one of the MySQL utilities (mysqlfailover or mysqlrpladmin) to find out if there are any errant transactions on the slave before the promotion or not.

Filtration on the slave

In some cases we might need to make filtration to the replication on the slave(s) i.e. not all tables' or databases' changes are propagated to the slave by using the system variables (replicate_ignore_db or replicate_ignore_table). When the slave receives transactions from the master which modify those ignored tables or databases, it simply skips executing them and when the slave restarted it sends the gtid_excuted to the master and the master finds the missing transactions (those for the ignored tables or databases) and sends them back to the slave.

Again, that leads to one of the following two conditions:

• If those transactions still exist in the master's binary log files, then no problem as the slave will skip executing them again!!
• If those transactions are no longer there in the master's binary log files, the replication will break on the slave.

Well, the above problem is supposed to be fixed in MySQL 5.6.18 (Bug #70048) The fix is injecting empty transactions on the slave for those ones modifying ignored tables or databases instead of just skipping them, and when the slave restarted they won't be sent back again from the master.

I listed the above problem although it should be fixed now because I want to mention that having MySQL always updated to the recent release is a good practice to avoid such problems and to get the most bug fixes.

Conclusion

The following are the main things which should be considered before using GTID:

• Migration from classic replication to transaction-based (GTID) replication requires downtime.
• Non-transactionally safe statements will not be executed in GTID replication.
• MySQL performance is a little bit slower in GTID replication, especially, on the slaves.
• mysql_upgrade script might cause troubles on a server having GTID_MODE=ON and it should be tested first.
• Errant transactions might break the replication in the fail-over process, thus, planning slaves for promotion will avoid falling in such cases.
• Some GTID bugs are fixed now (like slave filtration issue), thus MySQL server should be updated to the latest version once there is a new release.
• New bugs are expected to be discovered, so the application should be tested very well with GTID before performing the migration on production.

Taxonomy upgrade extras: GTIDreplication

Global Transaction ID (GTID) is one of the major features that were introduced in MySQL 5.6 which provides a lot of benefits.
I have talked about the GTID concept, implementation and possible troubleshooting at Percona Live London 2014, you can download the slides from our presentations repository or from my session at Percona Live.

On the other hand, there are some important things you should consider before deploying GTID in production, I'm going to list them here in this blog post.

Table of Content

• Migration to GTID replication
• Non transactionally safe statement will raise errors now
• MySQL Performance in GTID
• mysql_upgrade script
• Errant transactions!
• Filtration on the slave
• Conclusion

Migration to GTID replication

It is required to shutdown MySQL service on all servers in the replication setup in order to perform the migration from classic replication (based on binary logs information) to the transaction-based (GTID) replication which means that the migration process requires downtime.

The online migration to GTID replication is not yet available.
Facebook and Booking.com provided some MySQL patches for this, but they are not yet contained in Oracle's binaries.
So, if you can't afford a downtime during the migration process, then you might not be able to make the change.

Non transactionally safe statement will raise errors now

It is required to enable the system variable (enforce_gtid_consistency) on all servers inside the GTID replication setup which prevent executing the non transactionally safe statements (check GTID restrictions) like:

• CREATE TABLE .. SELECT.
• CREATE TEMPORARY TABLE (inside a transaction).
• Statements that update non-transactional tables inside a transaction.

So, you will have to fix your application first if it contains any of the above statements before using GTID replication.

MySQL Performance in GTID

It is required to enable the variables (bin_log and log_slave_updates) on - at least - the slave servers which affects the performance on those slaves negatively.

So, the performance should be tested very well before the production migration to GTID replication.

mysql_upgrade script

The mysql_upgrade script's problem when executed on a server having gtid_mode=on has been fixed since MySQL 5.6.7, but it is still not recommended to execute mysql_upgrade when gtid_mode=on as it might change system tables that is using MyISAM, which is non transactional.

Errant transactions! Transactions which are executed on a slave apart from the replication transactions (i.e. not executed on the master) are called "Errant transactions", those transactions cause trouble if that slave later is promoted to be a new master in the a fail-over process.
Once the other slaves connect to the new master, they send the value of gtid_executed and the master in turn checks those values, compares it with its own gtid_executed set and sends back all missing transactions (the errant transactions) to the slaves which leads to one of the following problems:

• If those transactions still exist in the new master's binary log files, they will be replicated to the other slave which was not intentional when those were executed only on the slave (new master).
• If those transactions do no longer exist in the new master's binary log file, the replication will break on all slaves.

How to avoid such problem?

• Choose some slaves to be possible candidates for promotion in case of fail-over. Thus, stand alone transactions (which are not coming from the master) should NOT be executed there.
• Use one of the MySQL utilities (mysqlfailover or mysqlrpladmin) to find out if there are any errant transactions on the slave before the promotion or not.

Filtration on the slave

In some cases we might need to make filtration to the replication on the slave(s) i.e. not all tables' or databases' changes are propagated to the slave by using the system variables (replicate_ignore_db or replicate_ignore_table). When the slave receives transactions from the master which modify those ignored tables or databases, it simply skips executing them and when the slave restarted it sends the gtid_excuted to the master and the master finds the missing transactions (those for the ignored tables or databases) and sends them back to the slave.

Again, that leads to one of the following two conditions:

• If those transactions still exist in the master's binary log files, then no problem as the slave will skip executing them again!!
• If those transactions are no longer there in the master's binary log files, the replication will break on the slave.

Well, the above problem is supposed to be fixed in MySQL 5.6.18 (Bug #70048) The fix is injecting empty transactions on the slave for those ones modifying ignored tables or databases instead of just skipping them, and when the slave restarted they won't be sent back again from the master.

I listed the above problem although it should be fixed now because I want to mention that having MySQL always updated to the recent release is a good practice to avoid such problems and to get the most bug fixes.

Conclusion

The following are the main things which should be considered before using GTID:

• Migration from classic replication to transaction-based (GTID) replication requires downtime.
• Non-transactionally safe statements will not be executed in GTID replication.
• MySQL performance is a little bit slower in GTID replication, especially, on the slaves.
• mysql_upgrade script might cause troubles on a server having GTID_MODE=ON and it should be tested first.
• Errant transactions might break the replication in the fail-over process, thus, planning slaves for promotion will avoid falling in such cases.
• Some GTID bugs are fixed now (like slave filtration issue), thus MySQL server should be updated to the latest version once there is a new release.
• New bugs are expected to be discovered, so the application should be tested very well with GTID before performing the migration on production.

Taxonomy upgrade extras: GTIDreplication