You are here

Sammlung von Newsfeeds

Newsletter Summer 2011

FromDual.en - Sun, 2011-06-19 16:12
Taxonomy upgrade extras: englishnewsletter

Dear MySQL and MariaDB User,

With this Newsletter you receive the News about FromDual for Summer 2011.


Sie können diesen Newsletter auch auf deutsch lesen oder sich den deutschprachigen Newsletter. abonnieren.

Topics Basic- and Silver-Support for MySQL and MariaDB

End of last year Oracle/MySQL has dropped the low cost Basic- and Silver-Support contracts from their service portfolio. The official justification was: Minor demand from the customers.

Numerous MySQL users since then have inquired this Support offerings with FromDual. We can offer you now the following Support Services for MySQL:

  • Our Best Effort Support (BES) for EUR 990.-/year as an alternative to MySQL Basic and
  • Our Business Hour Support (5 x 9, BHS) for EUR 1'990.-/year as an alternative to MySQL Silver.

Naturally we offer you as well Support in the high-end range for MySQL and MariaDB with our All Day Long Support (ADLS, 7x16) and our All around the Clock Support (7 x 24, AatCS).

More information you will find at 24x7 Premium Support.

If you have any question about our Support Offerings please let us know by sending us an e-mail to the following address and we will contact you asap...

FromDual Performance Monitor for MySQL with more InnoDB Graphs

In the middle of June FromDual has published its newest Release of its MySQL Performance Monitor. Because of many requests from our customers we have improved the InnoDB module and increased the number of InnoDB Graphs.

Some sample Graphs you can find at InnoDB Graphs for MySQL Performance Monitor.

Summer vacation without a MySQL DBA?

If your MySQL DBA is leaving you for its well-deserved summer holidays, you do not have to prohibit him his holidays anymore! We take-over his work during his summer vacation...

More information about our Remote-DBA services you will find on our website.

Upcoming Trainings and Workshops
  • On August 20 and 21 in St. Augustin (Germany) the FrOSCon 6 / 2011 is taking place. We will be present with our presentation MySQL Performance Tuning (in German). If you would like to know how we do Performance Tuning with our customers, come an visit us!
  • From August 15th to 17th we will have an Advanced MySQL Developer Workshop with Citrus in Helsinki. The workshop will be held in English.
  • At the /ch/open Workshop Days 2011 we will have on Thursday, September 15 our Workshop MySQL High-Availability with an active/passive Failover-Cluster. All those who were last year in the wrong Workshop have this year the chance to visit the right one...
  • On October 24 and 25 in the Linux-Hotel in Essen a MySQL Cluster course is taking place. You can apply directly at the Linux Hotel.
Technical Information

We have compiled the following interesting technical information for you:

If you have missed our presentations HA Architectures with MySQL or HandlerSocket and similar Technologies - NoSQL for MySQL at the DOAG SIG's you can find the slides as PDF at Presentations.

German speaking MySQL User Group (DMySQLAG) founded

Beginning of June the German speaking MySQL User Group (DMySQLAG) was founded.

This association advocates for:

  • the information of the use, the handling and the experience with MySQL and development in the MySQL Eco-System as well as systems which use MySQL.
  • the exchange of experience between MySQL users about MySQL and other systems.
  • the Advice and Cooperation with Oracle and vendors of other systems.
  • the submission of suggestions of the members to Oracle and vendors of other systems.

The intention of the German speaking MySQL User Group is to be a platform for MySQL User from Germany, Austria and Switzerland. To get a high enough weight for Austria and Switzerland we hope for a high number of registrations of these two countries!

Member fee:

  • Students: free
  • Single-membership: EUR 100.-/a
  • Companies up to 500 employees: EUR 200.-/a
  • Companies above 500 employees: EUR 300.-/a
News about MySQL
  • In May 2011 MySQL has released version 5.5.13 and 5.5.14 and fixed many (about 50) bugs in InnoDB and Replication.
  • Several new releases for MySQL Cluster 7.0, 7.1 and 7.2 are in the pipeline and will be possibly released in next few weeks.
  • MariaDB 5.2.6 and 5.2.7 were released in May and June.
  • Galera, a synchronous Multi-Master-Replication for MySQL advances with v0.8 in big steps to a stable release and seems to be production ready soon. It is worth to give this product a try!

If you want to stay tuned to our information, follow our Tweets on Twitter.

