Einzelinstallation¶

Installation ohne Interaktionen mit anderen MariaDB-Installationen:

• mariadb-server (ab Ubuntu 14.04 in universe)

mit apturl

sudo apt-get install mariadb-server 

sudo aptitude install mariadb-server 

Fremdquelle¶

Vor Ubuntu 14.04 war MariaDB nicht in den offiziellen Paketquellen enthalten, daher muss eine zusätzliche Fremdquelle hinzugefügt werden: Um aus der Fremdquelle zu installieren, muss man eine Paketquelle freischalten, deren Syntax man auf der Downloadseite von MariaDB erzeugen kann.

Es muss noch ein Schlüssel zur Authentifizierung der Quelle hinzugefügt werden. Wie das geht, ist im Artikel apt-key beschrieben. Nach dem Hinzufügen und Aktualisieren der Paketquellen kann MariaDB installiert werden.

Anschließend kann MariaDB mit folgendem Paket installiert werden:

• mariadb-server

mit apturl

sudo apt-get install mariadb-server 

sudo aptitude install mariadb-server 

Galera Cluster¶

Ein Galera Cluster aus mehreren Servern bietet den Vorteil, dass Les- und Schreibzugriffe auf alle beteiligten Servern erfolgen können und dabei die Datenbanken Redundant gehalten werden. Es können alle bis auf einen Server ausfallen, bevor Daten verloren gehen oder der Zugriff nicht mehr möglich ist.

• mariadb-galera-server

• galera

mit apturl

sudo apt-get install mariadb-galera-server galera 

sudo aptitude install mariadb-galera-server galera 

Wechsel von MySQL nach MariaDB¶

Vorbereitungen: Datenbanksicherung und bisheriges mysql-root-Passwort bereithalten. Man kann natürlich auch ein neues sql-root Passwort für MariaDB vergeben.

MySQL Deinstallieren:

sudo apt-get purge mysql-server mysql-common mysql*
## Aufräumen:
sudo apt-get autoclean; sudo apt-get clean; sudo apt-get autoremove; 
## Prüfen auf sql Reste:
dpkg -l | grep -i -e "sql\|maria" 

MariaDB Installieren:

sudo apt-get install mariadb-server 

Bei einem Test unter Ubuntu 13.04 war in diesem Szenario die bisherige SQL-Datenbank sofort wieder einsatzfähig. Bis auf das ggf. geänderte sql-root-Passwort waren alle SQL-Datenbank-Tabellen und SQL-User vorhanden. Auch eine Anbindung zum Webserver über das Paket php5-mysql lief wieder problemlos. Eine Einspielung einer Datenbanksicherung oder Änderungen in der Konfiguration war nicht notwendig. MySQL ist aktuell 100% binär-kompatibel zu MariaDB, d.h. alle Aufrufe auf der Kommandozeile oder in Schnittstellen zu anderen Programmen funktionieren wie bei MySQL.

Passwortloses Arbeiten¶

Um SQL-Befehle auszuführen, ohne sich jedes Mal bei MariaDB anmelden zu müssen, kann man im Homeverzeichnis die Datei /home/BENUTZERNAME/.my.cnf mit folgenden Inhalt anlegen.

[client]
host     = localhost
user     = BENUTZERNAME
password = PASSWORT
socket   = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host     = localhost
user     = BENUTZERNAME
password = PASSWORT
socket   = /var/run/mysqld/mysqld.sock
basedir  = /usr

Danach sollte man noch die Zugriffsrechte auf den Benutzer beschränken:

chmod 600 /root/.my.cnf 

Ändern des Datenbank-Verzeichnisses¶

Das Standardverzeichnis für Datenbanken ist /var/lib/mysql. Möchte man dies Änderung wollen, sind die folgenden Schritte notwendig.

Zuerst muss die Datei /etc/mysql/my.cnf mit einem Editor mit Root-Rechten ^[4][7] geöffnet werden. Dort Suche man die Zeile datadir und ändert hier den Wert auf das neue Verzeichnis, in dem MariaDB die Datenbank-Dateien ablegen soll.

Anschließend müssen die Systemdatenbanken, welche bei der Installation immer automatisch angelegt werden, vom Verzeichnis /var/lib/mysql ins neue Datenbankverzeichnis kopiert werden. Dabei ist zu beachten, dass Eigentümer und Gruppe der Dateien nicht verändert werden.

