MySql Failout+Heartbleet Server

B

ByteSurfer

0
Ich hoffe ich befinde mich im richtigen Bereich,

Ich möcht mir für die genannten Szenarien das entsprechende Umfeld aufbauen. Momentan habe ich noch einen DB-Master Server, welcher sich mir dem DB-Slave-Server repliziert. Bei einem Ausfall des Master kann ich entsprechend händisch die Anwendung auf die Slave DB umschalten ...

Wie kann man eine einfaches Szenario erschaffen, was bei einem Ausfall des Masterservers automatisch umschaltet. Auch dachte ich an Loadbalancing ...

Eigent sich hierfür HA Proxy ?
 
Zuletzt bearbeitet:
Du hast diverse Möglichkeiten.

1. Du machst aus deiner Master-Slave-Replikation eine Master-Master-Replikation. Diesen Weg kann man nutzen, wenn ganz sicher keine weiteren Server hinzukommen werden oder weitere Server nur Slaves sein werden. Mehr als 2 Master in einer Master-Master-Replikation sind schlecht zu managen, da du dann quasi im Kreis replizieren musst, was beim Ausfall eines Servers die Replikationskette unterbricht.
Vor die Master-Master-Replikation kannst du jeden beliebigen TCP-Proxy als Loadbalancer setzen, so lange der einen anständigen Health-Check zur Verfügung stellt.

2. Du nutzt Keepalived, damit die IP des ausgefallenen Servers vom anderen Server übernommen werden kann, so dass Client-Request automatisch auf dein Failover-System gehen.

3. Du schickst deine MySQL über den Jordan und setzt stattdessen Percona oder MariaDB mit Galera-Cluster ein. Da kannst du beliebig viele Master drin haben und auch wiederum einfach einen LB vorschalten.

4. Du nutzt Percona Cluster anstelle von Galera.

Meine Empfehlung ist, sich in der MySQL-Welt langsam mal von den Standard-Replikationen zu verabschieden, wenn man vor hat ein Netzwerk zu bauen, das beliebig skalierbar ist. Wir leben in Zeiten von Cloud-Hosting, wo Server auch mal schnell auf ein anderes Host umziehen müssen/können. Das geht mit einem Cluster-Layer wesentlich besser, weil man sich um Master-Status/Binlog-Position etc. nicht mehr kümmern muss.

Davon abgesehen hinkt Oracles MySQL in der Entwicklung mittlerweile weit hinter MariaDB und Percona hinterher. Wenn man nicht auf Features angewiesen ist, die es ausschliesslich in Oracle MySQL gibt, dann sollte man wechseln und XtraDB mit Percona oder MariaDB nutzen. Das performt weitaus besser als MySQLs InnoDB. Und selbst wenn man kein InnoDB nutzt, sind die beiden noch immer besser als MySQL.
 
Hallo bitmuncher,
vielen Dank für die Informationen. Um hier vorab Fragen stellen zu können, muss ich mich in den einzelnen, von Dir genannten Punkten, durch-/einarbeiten. :wink:

Ich melde mich ... :thumb_up:
 
So ... Hmmmh ...
Ich habe mich in den Part der MariaDb ´Geschichte einmal einglesen.

MariaDB-Server zzgl. Client sind auf dem Debian integriert und laufen.

Wird die MariaDb komplett in /etc/mysql installiert?
Wo befindet sich sonst der Pfad zu einer MariaDb-Installation?

Als Komponente für das LoadBalancing habe ich herausgelesen, dass hier die Komponente MariaDb-MaxScale nützlich sein soll ... Wäre das ein Ansatz ?
 
Mit MaxScale hab ich noch nicht gearbeitet. Kann daher nicht einschätzen wie gut das ist. Sieht aber durchaus nach einem sinnvollen Ansatz aus.

Wo die Installation von MariaDB liegt, hängt davon ab, wie es installiert wird. Wenn du die offiziellen Debian-Pakete nutzt, ist es meines Wissens nach wie alle Software im Dateisystem verteilt. Unter /etc/mysql dürfte also nur die Config liegen. Ich selbst bevorzuge mittlerweile Docker-Container, da ich die leichter auf andere Hosts umziehen und in Cloud-Umgebungen wie Kubernetes oder Swarm integrieren kann.
 