We would love to hear about your feedback.


Best Regards,

Your FromDual Team

FromDual Newsletter Sommer 2011

FromDual.de - Sun, 2011-06-19 16:10
Taxonomy upgrade extras: newslettergerman

Liebe MySQL und MariaDB Nutzerinnen und Nutzer,

Mit diesem Newsletter erfahren Sie, was es diesen Sommer neues von FromDual zu berichten gibt.


You can read this Newsletter in Englisch as well or subscribe to our English version.

Themen Basic- und Silber-Support für MySQL und MariaDB

Ende letzten Jahres hat Oracle/MySQL die günstigen Basic- und Silber-Supportangebote aus ihrem Dienstleistungsangebot gestrichen. Die offizielle Begründung lautete: Geringe Nachfrage auf Kundenseite.

Zahlreiche MySQL Nutzer haben sich hierauf bei uns gemeldet und diese Dienstleistungen nachgefragt. Wir können Ihnen daher folgendes anbieten:

  • Unseren Best Effort Support (BES) für EUR 990.-/Jahr als Alternative zu MySQL Basic und
  • Unseren Business Hour Support (5 x 9, BHS) für EUR 1'990.-/Jahr als Alternative zu MySQL Silber.

Natürlich bieten wir Ihnen auch im high-end Bereich Support für MySQL und MariaDB an mit unserem All Day Long Support (ADLS, 7x16) und All around the Clock Support (7 x 24, AatCS).

Mehr Informationen finden Sie unter 7x24 Premium Support.

Bei Fragen zu unserem Support-Angebot stehen wir Ihnen gerne für ein Gespräch zur Verfügung. Bitte teilen Sie uns mit, wenn wir Sie kontaktieren sollen...

FromDual Performance Monitor für MySQL mit mehr InnoDB Graphen

Mitte Juni hat FromDual den neusten Release seines MySQL Performance Monitors freigegeben. Auf vielfachen Wunsch unserer Kunden haben wir die InnoDB Graphen stark ausgebaut und verbessert.

Einige Beispiel-Graphen finden Sie unter InnoDB Graphs for MySQL Performance Monitor.

Sommerferien ohne MySQL DBA?

Sollte Ihr MySQL DBA in den wohlverdienten Sommer-Urlaub fahren wollen, müssen Sie ihm dies jetzt nicht mehr verbieten! Wir übernehmen seine Arbeiten während der Sommerferien für ihn...

Mehr Informationen über unsere Remote-DBA Dienstleistungen finden Sie auf unserer Website.

Anstehende Schulungen und Workshops
  • Am 20. und 21. August 2011 findet in St. Augustin die FrOSCon 6 / 2011 statt. Wir werden mit unserem Vortrag MySQL Performance Tuning (auf deutsch) vertreten sein. Wenn Sie wissen wollen, wie wir bei unseren Kunden Performance Tuning durchführen, kommen Sie uns doch besuchen!
  • Vom 15. bis zum 17. August führen wir mit Citrus einen MySQL Developer Workshop für Fortgeschrittene in Helsinki durch. Der Workshop findet in englischer Sprache statt.
  • An den /ch/open Workshop Tagen 2011 führen wir am Donnerstag 15. September den Workshop MySQL High-Availability mit einem aktiv/passiv Failover-Cluster durch. All jene, welche letztes Jahr im falschen Workshop waren, haben dieses Jahr die Gelegenheit, den richtigen Workshop zu besuchen...
  • Am 24. und 25. Oktober findet im Linux-Hotel in Essen ein MySQL Cluster Kurs statt. Anmelden können Sie sich direkt beim Linux Hotel.
Technische Informationen

Die folgenden technischen Information, welche wir zum Thema MySQL erarbeitet haben, sind für Sie interessant:

Wenn Sie unsere Vorträge zum Thema HA Architekturen mit MySQL oder HandlerSocket und ähnliche Technologien - NoSQL für MySQL an den DOAG SIG's verpasst hat, findet die Folien als PDF unter Präsentationen.

Deutschsprachige MySQL Anwender Gruppe gegründet

Anfangs Juni wurde die Deutschsprachige MySQL Anwender Gruppe (DMySQLAG) gegründet.