Beim Wechsel von MySQL ist zusätzlich die Anpassung von /etc/apparmor.d/usr.sbin.mysqld erforderlich, da AppArmor den Zugriff auf andere Verzeichnisse unterbindet. Siehe hierfür den Artikel von MySQL im Wiki.

Galera Cluster¶

Es ist empfehlenswert die Verbindung abzusichern. Hierzu muss man einen Benutzer mit Passwort anlegen. Die weitere Konfiguration erfolgt weiter unten.

mysql -u root -p -e "SET wsrep_on=OFF; GRANT ALL ON *.* TO BENUTZERNAME@'%' IDENTIFIED BY 'PASSWORT';" 

Um Fehler zu vermeiden, sollte man alle leeren Benutzer löschen:

mysql -u root -p -e "SET wsrep_on=OFF; DELETE FROM mysql.user WHERE user='';" 

Es gibt einige Optionen, die für den Betrieb von Galera notwendig sind. Diese sind hier aufgeführt. In der Datei /etc/mysql/my.cnf müssen folgende Einstellungen zwingend vorgenommen werden. Bereits in der Datei hinterlegte Einstellungen sollten erhalten bleiben und gegebenenfalls angepasst werden:

[mysqld]
# Wenn bind-address auskommentiert ist, "bind-address = 0.0.0.0" oder
# "bind-address = " gesetzt ist, ist die Datenbank an allen Interfaces im Netzwerk erreichbar.
# MariaDB kann auch nur an dem Netzwerk verfügbar sein an dem das Interface angeschlossen ist:
# bind-address = IP-ADRESSE_EINES_INTERFACES
# Auf alle Fälle müssen die Knoten sich über das Netzwerk erreichen können.

binlog_format = ROW
innodb_locks_unsafe_for_binlog=1
innodb_autoinc_lock_mode=2
default_storage_engine=InnoDB
query_cache_size=0
query_cache_type=0

[mysqldump]
max_allowed_packet = 16M
quick
quote-names

[mysql]

[isamchk]
!includedir /etc/mysql/conf.d/

In einer Datei unter /etc/mysql/conf.d/ z.B. /etc/mysql/conf.d/mariadb.cnf kann man dann getrennt die spezifischen Galera-Optionen festlegen. Man kann natürlich auch alle Einstellungen in einer Datei sammeln. Es wird aber empfohlen, diese der Übersichtlichkeit halber zu trennen. Man muss sich auch noch überlegen, welche Replikationsmethode verwendet werden soll:

Es wird empfohlen, rsync zu verwenden, da diese Methode ziemlich schnell, stabil und bandbreitenschonend ist. Man kann natürlich auch eine eigene Lösung implementieren. Dies ist aber im Vergleich zum Nutzen meist zu viel Arbeit.

Es muss im Folgenden die Option wsrep_cluster_address noch besonders beachtet werden. Hier wird eingestellt, wo der nächste Knoten zu finden ist. Der erste Knoten erhält vorübergehend keine Adresse zum Verbinden. Alle weiteren Knoten bekommen eine Adresse eingetragen, die zu einem Knoten gehört, der bereits an dem Cluster beteiligt ist. Zum Schluss wird auch dem ersten Knoten eine Adresse eingetragen, damit auch dieser sich wieder automatisch mit dem Cluster verbinden kann, wenn dieser Knoten einmal ausfällt.

[client]
# Standard ist Latin1. Es wird für einen Galera Cluster aber UTF-8 benötigt. (auch in der Serversektion)
default-character-set = utf8

[mysqld]
# Standard ist Latin1. Es wird für einen Galera Cluster aber UTF-8 benötigt.
character_set_server   = utf8
collation_server       = utf8_general_ci

# "gcom://"" setzen um einen Knoten zu reinitialisieren (resetten)
wsrep_cluster_address = 'gcomm://'
# "gcom://10.10.10.10"" oder "gcom://HOSTNAME"" setzen um einen Knoten mit bestehenden Cluster-Knoten zu verbinden
#wsrep_cluster_address = 'gcomm://KNOTENADRESSE'

wsrep_provider = /usr/lib/galera/libgalera_smm.so

# Wie oft soll versucht werden festgefahrene autocommits zu committen
wsrep_retry_autocommit=1

# Übertragungsmethode (mysqldump, rsync, xtrabackup oder eigene Skripte)
wsrep_sst_method=rsync


## Optionale Einstellungen ##

# Authentifizierung (empfohlen)
wsrep_sst_auth=BENUTZERNAME:PASSWORT

