Ich hatte schon länger vor mir mal Galera anzuschauen. Folgender Blog hatte mich daran erinnert es endlich zu machen.
Was ist Galera?
Galera verspricht synchrone Replikation und ein Multi-Master-Setup. So werden die Daten nicht nur sicher repliziert, nein Galera ist es auch egal in welche der Nodes (auch gleichzeitig) geschrieben wird.
Um dies zu bewerkstelligen wurde MySQL gepatcht. Wobei wir auch schon beim ersten Problem sind. Wer sich Galera (Version 0.8) anschauen will bekommt eine MySQL 5.1.53. Des weiteren repliziert Galera nur InnoDB/XtraDB-Tabellen. Da obiger Blog schon mit einem Howto kommt. Erspare ich mir diese Erklärung. Zudem ist die Installation des Demo-Tar-Balls straight forward.
Galera erlaubt unter anderem eine (nahezu) synchrone Replikation. …

Moinsen, ich nutze noch stark die 5.1.xer Schiene von MySQL. Zudem verwende ich keine Pakete der Distributionen. Beim Verarbeiten der Binärpakete von MySQL. Schrieben meine Installskripte - bei der 5.1.57 - plötzlich ins Errorlog:

WARNING: HELP FILES ARE NOT COMPLETELY INSTALLED!
The "HELP" command might not work properly.

Genaueres ist hier nachzulesen. Da wurde die fill_help_tables.sql - von 5.1.56 auf 5.1.57 - um genauere Links erweitert. Nur dass diese dann zu lang für `url` char(128) NOT NULL in der Tabelle mysql.help_topic waren.

Es handelt sich "nur" um die Helpfiles ... aber trotzdem :)

Viel Spaß
Erkan

MariaDB soll laut folgender Page bei temporay tables schneller sein als MySQL. Da:

Our use of the Aria storage engine enables faster complex queries (queries which normally use disk-based temporary tables). The Aria storage engine is used for internal temporary tables, which should give you a speedup when doing complex selects. Aria is usually faster for temporary tables when compared to MyISAM because Aria caches row data in memory and normally doesn't have to write the temporary rows to disk.
Um dies zu testen wurden folgende Versionen installiert:

• MySQL 5.5.12
• MySQL 5.1.57
• MariaDB 5.2.6
• MariaDB 5.1.55
  

Es wurden zwei Tabellen mit jeweils 10000 Rows erstellt:

Ein Freund fragte mich nach Konventionen für die Benennung von Tabellen bei der Entwicklung von Schemata für MySQL Datenbanken. Es begann damit, daß er mich fragte, wie man denn wohl eine Relation benennen soll, also eine Hilfstabelle, die zwei Tabellen in einer n:m-Beziehung miteinander verbindet.

In einem alten Job hatten wir die unten stehenden Regeln. Sie sind recht willkürlich und man kann sich anders entscheiden, aber wir hatten das so gemacht und es hat gut für uns funktioniert.

Jede Tabelle bekommt einen Namen in Kleinbuchstaben (oder der Server läuft mit lower_case_table_names = 1, was sowieso empfehlenswert ist). Der Name ist ein beschreibendes Wort im Singular. Auf diese Weise hat man weniger Schmerzen, wenn man über eine Query an einem Beispiel diskutiert. Zusätzlich wird für jede Tabelle ein eindeutiges Kürzel definiert.

Beispiel: Die Tabelle kunde bekommt das eindeutige Kürzel k.

Wir …

Sehr erfolgreich ging heute die DOAG Doppel SIG - Database zum Thema "Cloud Computing" und die erste DOAG Veranstaltung zum Thema "MySQL" zu Ende. Die Teilnehmer bewerteten die Vorträge sehr gut. Es gab viele sehr gute und interessante Vorträge.

Am Donnerstag, den 19. Mai 2011 findet in Hannover die DOAG SIG - Database zum Thema "Cloud Computing" und "MySQL" statt. Es gibt zwei parrallele Vortragsstreams, zwischen denen die Teilnehmer auswählen und pendeln können. Moderator ist der DOAG SIg - Leiter und ORACLE ACE Christian Trieb.

Mehr:
https://mydoag.doag.org/termine/termine.php?tid=413838

https://mydoag.doag.org/termine/termine.php?tid=423270

Ich selbst nutze unter anderem PowerDNS als DNS-Server. Im letzten Monat betrachtete ich mir dessen MySQL-Backend, da ich über zwei Kanäle darüber informiert wurde, dass PowerDNS mit dem Backend nicht skaliert.

Die DNS-Records werden in PowerDNS in zwei Tabellen abgelegt. Eine für die Domains:

create table domains (
id INT auto_increment,
name VARCHAR(255) NOT NULL,
master VARCHAR(128) DEFAULT NULL,
last_check INT DEFAULT NULL,
type VARCHAR(6) NOT NULL,
notified_serial INT DEFAULT NULL,
account VARCHAR(40) DEFAULT NULL,
primary key (id)
) Engine=InnoDB;

Und eine weitere für die Records:

CREATE TABLE records (
id int(11) NOT NULL auto_increment,
domain_id int(11) NOT NULL,
name varchar(255) NOT NULL,
type varchar(10) NOT NULL,
content varchar(255) NOT NULL,
ttl …

Mit MariaDB 5.3 wird ein neuer ColumnType Einzug halten. Das sogenannte Dynamic Column. Die Idee ist gewisse Vorgehensweisen, welche aus den DocumentStore-Lösungen (z.B. MongoDB) bekannt sind zu erfüllen. Ob man das wirklich will, liegt nicht an mir zu entscheiden. Doch sei folgender Link dem geneigten Leser nahe gelegt.
Die Idee ist denkbar einfach: In der Tabelle wird eine BLOB-Spalte verwendet um darin die dynamischen Element zu verwalten.
Es sei erwähnt, dass zum Nachspielen  https://code.launchpad.net/~maria-captains/maria/5.3-mwl34 zu verwenden ist.

MariaDB [test]> SELECT VERSION();
+---------------------+
| VERSION()           |
+---------------------+
| 5.3.0-MariaDB-alpha |
+---------------------+ …

MySQL hat bisher nicht den besten Ruf was die Performance von Stored Procedures angeht. Bereits 2008 war dies ein Thema in einem Blogeintrag[1]. Darin wurde die Fibonacci Formel[2] mit einer Stored Function nachgebildet. Das Ergebnis war: PHP ist mit einer ähnlichen Funktion 10x schneller als die MySQL Stored Function. Hat MySQL inzwischen nachbessern können? UPDATE 03.05.2011

Am Dienstag, den 10. Mai 2011 findet in Berlin und am Donnerstag, den 12. Mai 2011 in Kirchheim - Heimstetten (bei München) je eine Veranstaltung zum Thema "MySQL Skalierbarkeit und Leistung verbessern" statt.

Mehr:
http://www.oracle.com/us/dm/h2fy11/70841-wwmk10037168mpp216c004-oem2-359311-de.html

Berlin:
http://www.oracle.com/webapps/events/ns/EventsDetail.jsp?p_eventId=131061&src=7011252&src=7011252&Act=181&evite=181

München:
http://www.oracle.com/webapps/events/ns/EventsDetail.jsp?p_eventId=131062&src=7011252&src=7011252&Act=179&evite=179