Der Verein fördert:

  • die Information über den Einsatz, den Umgang und die Erfahrung mit MySQL und Entwicklungen im MySQL Öko-System sowie Anwendungssysteme welche MySQL nutzen.
  • den Erfahrungsaustausch zwischen den Benutzern über MySQL sowie anderer Systeme.
  • die Beratung und Zusammenarbeit mit Oracle und Herstellern anderer Systeme.
  • die Unterbreitung von Mitgliedervorschlägen an Oracle und Hersteller von anderen Systemen.

Die deutschsprachige MySQL Anwender Gruppe ist für MySQL Anwender aus Deutschland, Österreich und der Schweiz gedacht. Damit Österreich und Schweiz ein genügend grosses Gewicht erhalten sind insbesondere zahlreiche Anmeldungen aus diesen beiden Ländern erwünscht!

Die Mitgliederbeiträge betragen:

  • Schüler und Studenten: frei
  • Einzelmitglieder: EUR 100.-/a
  • Firmen bis 500 Mitarbeiter: EUR 200.-/a
  • Firmen über 500 Mitarbeiter: EUR 300.-/a
Neuigkeiten zu MySQL
  • MySQL hat im May 2011 die Releases 5.5.13 und 5.5.14 freigegeben und zahlreiche (ca. 50) Bugs in InnoDB und der Replikation gefixt.
  • Diverses Neue Releases für MySQL Cluster 7.0, 7.1 und 7.2 stehen in der Pipeline und dürften in den nächsten Wochen freigegeben werden.
  • MariaDB 5.2.6 und 5.2.7 wurden im Mai und Juni freigegeben.
  • Galera, eine synchrone Multi-Master-Replikation für MySQL nähert sich mit v0.8 in grossen Schritten einem stabilen und für den kommerziellen Einsatz geeigneten Zustand. Es lohnt sich, dieses Produkt auszuprobieren!

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

Gerne nehmen wir auch Ihre Rückmeldungen entgegen.


Mit freundlichen Grüssen,

Ihr FromDual Team

MySQL Entwickler Workshop für Fortgeschrittene

FromDual.de - Wed, 2011-06-08 10:46
Taxonomy upgrade extras: germanVom 15. bis zum 17. August führt FromDual mit Citrus einen MySQL Entwickler Workshop für Fortgeschrittene in Helsinki (Finnland) durch. Der Workshop findet in englischer Sprache statt. Die behandelten Themen finden Sie hier und hier können Sie sich registrieren.

Advanced MySQL Developer Workshop

FromDual.en - Wed, 2011-06-08 10:44
Taxonomy upgrade extras: englishFrom August 15th to 17th FromDual will have an Advanced MySQL Developer Workshop with Citrus in Helsinki (Finland). The workshop will be held in English. The workshop topics you can find here and the registration form is available here.

Deutschsprachige MySQL Anwender Gruppe gegründet (DMySQLAG)

Oli Sennhauser - Mon, 2011-06-06 16:51
Heute wurde in Berlin die Deutschsprachige MySQL Anwender Gruppe formal gegründet. Der Verein fördert:
  • die Information über den Einsatz, den Umgang und die Erfahrung mit MySQL und Entwicklungen im MySQL Eco-System sowie Anwendungssysteme welche MySQL nutzen.
  • den Erfahrungsaustausch zwischen den Benutzern über MySQL sowie anderer Systeme.
  • die Beratung und Zusammenarbeit mit Oracle und Herstellern anderer Systeme.
  • die Unterbreitung von Mitgliedervorschlägen an Oracle und Hersteller von anderen Systemen.
Die deutschsprachige MySQL Anwender Gruppe ist für MySQL Anwender aus Deutschland, Österreich und der Schweiz gedacht. Damit Österreich und Schweiz ein genügend grosses Gewicht erhalten sind insbesondere zahlreiche Anmeldungen aus diesen beiden Ländern erwünscht! Wer als Gründungsmitglied aufgeführt werden will, soll sich asap (bis Freitag) bei uns per e-Mail melden. Eine spätere Mitgliedschaft ist jederzeit möglich. Mitgliederbeiträge
  • Schüler und Studenten: frei
  • Einzelmitglieder: EUR 100.-/a
  • Firmen bis 500 Mitarbeiter: EUR 200.-/a
  • Firmen über 500 Mitarbeiter: EUR 300.-/a
Taxonomy upgrade extras: mysqlanwendergerman

Deutschsprachige MySQL Anwender Gruppe gegründet (DMySQLAG)