# Name des Clusters
wsrep_cluster_name=CLUSTERNAME

# Log-Level auf DEBUG stellen, damit man mehr Infos bekommt. 
# Diese Einstellung ist bei der Einrichtung sehr zu empfehlen um Fehler zu finden. 
wsrep_debug=1

# Für MyISAM Unterstützung erforderlich
wsrep_replicate_myisam=1

# Konvertiere locking sessions in Transaktionen.
# Transaktionen sorgen dafür das bei parallelen Zugriff auf Daten
# diese für einen zugreifneden gesperrt werden, damit nicht
# der Zufall entscheidet was am Ende gespeichert wird.
wsrep_convert_LOCK_to_trx=1

# Generate fake primary keys for non-PK tables (required for multi-master and parallel applying operation)
wsrep_certify_nonPK=1

Nun kann man MariaDB neustarten und den Status des Clusters überprüfen:

mysql -e "SHOW STATUS LIKE 'wsrep_%';" 

Die Ausgabe sollte in etwa so aussehen. Wenn die Node-Anzahl wsrep_cluster_size stimmt, kann man davon ausgehen, dass alles geklappt hat.

+----------------------------+--------------------------------------+
| Variable_name              | Value                                |
+----------------------------+--------------------------------------+
| wsrep_local_state_uuid     | d50ca7c2-8f17-11e2-0800-ca06845fffe9 |
| wsrep_protocol_version     | 4                                    |
| wsrep_last_committed       | 320                                  |
| wsrep_replicated           | 0                                    |
| wsrep_replicated_bytes     | 0                                    |
| wsrep_received             | 3                                    |
| wsrep_received_bytes       | 267                                  |
| wsrep_local_commits        | 0                                    |
| wsrep_local_cert_failures  | 0                                    |
| wsrep_local_bf_aborts      | 0                                    |
| wsrep_local_replays        | 0                                    |
| wsrep_local_send_queue     | 0                                    |
| wsrep_local_send_queue_avg | 0.000000                             |
| wsrep_local_recv_queue     | 0                                    |
| wsrep_local_recv_queue_avg | 0.000000                             |
| wsrep_flow_control_paused  | 0.000000                             |
| wsrep_flow_control_sent    | 0                                    |
| wsrep_flow_control_recv    | 0                                    |
| wsrep_cert_deps_distance   | 0.000000                             |
| wsrep_apply_oooe           | 0.000000                             |
| wsrep_apply_oool           | 0.000000                             |
| wsrep_apply_window         | 0.000000                             |
| wsrep_commit_oooe          | 0.000000                             |
| wsrep_commit_oool          | 0.000000                             |
| wsrep_commit_window        | 0.000000                             |
| wsrep_local_state          | 4                                    |
| wsrep_local_state_comment  | Synced                               |
| wsrep_cert_index_size      | 0                                    |
| wsrep_causal_reads         | 0                                    |
| wsrep_incoming_addresses   | ,                                    |
| wsrep_cluster_conf_id      | 2                                    |
| wsrep_cluster_size         | 2                                    |
| wsrep_cluster_state_uuid   | d50ca7c2-8f17-11e2-0800-ca06845fffe9 |
| wsrep_cluster_status       | Primary                              |
| wsrep_connected            | ON                                   |
| wsrep_local_index          | 1                                    |
| wsrep_provider_name        | Galera                               |
| wsrep_provider_vendor      | Codership Oy <info@codership.com>    |
| wsrep_provider_version     | 23.2.2(r137)                         |
| wsrep_ready                | ON                                   |
+----------------------------+--------------------------------------+

Galera Cluster Debian-Sys-User inkonsistent¶

Man erhält beim Starten von MariaDB folgende Fehlermeldung oder findet in den Logs folgende Fehlermeldung:

"ERROR 1045 (28000): Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)"

Falls man einen Galera Cluster betreibt, liegt das Problem vor, das auf den Knoten unterschiedliche Passwörter in den Dateien /etc/mysql/debian.cnf auf den Knoten vorhanden sind. Am einfachsten ist es, die Datei von einem Knoten auf den/die anderen zu kopieren. Bei einer Einzelinstallation kann es bei einer Aktualisierung eines Paketes zu einer Veränderung des Passwortes gekommen ist. Man führt einfach folgende SQL-Befehle aus:

1
2
3

grant all privileges on *.* to 'debian-sys-maint'@'localhost' identified by 'newpassword' with grant option;
flush privileges;
quit;