Dafür reichen meine Debian/Bash-Kenntnisse wohl nicht aus ... :rolleyes:

Ich werde mich einmal an die MaxScale Geschichte wagen ...
Schaun wa mal ...

Danke Dir !
 
Für deine Angelegenheiten würde ich dir zZ von Percona abraten, die kriegen es seit ca 1/2 Jahr nicht gebackten eine problemlose Installation für Ubuntu bereitzustellen.
Die *.deb-Packete machen Zicken und die Repositories sind augenscheinlich nicht mehr signiert.
Und nötigen den Nutzern dabei noch weitere IMHO unnötische Schritte ab.
Nur damit du halt weniger Kopfschmerzen hast.
Gruß

Fluffy

Broken ubuntu package percona-server-server-5.5 -

Percona Community (Ist schon älter aber unter Ubuntu Xenial immer noch aktuell)
 
Zuletzt bearbeitet von einem Moderator:
Welche Zicken machen die denn? Und wieso nicht signiert?

- wget https://repo.percona.com/apt/percona-release_0.1-4.xenial_all.deb
- dpkg -i percona-release_0.1-4.xenial_all.deb
- apt-get update
- apt-get -y install percona-server-server-5.7

Geht bei mir problemlos.

Edit: Geht übrigens auch mit 5.5 auf einem frisch aktualisierten Xenial.
Edit2:
Code: 
root@1e9bce54739a:/# uname -a
Linux 1e9bce54739a 4.4.20-moby #1 SMP Thu Sep 15 12:10:20 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
root@1e9bce54739a:/# mysql -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.7.14-8 Percona Server (GPL), Release '8', Revision '1f84ccd'
 
Ich hab den kompletten Tar-ball runtergeladen(~270Mb) entpackt und dann percona-server-5.7.deb versucht zu installieren, Und es wurde sich über die Abhängigkeiten beschwert.
Anschließend habe ich es noch einmal mit dem Repository versucht und da hat sich apt beschwert das es nicht verifiziert werden konnte.
Nach einigen hin zu zurück bin ich nun auf MariaDB umgestiegen und es läuft auf anhieb.

Das größte Problem ist da ja das es sich für mich nicht automatisieren ließ.
Abgesehen davon würden in letzter Zeit Software-installationen kompromitiert(eher windows aber trotzdem) und da pack ich mir doch keine Software drauf wenn ich davon ausgehen sollte das sie signiert ist).
Und MariaDB ist da unkomplizierter und wird es für mich auch tun.
 
Also unkomplizierter als mit einem Deb-File, das die Repo-Configs und Keys hinzufügt um dann wie üblich mit apt-get oder aptitude arbeiten zu können, geht es imo kaum. Ich hab die oben genannte Prozedur vorhin auf Ubuntu getestet. Lief absolut problemlos. Sollte es da mal Probleme gegeben haben, sind die offensichtlich behoben.
 
Kommen wir zu dem Punkt, wo ich Hilfe benötige ... :rolleyes:

Ich habe auf meinem System Debian GNU/Linux 8 (Jessy) am laufen, mit einer normale installation.
-PHP 7.0.11-1
und
mysql Ver 15.1 Distrib 10.0.27-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
mariaDB-server, zzgl. MAriaDB-client sind erforlgreich installiert.

Wenn ich jetzt den angegebenen Link abarbeite, welcher meiner Meinung nach korrekt sein sollte,

Building MaxScale from Source Code - MariaDB Knowledge Base

bekomme ich im Abschnitt
Obtaining the MaxScale Source Code

Probleme mit cmake...


ist die Anleitung hier nutzlos, oder liegen hier gröbere Probleme bei mir vor ...

Kann jemand der mehr Erfahrung hat wie ich die Anleitung testen um zu sehen, ob es woanders funktioniert ...