Oli Sennhauser - Mon, 2011-06-06 16:51
Taxonomy upgrade extras: mysqlanwendergermanHeute wurde in Berlin die Deutschsprachige MySQL Anwender Gruppe formal gegründet. Der Verein fördert:
  • die Information über den Einsatz, den Umgang und die Erfahrung mit MySQL und Entwicklungen im MySQL Eco-System sowie Anwendungssysteme welche MySQL nutzen.
  • den Erfahrungsaustausch zwischen den Benutzern über MySQL sowie anderer Systeme.
  • die Beratung und Zusammenarbeit mit Oracle und Herstellern anderer Systeme.
  • die Unterbreitung von Mitgliedervorschlägen an Oracle und Hersteller von anderen Systemen.
Die deutschsprachige MySQL Anwender Gruppe ist für MySQL Anwender aus Deutschland, Österreich und der Schweiz gedacht. Damit Österreich und Schweiz ein genügend grosses Gewicht erhalten sind insbesondere zahlreiche Anmeldungen aus diesen beiden Ländern erwünscht! Wer als Gründungsmitglied aufgeführt werden will, soll sich asap (bis Freitag) bei uns per e-Mail melden. Eine spätere Mitgliedschaft ist jederzeit möglich. Mitgliederbeiträge
  • Schüler und Studenten: frei
  • Einzelmitglieder: EUR 100.-/a
  • Firmen bis 500 Mitarbeiter: EUR 200.-/a
  • Firmen über 500 Mitarbeiter: EUR 300.-/a

BLOB's aus der MySQL Datenbank herausklauben

Oli Sennhauser - Fri, 2011-04-22 14:12

Ein Kunde, welcher mit digitalen Zertifikaten zu tun hat, hatte ein Problem mit einem solchen. Also mussten wir nachforschen, was das Problem war.

Weil das Zertifikat in binärer Form vorliegt, ist es in einem BLOB gespeichert und wir mussten es aus der Datenbank herausklauben um einige Tests damit durchzuführen.

Als erstes kam mir in den Sinn, das Zertifikat mit dem Befehl SELECT INTO OUTFILE zu erhalten. Aber das Verifizierungstool reklamierte und sagte uns, dass das Zertifikat ein falsches Format habe.

Zum Glück fand ich in der MySQL Dokumentation den folgenden Satz: If you use INTO DUMPFILE instead of INTO OUTFILE, MySQL writes only one row into the file, without any column or line termination and without performing any escape processing. This is useful if you want to store a BLOB value in a file.

Wir haben es ausprobiert mit:

mysql> SELECT certificate INTO DUMPFILE '/tmp/certificate.bin' FROM identity WHERE id = 42;

und es hat perfekt funktioniert. Das Zertifikat-Verifizierungstool hatte nichts mehr zu meckern und wir konnten weiter nachforschen, warum das Zertifikat überhaupt ein Problem verursacht hat...

Mit diesem Befehl, welchen ich vorher noch nicht kannte, ist es sehr einfach ein einzelnes BLOB aus der Datenbank in eine Datei zu dumpen und dieses von dort aus weiter zu verarbeiten.

Zur Erinnerung: MySQL hat eine generelle Protokoll-Limitation für BLOB's von 1 Gbyte und die Grösse für max_allowed_packet muss entsprechend für den Client UND den Server angepasst werden wenn grosse BLOB's verwendet werden. Weitere Informationen über MySQL-Limitationen finden Sie hier.

Im weiteren muss der Typ des BLOB's entsprechend der erwarteten Grösse des BLOB's richtig gewählt werden. Siehe auch: Data Type Storage Requirements.

Literatur
  1. SELECT Syntax
Taxonomy upgrade extras: mysqlblobdumpselectgerman

BLOB's aus der MySQL Datenbank herausklauben

Oli Sennhauser - Fri, 2011-04-22 14:12
Taxonomy upgrade extras: mysqlblobdumpselectgerman

Ein Kunde, welcher mit digitalen Zertifikaten zu tun hat, hatte ein Problem mit einem solchen. Also mussten wir nachforschen, was das Problem war.

Weil das Zertifikat in binärer Form vorliegt, ist es in einem BLOB gespeichert und wir mussten es aus der Datenbank herausklauben um einige Tests damit durchzuführen.

