März 2015 Archive

;)


#v+

me:
- Erkan Yanar
- erkan.yanar@linsenraum.de
- http://linsenraum.de

Einführung:
- Docker
- Abgrenzung
- Container@Linux(Vanilla)
- Kernelfeatures

Docker:
- Intarktive Steps
- Desktop Docker
- Sysadmin Docker
- Applikationcontainer

Infrastruktur:
- Dockerfiles
- Portable Images
- Golden Image
- MicroServices
- Immutable Infrastructure
#v-

Ja es war ein freier Vortrag/HandsON \o/

Dieses Setup treibt schon seit Jahren sein Unwesen und ist nicht tot zu kriegen. Legen wir erneut an und halten wir uns nicht mit den aktiv-aktiv Setups auf. Nein, der weise DBA von heute nutzt Master-Master nur für Failover-Szenarion.

Was denkt der fancy DBA was Master-Master bringt?

  • Automatisches syncen der Daten beim Recovery.
  • Kein Backpup zum Syncen einspielen.

Erinnern wir uns: MySQL Replikation _ist_ asynchron

Nochmal: MySQL Replikation ist asynchron, auch das was als semi-sync verkauft wird!

Sprich folgendes ist möglich/wahrscheinlich.

Schöne Replikation:

 aktiv                 standby
+------+     c        +------+
|      |------------->|      |
|abcd  |              |ab    |
|      |              |      |
|      |<-------------|      |
+------+              +------+

Nun stirbt der Node hat aber ein Delta:

 RIP                   aktiv
+------+              +------+
|      |-----||------>|      |
|abcd  |              |abc   |
|      |              |      |
|      |<----||-------|      |
+------+              +------+

Aber kein Problem wir haben Master-Master.

Beim Recovery wird alles wieder gut :/:

Recovered              aktiv
+------+              +------+
|      |------------->|      |
|abcd  |              |abce  |
|      |      e       |      |
|      |<-------------|      |
+------+              +------+

Bravo wir haben nicht synchrone Daten!

Recovered             aktiv
+------+              +------+
|      |------------->|      |
|abcde |              |abce  |
|      |              |      |
|      |<-------------|      |
+------+              +------+

Das amüsante hierbei ist, dass mit GTID dieses Master-Master gar nicht mehr nötig ist. Nehmt doch eine einfache Replikation. Bei einem Failover - ein Dank an die GTID - könnt ihr checken, ob auf dem recovering Node Delta Transaktionen sind. Wenn nicht einfach eine Replikation aufsetzen und die Deltas werden gezogen.

Falls doch, dann muss eh ein Full Sync daher;)

Das gilt für GTID@MariaDB und GTID@MySQL. Willkommen in der Ära der GTIDs ;)

Viel Spaß Erkan

systemd ist auf dem Vormarsch. Auch MySQLer werden sich damit arangieren müssen.

Hier ein kleines Beispiel mit MariaDB und Centos7 :)

Wer z.B. den tableopencache erhöhen wollte konnte dies schlicht konfigurieren. Der Prozess startete als user root und hatte keine limit Probleme.

Im service File von Centos läuft der Prozess gleich als Unix User mysql.

[Service]
Type=simple
User=mysql
Group=mysql
..

Dieser User ist nicht in der Lage seine limits nach oben zu veränden. In dem Error Log sollte etwas in folgender Art zu lesen sein:

150303 11:57:02 [Warning] Changed limits: max_open_files: 1024  
 max_connections: 214  table_cache: 400

Netter Weise ist im Service File selbst ein Hinweis auf LimitNOFILE. Nur wer liest das Service File?

Und bitte wie dort dokumentiert die Erweiterung als eigene Datei unter /etc/systemd/system/mariadb.service.d/limits.conf anlegen. Ob es nun limits heißt, ist egal. Bitte nicht die Dateien unter /usr/lib/systemd/system ändern. Die gehören dem Paketmaintainer und sind beim nächsten Update eventuell weg:)

Viel Spaß

Erkan

P.S.: Das Centos Service File selbst ruft /usr/bin/mysqld_safe auf. Halte ich ja für mehr als schlecht. Aber das ist eine andere Geschichte ;)