Code: 
-- Performing Test HAVE_RABBITMQ50
-- Performing Test HAVE_RABBITMQ50 - Success
-- Found RabbitMQ version 0.5.2: /usr/lib/x86_64-linux-gnu/librabbitmq.so
-- Found RabbitMQ development headers at: /usr/include
-- Found OpenSSL: /usr/lib/x86_64-linux-gnu/libssl.so;/usr/lib/x86_64-linux-gnu/libcrypto.so (found version "1.0.1t")
-- Valgrind not found.
-- Dynamic MySQL client library not found.
-- Static MySQL client library not found.
-- Pandoc not found.
-- Could not find libtcmalloc, using system default malloc instead.
-- Could not find libjemalloc, using system default malloc instead.
-- Found Git: /usr/bin/git (found version "2.1.4")
-- Could NOT find CURL (missing:  CURL_LIBRARY CURL_INCLUDE_DIR)
-- Found RabbitMQ version 0.5.2: /usr/lib/x86_64-linux-gnu/librabbitmq.so
-- Found RabbitMQ development headers at: /usr/include
CMake Error at cmake/FindLibUUID.cmake:8 (message):
  Could not find libuuid library
Call Stack (most recent call first):
  CMakeLists.txt:43 (find_package)


-- Configuring incomplete, errors occurred!
See also "/MaxScale/build/CMakeFiles/CMakeOutput.log".
See also "/MaxScale/build/CMakeFiles/CMakeError.log".
root@debian-dummy:/MaxScale/build#

Mysql war vorinstalliert, zzgl des Clients ...

Ich weiss, klingt doof ...

-->
kleines Update
[die fehlende Pakete nach installiert, bis auf libtcmalloc]

Code: 
-- Performing Test HAVE_RABBITMQ50
-- Performing Test HAVE_RABBITMQ50 - Success
-- Found RabbitMQ version 0.5.2: /usr/lib/x86_64-linux-gnu/librabbitmq.so
-- Found RabbitMQ development headers at: /usr/include
-- Found OpenSSL: /usr/lib/x86_64-linux-gnu/libssl.so;/usr/lib/x86_64-linux-gnu/libcrypto.so (found version "1.0.1t")
-- Valgrind found: /usr/bin/valgrind
-- Found dynamic MySQL client library: /usr/lib/libmysqlclient.so
-- Found statc MySQL client library: /usr/lib/libmysqlclient.a
-- Looking for LIBMARIADB
-- Looking for LIBMARIADB - found
-- Found MariaDB Connector-C
-- Pandoc found: /usr/bin/pandoc
-- Could not find libtcmalloc, using system default malloc instead.
-- Found libjemalloc: /usr/lib/x86_64-linux-gnu/libjemalloc.so
-- Found Git: /usr/bin/git (found version "2.1.4")
-- Found CURL: /usr/lib/x86_64-linux-gnu/libcurl.so (found version "7.38.0")
-- Found RabbitMQ version 0.5.2: /usr/lib/x86_64-linux-gnu/librabbitmq.so
-- Found RabbitMQ development headers at: /usr/include
CMake Error at cmake/FindLibUUID.cmake:8 (message):
  Could not find libuuid library
Call Stack (most recent call first):
  CMakeLists.txt:43 (find_package)

und somit bekomme ich bei dem Befehle make das keine Steuerdatei gefunden wurde ...
 
Zuletzt bearbeitet:
Guten Morgen,
ja, das ist installiert. Die erster Variante war es - uuid-dev.
Ich habe für die - cmake - Variante nach längerer Suche alle Pakete gefunden und nachinstalliert. :)
Starke Probleme hatte ich noch bei dem Paket - libtcmalloc - welches standalone scheinbar nicht zu bekommen ist!? Die gängigen mit erweiterten Name die man finden kann (z.B ltcmalloc-minimal0) sind nicht funktionsfähig gewesen, in so weit die Meldung "not found" nicht verschwand. Gefunden habe ich dann jenes (google-perf-tools), was mir zmindestens nach der Installation die Meldung "not found" nach Ausführung von cmake verschwinden lies das entsprechende Paket beinhaltet.

Scheint wohl das Richtige zu ein.

Nächster Schritt wäre jetzt make, welcher funktioniert - und nun wen wundert es - scheppert es volle Pulle bei make install an allen Ecken. Tausende Fehler in irgendwelchen Methoden von unbekannten Funktionsaufrufen von sqllite3 usw.. Scheinbar sind diverse *.c dateien kaputt oder falsch installiert, ich habe keine Ahnung.