Als erstes kam mir in den Sinn, das Zertifikat mit dem Befehl SELECT INTO OUTFILE zu erhalten. Aber das Verifizierungstool reklamierte und sagte uns, dass das Zertifikat ein falsches Format habe.

Zum Glück fand ich in der MySQL Dokumentation den folgenden Satz: If you use INTO DUMPFILE instead of INTO OUTFILE, MySQL writes only one row into the file, without any column or line termination and without performing any escape processing. This is useful if you want to store a BLOB value in a file.

Wir haben es ausprobiert mit:

mysql> SELECT certificate INTO DUMPFILE '/tmp/certificate.bin' FROM identity WHERE id = 42;

und es hat perfekt funktioniert. Das Zertifikat-Verifizierungstool hatte nichts mehr zu meckern und wir konnten weiter nachforschen, warum das Zertifikat überhaupt ein Problem verursacht hat...

Mit diesem Befehl, welchen ich vorher noch nicht kannte, ist es sehr einfach ein einzelnes BLOB aus der Datenbank in eine Datei zu dumpen und dieses von dort aus weiter zu verarbeiten.

Zur Erinnerung: MySQL hat eine generelle Protokoll-Limitation für BLOB's von 1 Gbyte und die Grösse für max_allowed_packet muss entsprechend für den Client UND den Server angepasst werden wenn grosse BLOB's verwendet werden. Weitere Informationen über MySQL-Limitationen finden Sie hier.

Im weiteren muss der Typ des BLOB's entsprechend der erwarteten Grösse des BLOB's richtig gewählt werden. Siehe auch: Data Type Storage Requirements.

Literatur
  1. SELECT Syntax

The DRBD Module for FromDual Performance Monitor for MySQL is now available

FromDual.en - Fri, 2011-04-01 21:59
Taxonomy upgrade extras: drbdperformance monitorreleasempmmaas

FromDual has released today the next version v0.6 of its FromDual Performance Monitor for MySQL.

The most important improvement of the new release is the new monitoring module for DRBD devices which are often used in MySQL High Availability (HA) set-ups.

More information about the new functionality added you can find in the article MySQL Performance Monitor with DRBD monitoring capabilities, MySQL Performance Monitor and in the MySQL HA (high availability) cookbook.

The FromDual Performance Monitor for MySQL is now available on our download page.

Follow us on Twitter...

Wo sich die MySQL Gemeinde tummelt...

Oli Sennhauser - Sun, 2011-03-27 21:27

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

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

Der Weg nach #mysql.de

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

Web-IRC

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

Die Reise

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

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

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

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

/join #mysql.de

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

Bräuche und Sitten

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

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

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

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

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

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

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

Willkommen!

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

Kommt uns doch mal besuchen!

Lokale Sprache

Einige nützliche Redewendungen im IRC-Universum sind:

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

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

Weiter Länder in dieser Welt

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

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

Wo sich die MySQL Gemeinde tummelt...

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

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

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

Der Weg nach #mysql.de

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

Web-IRC

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

Die Reise

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

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

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

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

/join #mysql.de

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

Bräuche und Sitten

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

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

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

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

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

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

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

Willkommen!

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

Kommt uns doch mal besuchen!

Lokale Sprache

Einige nützliche Redewendungen im IRC-Universum sind:

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

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

Weiter Länder in dieser Welt

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

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

Vorsicht bei der Nutzung von SAN

Oli Sennhauser - Fri, 2011-03-04 18:36

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

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

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

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

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

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

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

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

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

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

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

Siehe auch unser Commit Demo Test:

Taxonomy upgrade extras: performancesanvirtualizationconsolidationcloudvirtualisierungkonsolidierunggerman

Vorsicht bei der Nutzung von SAN

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

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

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

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

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

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

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

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

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

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

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

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

Siehe auch unser Commit Demo Test:

PrimeBase Technologies and FromDual form a Service-Cooperation for MySQL products

FromDual.en - Mon, 2011-02-28 14:58
Taxonomy upgrade extras: englishmysqlsupportprimebaseremote-dbacooperationproductservicemysql-support

From the Cooperation of these two companies arises the biggest independent service provider for MySQL and MariaDB in Europe.

Hamburg, Uster -- February 28, 2011 - The Hamburg based PrimeBase Technologies and the near Zürich located FromDual are forming a Cooperation for MySQL products and services, starting March 1st, 2011.

This Cooperation enables both companies to offer a complete set of services for all MySQL and MariaDB customers.

The customers of both parties now have he possibility to demand a 24x7 support service from their provider.

Companies, which use MySQL, often do not have the capability to operate the product themselves, because they do not have sufficiently trained MySQL staff.

The Remote-DBA offer meets exactly this need: Customers then have the possibility to let their databases be operated by a MySQL specialist.

In addition, the set of services offers MySQL Health Checks on a regular basis or an Emergency intervention in case of an incident.

The whole package is built modularly and there is no obligation to pay license fees or to purchase service that one does not need.

About PrimeBase Technologies

PrimeBase Technologies is the maker of the well known, scalable and transactional MySQL Storage Engine PBXT as well as the Streaming Engine PBMS and offers Support Services for MySQL and MariaDB. PrimeBase Technologies, furthermore is MySQL Platinum Partner.

Its CTO Paul McCullagh is currently the only Oracle ACE Director for MySQL in Europe.

Further information can be found at: www.PrimeBase.com.

About FromDual

FromDual is a global acting, neutral and vendor independent consulting company for MySQL and MariaDB with numerous customers from the Telecom, Media, Service, Internet and Industry sector. FromDual offers services and training for MySQL and its derivatives MariaDB, Percona Server and Drizzle. FromDual is an Oracle Silver Partner and Open Database Alliance (ODBA) Silver Partner.

Further information can be found at: www.fromdual.com

Contacts

PrimeBase Technologies GmbH: volker.oboda@primebase.com, Phone +49 40 389 044 15

FromDual GmbH: oli.sennhauser@fromdual.com, Phone +41 79 830 09 33

PrimeBase und FromDual schließen Kooperationsvertrag für MySQL Dienstleistungen

FromDual.de - Mon, 2011-02-28 14:50
Taxonomy upgrade extras: consultingberatungbetriebsupportprimebasekooperationdienstleistungenremote-dbagermanmysql-supportmysql-consultingmysql-beratung

Hamburg, Uster - 28. Februar 2011 - PrimeBase Technologies GmbH aus Hamburg und die in der nähe von Zürich ansässige FromDual GmbH gehen ab dem 1. März 2011 eine Partnerschaft für MySQL Produkte und Dienstleistungen ein.

Diese Partnerschaft ermöglicht es, den beiden Unternehmen eine vollständige Palette von Dienstleistungen für Ihre MySQL und MariaDB Kunden auch in deutscher Sprache anzubieten. Insbesondere besteht für die zahlreichen Kunden der beiden Unternehmen jetzt auch die Möglichkeit, einen 7x24 Stunden Support in Anspruch zu nehmen.

Unternehmen, die MySQL einsetzen, stehen immer öfter vor dem Problem, Ihre Anwendungen, die MySQL oder MariaDB verwenden, selber zu betreiben, zu warten oder weiter zu entwickeln. "Am Markt stehen nicht ausreichend ausgebildete MySQL Fachkräfte zur Verfügung", erklärt Oli Sennhauser, Geschäftsführer FromDual.

Genau hier setzt das Remote-DBA Angebot an: Die Kunden haben die Möglichkeit, ihre Datenbanken von einem MySQL Spezialisten betreiben zu lassen und zahlen nur den tatsächlichen Aufwand.

Das Dienstleistungsangebot beider Unternehmen umfasst auch einen regelmäßigen MySQL Gesundheitscheck oder eine Notfall-Intervention im Falle eines Zwischenfalles.

Das Angebotspaket ist Modular aufgebaut, und es besteht für Kunden keine Verpflichtung Lizenzgebühren zu entrichten oder zwingend Dienstleistungen zu kaufen, die man eigentlich gar nicht benötigt.

Über PrimeBase Technologies GmbH

PrimeBase Technologies GmbH ist Hersteller der bekannten, skalierbaren und transaktionsorientierten MySQL Storage Engine PBXT, sowie der Streaming Engine PBMS und bietet Support-Dienstleistungen für MySQL, Drizzle und MariaDB an. PrimeBase Technologies ist zudem MySQL Platinum Partner. Paul McCullagh, CTO, ist zur Zeit der einzige Oracle ACE Director für MySQL in Europa und wurde in 2008 MySQL Code Contributor of the year

Weitere Informationen finden Sie unter: www.PrimeBase.com.

Über FromDual

FromDual ist ein weltweit tätiges, neutrales und herstellerunabhängiges Beratungsunternehmen für MySQL und MariaDB mit zahlreichen Kunden aus der Telekom-, Medien-, Dienstleistungs- und Internet-Branche sowie der Industrie. FromDual bietet Beratung und Schulung für MySQL, sowie dessen Derivate MariaDB, Percona Server und Drizzle an. FromDual ist Oracle Silber Partner sowie Open Database Alliance (ODBA) Silber Partner.

Weitere Informationen finden Sie unter: www.fromdual.com

Kontakt

PrimeBase Technologies GmbH: volker.oboda@primebase.com, Telefon +49 40 389 044 15
Max-Brauer-Allee 50, D-22765 Hamburg

FromDual GmbH: oli.sennhauser@fromdual.com, Telefon +41 79 830 09 33
Rebenweg 6, CH-8610 Uster

DOAG Reagionaltreffen in München - 23. März 2011

FromDual.de - Mon, 2011-02-21 15:58
Taxonomy upgrade extras: mysqldoagregionaltreffenmünchenreplikationgerman

Wir sind am DOAG Regionaltreffen in München am Mittwoch den 23. März mit unserem Vortrag MySQL Replikation - Scale-Out, Master-Master, Backup (der Vortrag wird in deutscher Sprache gehalten).

FromDual releases new version of its MySQL Performance Monitor

FromDual.en - Sun, 2011-02-20 16:39
Taxonomy upgrade extras: mysqlperformanceenterprise monitormonitorperformance monitoringmpmmaas

FromDual releases its new version v0.5 of its MySQL Performance Monitor working with Zabbix.

What has changed so far in this release:

  • Recommended Location has changed to /usr/local
  • FromDual agent log files are rotated now.
  • There are now 2 different packages: One for the Agent and one for the Templates.
  • Some of the graphs were improved.
  • Missing status and system variable information were added and some were fixed.
  • Verbosity of logging information was adjusted.
  • A module for monitoring additional informations for Linux servers was added.
  • Agent caches now the data if it has no access to server. This gives the possibility to run the agent without an installed Zabbix Server and load the data later on off-site.
  • Start/stop scripts for running Zabbix agent and server under the mysql user were added.
  • Status information for the Aria Storage Engine were added.

The MySQL Performance Monitor is free of costs and the modules are offered under GPL.

You can get it from our download page.

If you find some problems or have suggestions to improve this solution please let us know about.

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

Oli Sennhauser - Wed, 2011-01-12 20:25

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

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

Wir hatten das folgende MySQL Cluster Konstrukt im Einsatz:

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

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

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

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

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

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

Unsere Erkenntnisse

Unsere Erkenntnisse waren folgender Art:

Doppelte Primary Key Einträge

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

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

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

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

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

Empfohlene Channel Fail-over Methode funktioniert nur unter Last

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

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

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

Dokumentationsfehler über log_slave_updates

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

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

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

Leere Epochen

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

Log_slave_updates wird auch durch den Binlog Injector Thread berücksichtigt

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

Skip_slave_start sollte verwendet werden

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

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

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

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

Taxonomy upgrade extras: replicationMySQL Clusterfail-overchannelRing-Replikationgerman

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

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

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

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

Wir hatten das folgende MySQL Cluster Konstrukt im Einsatz:

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

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

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

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

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

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

Unsere Erkenntnisse

Unsere Erkenntnisse waren folgender Art:

Doppelte Primary Key Einträge

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

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

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

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

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

Empfohlene Channel Fail-over Methode funktioniert nur unter Last

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

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

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

Dokumentationsfehler über log_slave_updates

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

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

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

Leere Epochen

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

Log_slave_updates wird auch durch den Binlog Injector Thread berücksichtigt

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

Skip_slave_start sollte verwendet werden

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

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

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

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

MyEnv für Multi-Datenbank Set-ups

Oli Sennhauser - Wed, 2010-12-01 12:21

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

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

Was ist MyEnv?

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

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

Wann soll MyEnv eingesetzt werden?

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

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

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

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

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

Weitere Informationen finden Sie in der MyEnv Dokumentation.

Taxonomy upgrade extras: mysqlenvironmentmulti instancedatabasevirtualizationconsolidationSaaSMyEnv

Pages

Subscribe to FromDual Aggregator