Sqllite, so wie ich es lese, ist ein eigenes Datenbank-/Treiberpaket. MariaDB ist scheinbar darauf aufgesetzt, bzw. arbeitet damit wodurch es in meinem Installationspaket von MaxScale zu Fehlern kommt.

Ich bin langsam am Verzweifeln, denn die MariaDB Grundinstallation verlief tadellos und absolut Fehlerfrei ...

Ich wäre für dankbar für Unterstützung - denn ich habe so langsam keine Idee mehr ...
 
Problem bei der Anleitung ist, dass sie sich auf Ubuntu bezieht. Ich würde mich nicht darauf verlassen, dass das auch mit Debian identisch funktioniert. Zumindest die Repository-Einträge wirst du anpassen müssen.
 
so vorab erstmal Danke für die Tipps und den Support, denn das hat mich
auf den richtigen Weg gebracht!

Die aufgesetzte MaxScale Variante ist erstmal lauffähig ...

folgende Schritte unter Berücksichtigung des Linkes von bitmuncher führten zum Erfolg:
1. wget [path/to]/*.deb
2. dpkg -i [filename]
"Es kann so einfach sein"

Funktionierte dann tadellos - jetzt nur noch die maxscale.cnf konfigurieren
und man sollte fertig sein.

Ein Frage hätte ich noch,
Server X.X.X.101 Mysql - Master
Server X.X.X.102 Mysql - Slave
Replikation vom Slave zum Master funktioniert tadellos

MariaDb-Server/MaxScale erreichbar über X.X.X.200
erkennt beide entsprechend als Master und Slave.
Fällt einer der beiden (Master/Slave) aus, kann das über eine entsprechende Konsolenabfrage angezeigt werden.

Mit der Applikation bin ich über den X.X.X.200 verbunden und stelle meine
Anfragen an die DB. MAxScale leitet diese weiter an den entsprechenden
DB Server.

Mein Problem ist nun das folgende, hat jemand Erfahrung, bzw. wie kann
ich MaxScale mitteilen das bei einem Failout des Master Servers der
entsprechenden Slave in den Masterstatus versetzen wird. Da MaxScale
Scripbasiert ist, habe ich - augenscheinlich - nur die Möglichkeit über die
maxscale.cnf das event=master_down zu setzen und hier eine Script
ausführen zu lassen, welches dann die entsprechende Tätigkeit ausführen
soll. Problem ist nur, das Script wird nicht angesprochen ... Selbst mit
Root/Maxscale Rechten keine Änderung ...

Wenn man hier entsprechend versucht Informationen zu finden, gelange ich
immer auf EN-Sprachige Foren/Beiträge und habe bald das Gefühl das im
deutsch sprachigen Raum keiner einer derartige Lösung verwendet ... Kann
aber auch sein das ich mich täusche ... Auch sind diese Anleitung immer
unterschiedlich und führen nicht zum Erfolg.

Hat jemand nochmal Rat ?
 
Zuletzt bearbeitet:
Nach etwas hin und her bin ich bei maxscale google groups über den MariaDb-Replication-Manager gestoßen ... schaun wa mal weiter :)
 
Ok,
ich habe es zu laufen ... :)

Vorab, der replication-manager arbeitet nur in Verbindung mit MariaDb 10, oder höher.

Ansonsten läuft MaxScale als "Proxy-/Verbindungsserver" und verteilt die Last auf die entsprechenden Datenbanken. Zzgl. der "still alive" abfrage, welche hervorragend funktioniert. Die zeitliche Verzögerung, ist vorhanden (Ja), aber kann man eigentlich vernachlässigen -ca. 3-4 Sekunden. Finde ich nicht so gravierend ...

Loadbalancing funktioniert hier nur, wenn das AutoCommit auf on ist und keine Transaction gestartet werden.

Bei einem Ausfall des Master wird Event getrieben ein Script auf dem Verbindungsserver ausgeführt, welches Slave1 als neuen Master instanziert und den Slave2 mit den neuen Master replizieren lässt.

Danke !!!

LG, ByteSurfer
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben