Problem mit MariaDB -> MariaDB kann nicht ganz deaktiviert werden

Wenn
 systemctl stop mysqld
einen mysqld nicht runterfährt, dann ist der nicht korrekt in den 
systemd integriert.

Debian 9 amd64, mit mysql-server aus der Distri:

# ps ax|grep mysql
 2189 ?        Ssl    0:00 /usr/sbin/mysqld
 2260 pts/0    S+     0:00 grep mysql
# systemctl stop mysqld
# ps ax|grep mysql
 2268 pts/0    S+     0:00 grep mysql

Was für ein System und was für ein MariaDB ist das überhaupt? RasPi (wg. 
ARM) ist doch auch Debian, aber die "ps ax" Zeile sieht ziemlich anders 
aus. Ist die oben gezeigte MariaDB überhaupt aus der Distri, oder ist 
die selbst gebaut?

Kevin schrieb:
> Da ich zwischen mehreren MySQL Versionen hin und herschalten muss,
> muss ich MariaDB komplett deaktivieren.

Autsch. Da muss man aufpassen dass auch die richtigen Tools jeweils 
aufgerufen werden. Das eigentliche Runterfahren triggert ja das 
"mysqladmin" Tool. Ich nehme an dass Deine Start Skripte da eine flasche 
Version finden (siehe $PATH) oder das Tool eine andere Config Datei.

In diesem Szenario deaktiviert man die automagischen Startskripte besser 
ganz und startet/stoppt manuell.

Hier wären eventuell Container nützlich. Einvach den jeweiligen Dienst 
in einen eigenen Container packen, und dann jeweils den entsprechenden 
Container starten, den man gerade braucht. Oder einfach alle Container 
parallel laufen lassen.

Ich habe am liebsten libvirt-lxc:
https://dev1galaxy.org/viewtopic.php?id=617 (Anleitung ist zwar für 
Devuan, aber für andere Distros einfach das debootstrap anpassen oder 
wie auch immer die Distro das dort nennt.)

Am Zweitlibsten LXD: 
https://linuxcontainers.org/lxd/getting-started-cli/

Alternativ kann man noch Docker versuchen: 
https://hub.docker.com/_/mariadb/

Kevin schrieb:
> Ich habe ein kleines Problem mit MariaDB.
> Da ich zwischen mehreren MySQL Versionen hin und herschalten muss,

Warum mußt du das?

> muss ich MariaDB komplett deaktivieren.
> Aber so, das es per Bash Script wieder aktiviert werden kann!
> Also nicht deinstallieren, o.ä.
>
> Ich deaktiviere MariaDB wie folgt:
>
> sudo systemctl stop mysqld
> sudo systemctl disable mysqld
> sudo update-rc.d mysqld remove

Ich fände es verwunderlich, wenn das out-of-the-box funktionieren würde. 
Du kannst schon nicht MariaDB und MySQL (gar in mehreren Versionen) aus 
den Distributions-Repositories parallel installieren, weil einige 
executables (z.B. mysqld für den Server-Prozeß) gleich heißen und an 
gleicher Stelle im Dateisystem liegen.

Genau das gleiche Problem kriegst du mit systemd. Die Units dürften 
jeweils gleich heißen (und falls nicht, wäre das ein dummer Zufall). Mir 
wäre auch nicht bekannt, daß es einen Mechanismus gäbe, der bei der 
Installation eine vorhanden Unit gleichen Namens entdeckt und der neu 
installierten Unit einen anderen Namen zuweist. Auch wenn ich nicht 
ausschließen kann, daß das jemand mal reingehackt hat.

Der einzige Weg, wie man das halbwegs sauber hinbekommt, wäre die MySQL- 
bzw. MariaDB-Installationen in eigene Verzeichnisse zu installieren, 
z.B. /opt/MySQL-x.y.z und /opt/MariaDB-a.b.c und jeweils eigene systemd 
Units mit eindeutigen Namen einzurichten. Für die my.cnf und das datadir 
müßte man sich auch Konventionen einfallen lassen. Am einfachsten: 
my.cnf ins Installdir und dort das datadir referenzieren. Aber ohne 
manuelle Arbeit geht das nicht. Für den normalen Anwender ist das 
nämlich nicht notwendig.

spar dir die ganzen kopfschmerzen und nimm (wie schon mindestens einmal 
erwähnt) irgendwas zum containerisieren.

ob lxc, lxd, docker oder auch komplette vms wie z.b. vagrant ist dann 
eher wurscht

Daniel F. schrieb:
> spar dir die ganzen kopfschmerzen und nimm (wie schon mindestens einmal
> erwähnt) irgendwas zum containerisieren.

Besser nicht. Das ganze Containergedöhns ist in diesem Fall vollkommen 
unnötig. Es verbrät bloß Platz auf dem Massenspeicher und im RAM. Der 
einzige Grund, warum man das verwenden wollen würde, ist weil man 
entweder unwillig oder unfähig ist, mal ein bißchen selber zu denken.

Was ganz besonders grotesk ist, wenn man sich verinnerlicht, daß das 
Hirn das einzige Organ ist, das auch bei intensivster Benutzung nicht 
abgenutzt wird, sondern nur immer besser.

Mann kann beliebig viele MySQL- oder MariaDB-Instanzen gleichzeitig 
installiert und (in Grenzen) auch laufen haben. Nur eben nicht die, 
die aus den Standard-Repos kommen, weil die extra dafür gebaut sind, 
einander zu ersetzen. Was ja auch explizit durch die Paketabhängigkeiten 
dokumentiert ist: "X replaces Y" bzw. "X conflicts (with) Y".

Für die Installation muß man sie in unterschiedliche Verzeichnisse 
entpacken, was am einfachsten mit .tar.gz Packages geht. Zum Rest gibt 
es die ausgezeichnete Dokumentation.


PS: nach wie ungeklärt ist, warum man (als Anwender) überhaupt mehrere 
Versionen gleichzeitig installiert haben muß.

PPS:

1

~ $ls -l /usr/local/mysql/

2

total 24

3

drwxr-xr-x  6 axel axel    90 Jan  3  2012 configs/

4

lrwxrwxrwx  1 axel axel    15 Feb 18  2015 current -> mariadb-10.0.15/

5

drwxr-sr-x  3 axel axel   107 Apr 15  2014 current-slave/

6

drwxr-sr-x  3 axel axel    20 Jun  9  2010 enterprise/

7

drwxr-sr-x 10 axel axel   109 Jan  3  2012 maria-5.1/

8

drwxr-sr-x 10 axel axel   109 Jan  3  2012 maria-5.2/

9

drwxr-sr-x 10 axel axel   122 Oct  3  2012 maria-5.3/

10

drwxr-sr-x  8 axel axel   101 Feb 19  2013 maria-5.5/

11

drwxr-sr-x  8 axel axel    78 Apr 15  2014 mariadb-10.0.10/

12

drwxr-xr-x  8 axel axel    78 Dec 17  2014 mariadb-10.0.12/

13

drwxr-xr-x  8 axel axel    78 Dec 17  2014 mariadb-10.0.13/

14

drwxr-xr-x  8 axel axel    78 Dec 17  2014 mariadb-10.0.14/

15

drwxr-sr-x  9 axel axel   101 Mar 29  2017 mariadb-10.0.15/

16

drwxr-xr-x  8 axel axel    78 Apr  8  2015 mariadb-10.1-2b475b5/

17

drwxr-xr-x  9 axel axel   118 Mar 29  2017 mariadb-10.1-git/

18

drwxr-xr-x  9 axel axel   101 Mar 29  2017 mariadb-10.2.4/

19

drwxr-xr-x  9 axel axel    96 Jun  2  2017 mariadb-10.2.6/

20

drwxr-xr-x  9 axel axel   137 Aug 30 14:08 mariadb-10.3.1/

21

drwxr-xr-x  9 axel axel   137 Aug 30 14:23 mariadb-10.3.1-debug/

22

drwxr-xr-x  8 axel axel    78 Dec 17  2014 mariadb-5.5.36/

23

drwxr-xr-x  8 axel axel    78 Dec 17  2014 mariadb-5.5.37/

24

drwxr-xr-x  8 axel axel    78 Dec 17  2014 mariadb-5.5.38/

25

drwxr-xr-x  8 axel axel    78 Dec 17  2014 mariadb-5.5.39/

26

drwxr-sr-x  8 axel axel    78 Dec 17  2014 mariadb-5.5.40/

27

drwxr-sr-x 10 axel axel    97 Feb  2  2014 mysql-4.0/

28

drwxr-sr-x  8 axel axel    76 Jan  3  2012 mysql-4.1/

29

drwxr-sr-x  8 axel axel  4096 Jun 19  2012 mysql-5.0/

30

drwxr-sr-x  8 axel axel   108 Jul 31  2013 mysql-5.1/

31

drwxr-sr-x  8 axel axel   101 Nov  8  2012 mysql-5.5/

32

drwxr-xr-x  7 axel axel    68 Dec 17  2014 mysql-5.5.36/

33

drwxr-xr-x  7 axel axel    68 Dec 17  2014 mysql-5.5.37/

34

drwxr-xr-x  7 axel axel    68 Dec 17  2014 mysql-5.5.38/

35

drwxr-xr-x  7 axel axel    68 Dec 17  2014 mysql-5.5.39/

36

drwxr-xr-x  7 axel axel    68 Dec 17  2014 mysql-5.5.40/

37

drwxr-sr-x  7 axel axel    68 Dec 17  2014 mysql-5.5.41/

38

drwxr-xr-x  7 axel axel    68 Dec 17  2014 mysql-5.6.15/

39

drwxr-xr-x  7 axel axel    68 Dec 17  2014 mysql-5.6.16/

40

drwxr-sr-x  8 axel axel   108 Jun 16  2014 mysql-5.6.17/

41

drwxr-xr-x  7 axel axel    81 Dec 17  2014 mysql-5.6.19/

42

drwxr-xr-x  7 axel axel    81 Dec 17  2014 mysql-5.6.20/

43

drwxr-sr-x  8 axel axel   108 Jul  6  2015 mysql-5.6.21/

44

drwxr-sr-x  7 axel axel    98 Apr 15  2014 mysql-5.7.3-m13/

45

drwxr-sr-x  7 axel axel    68 Apr 17  2014 mysql-5.7.4-labs-april/

46

drwxr-sr-x  7 axel axel    98 Apr 16  2014 mysql-5.7.4-m14/

47

-rw-r--r--  1 axel axel   913 Apr 12  2012 run-sqlbench.conf

48

-rwxr-xr-x  1 axel axel 14779 Apr 12  2012 run-sqlbench.pl*

Aber ich bin ja auch kein normaler Anwender ...

Markus schrieb:
> Kann ich eine bestehende MariaDB 10.0.x-Version einfach mit apt-get
> upgrade auf die 10.2.x aktualisieren

Im Prinzip ja. Was du da machst, ist ein "binary upgrade", unter diesem 
Stichwort liefert das Manual (nimm das von MySQL, das gilt bis auf die 
Versionsnummern) auch Info. MariaDB 10.0 entspricht MySQL 5.6. 10.2 
entspricht ungefähr MySQL 5.7.

> oder gilt es da einiges zu beachten?
> Werden existierende Datenbank beibehalten?

Wenn der Package-Maintainer seine Sache gut gemacht hat, wird nach dem 
Upgrade automatisch mysql_upgrade ausgeführt, das die existierende 
Datenbank auf Kompatibilität prüft und gegebenenfalls updated. Im 
Zweifel mysql_upgrade noch mal händisch ausführen. Wenn es bereits 
gelaufen ist, ist das ein no-op.

Ich empfehle in jedem Fall vorher ein Backup. Entweder mysqldump oder 
den MariaDB-Server stoppen und das datadir komplett sichern.

Axel S. schrieb:
> Daniel F. schrieb:
>> spar dir die ganzen kopfschmerzen und nimm (wie schon mindestens einmal
>> erwähnt) irgendwas zum containerisieren.
>
> Besser nicht. Das ganze Containergedöhns ist in diesem Fall vollkommen
> unnötig. Es verbrät bloß Platz auf dem Massenspeicher und im RAM. Der
> einzige Grund, warum man das verwenden wollen würde, ist weil man
> entweder unwillig oder unfähig ist, mal ein bißchen selber zu denken.

Erzähl' doch bitte keinen Unsinn. Gerade für Anwendungsfälle wie diesen 
sind Container perfekt geeignet.

> Für die Installation muß man sie in unterschiedliche Verzeichnisse
> entpacken, was am einfachsten mit .tar.gz Packages geht. Zum Rest gibt
> es die ausgezeichnete Dokumentation.

Statt des Geschwafels über die bösen Ressourcenfressercontainer hättest 
Du dem TO vielleicht mal eine Quelle für Raspbian-Tarballs nennen 
können. Die "ausgezeichnete" Dokumentation (wer hat die eigentlich 
ausgezeichnet?) ist dazu nämlich leider ein wenig schweigsam.

Markus schrieb:
> Auf https://mariadb.com/kb/en/library/upgrading/ sind nämlich nur
> Updates von einer Version auf die nächste beschrieben, also von 10.0 auf
> 10.1, von 10.1 auf 10.2 usw.

Prinzip:

Wenn du ein Paket per Sourcecode installierst und aktualisierst, dann 
sind die Anweisungen im Source-Paket relevant und es ist dein Job, dich 
daran zu halten.

Wenn du ein Paket per Binär-Distribution wie Debian oder Redhat 
installierst und aktualisierst, dann ist diese Distribution für den 
Einhaltung des korrekten Ablauf des Updates zuständig.

Hallo,

also wenn es sich wirklich um raspbian auf RPI handelt, dann kann ich 
nur empfehlen, einfach mehre davon zu nutzen.

Ich habe mir z.B. 7 rpi gestapelt, die wahlweise als hex-Cluster hinterm 
proxy laufen. Einer hat apache2 der andere nginx, mysql der dritte, 
einer macht nas und einer fhem, 2 sind Reserve für Tests.

Vorteil ist die sichere Installation per apt-get. Wenn man will, kann 
man hinterher immer noch mehrere Pakete auf einem Rechner installieren 
und sieht sofort, ob sich etwas anders verhält und man daher noch nach 
dem Fehler suchen muss.

Gruß,
Michael

Markus schrieb:
> Axel S. schrieb:
>> Im Prinzip ja.
>
> Auf https://mariadb.com/kb/en/library/upgrading/ sind nämlich nur
> Updates von einer Version auf die nächste beschrieben, also von 10.0 auf
> 10.1, von 10.1 auf 10.2 usw

Oh, stimmt, das wollte ich ja noch schreiben. Garantiert ist die 
Updatefähigkeit immer nur von einer Version zum nächsten major-Release 
(also eine Änderung um +1 in der zweiten Stelle der Versionsnummer). In 
der Praxis funktionieren auch größere Sprünge fast immer. Und speziell 
bei MariaDB wird sehr viel Wert auf Kompatibilität gelegt.

Nur wie gesagt: eine Garantie gibt es darauf nicht. U.a. deswegen 
empfahl ich ein Backup. Einen alten Dump solltest du hingegen immer 
einspielen können. Wobei es auch da manchmal Probleme gibt, etwa wenn 
sich die Default-Engine geändert hat.

> Außerdem heißt es auf den zugehörigen
> Unterseiten 'Uninstall MariaDB 10.x'. Ein einfaches 'apt-get upgrade'
> reicht anscheinend nicht aus, sondern vorher muß noch 'apt-get remove'
> ausgeführt werden?

Nein. Unter der Haube macht apt upgrade genau das: es deinstalliert das 
alte Paket und installiert das neue.

Sheeva P. schrieb:
> Axel S. schrieb:
>> Daniel F. schrieb:
>>> spar dir die ganzen kopfschmerzen und nimm (wie schon mindestens einmal
>>> erwähnt) irgendwas zum containerisieren.
>>
>> Besser nicht. Das ganze Containergedöhns ist in diesem Fall vollkommen
>> unnötig. Es verbrät bloß Platz auf dem Massenspeicher und im RAM. Der
>> einzige Grund, warum man das verwenden wollen würde, ist weil man
>> entweder unwillig oder unfähig ist, mal ein bißchen selber zu denken.
>
> Erzähl' doch bitte keinen Unsinn. Gerade für Anwendungsfälle wie diesen
> sind Container perfekt geeignet.

Sie sind in erster Linie komplett überdimensioniert. Und eine ganze 
Menge Dinge erledigen sie trotzdem nicht. Wenn man von außerhalb der 
Container auf die Datenbanken zugreifen will, muß man sich trotzdem 
Gedanken über TCP-Ports oder UNIX-Socket Pfade machen.

Und wie gesagt: eigentlich das trivial. Genauso trivial, wie zwei Autos 
zu haben. Auch Fahranfängern muß man sicher nicht erklären, daß man sie 
dann aber nicht auf dem gleichen Stellplatz parken kann. Die Idee mit 
den Containern entspricht dann dem Ratschlag, sich einfach ein zweites, 
drittes etc. Haus zu kaufen, damit man jeweils ein Auto vor jedes Haus 
stellen kann.

>> Für die Installation muß man sie in unterschiedliche Verzeichnisse
>> entpacken, was am einfachsten mit .tar.gz Packages geht. Zum Rest gibt
>> es die ausgezeichnete Dokumentation.
>
> Statt des Geschwafels über die bösen Ressourcenfressercontainer hättest
> Du dem TO vielleicht mal eine Quelle für Raspbian-Tarballs nennen
> können.

https://www.google.de/search?q=raspbian+mysql+tar.gz ist zu fernliegend?

> Die "ausgezeichnete" Dokumentation (wer hat die eigentlich
> ausgezeichnet?) ist dazu nämlich leider ein wenig schweigsam.

1. die Dokumentation von MySQL ist ausgezeichnet. Das weiß jeder, der 
sie mal benutzt hat. Und vielleicht mit der Dokumentation anderer 
Software verglichen hat.

2. da der Raspberry Pi keine unterstützte Plattform ist (weder von MySQL 
noch von MariaDB) liefert die Hersteller-Doku folgerichtig auch keine 
Hinweise auf derartige Pakete.

@Axel Schwenke

Es gibt diverse Gründe, warum Container Sinn machen können, aber 
generell geht es darum, ein System einfacher managebar zu machen und 
unzusammenhängende Teile etwas zu separieren.

Auf meinem Server z.B. habe ich einen, den ich für Webservices nutze, 
einen für E-Mail, etc., wodurch wenn einer Kaputt geht nicht der ganze 
Server betroffen ist und ich ihn einfacher reparieren, ersetzen, in 
einen früheren Zustand zurücksetzen, auf ein anderes System Kopieren, 
etc. kann.

Für den TO würden Container aus dem selben grund Sinn machen, aus dem 
man Software eben für gewöhnlich nicht direkt von der Quelle hohlt, und 
davon am wichtigsten: Updates. Wenn man Software direckt von den Quellen 
holt, muss man sich selbst manuell ums Updaten kümmern, weil der 
Packetmanager davon ja nichts wissen kann. Verwendet man statdessen 
einen LXC-Container kann man darin einfach "apt-get update" ausführen. 
Es ist auch zu beachten, dass Distributoren auch Security fixes 
backporten, wohingegen man sonst meist hätte auf die neuste version der 
Software updaten müssen.

Auf Desktop und Entwicklungssystemen ist es eventuell etwas weniger 
dramatisch, wenn man nicht oder nicht sofort alle Updates einspielt, 
aber auf Servern bei Produktivsystemen ist dass ein nogo, dort sollte 
alles reibungslos und möglichst ohne Gebastel laufen. Mit einer 
Kombination von apt-mirror und ssmtp kann man die Updates sogar 
automatisieren, und sich jeweils den Bericht zusenden lassen. So bleiben 
die Systeme sicher und stabil, warten sich fast von selbst, und wenn 
doch mal ein Update fehlschlägt oder man mal manuell etwas bestätigen 
müsste laufen die zu updatenden Services in der Regel noch, so dass man 
sich durchaus etwas Zeit lassen kann, bis man gelegenheit hat sich darum 
zu kümmern. Das ist um einiges besser, als selbst manuell rumkramen zu 
müssen, oder die Updates einfach zu vergessen und irgendwann mit 
unsicheren, uralten, fast oder garnichtmehr updatebaren Softwaremonstern 
zu enden.

Dies ist aber auch, weshalb ich libvirt-lxc gegenüber Docker bevorzuge, 
bei Docker ist es nicht ungewöhnlich, dass bei den Images nicht alle 
Layer geupdatet werden, wenn dies nötig würde, das ganze Image veraltet, 
oder andere Dinge wie z.B. das regenerieren von Keys vergessen wird. Bei 
libvirt-lxc hingegen habe ich eine normale Installation einer ganz 
normalen Distro, die ich ganz normal Updaten kann, ein wenig wie bei 
einer VM, nur kleiner, schneller und ohne Emulation. Wen kümmern denn 
schon die paar MB mehr, wenn man sich dafür den ganzen Wartungsaufwand 
sparen kann?

Axel S. schrieb:
> Sheeva P. schrieb:
>> Axel S. schrieb:
>>> Besser nicht. Das ganze Containergedöhns ist in diesem Fall vollkommen
>>> unnötig. Es verbrät bloß Platz auf dem Massenspeicher und im RAM.
>>
>> Erzähl' doch bitte keinen Unsinn. Gerade für Anwendungsfälle wie diesen
>> sind Container perfekt geeignet.
>
> Sie sind in erster Linie komplett überdimensioniert.

Wie gesagt: erzähl' doch bitte keinen Unsinn. Ein Container ist im 
Prinzip wenig mehr als ein über Cgroups und Namespaces isolierter 
Prozeß, und hat deswegen minimalen Overhead. Wenn man mit Docker für 
seine Container immer dasselbe Basisimage verwendet, belegt das auch nur 
einmalig Diskspace. (Im Gegensatz zu Daniel Albrecht mag ich Docker 
nicht nur, aber auch und gerade wegen des gestackten Dateisystems.)

Im Falle von Debian 9 Stretch belegt das ungefähr 100 Megabyte, mit 
einem kleinen System wie Alpine Linux sogar nichtmal winzige 5 MB. Der 
Docker-Daemon selbst "verbrät" auch nur schmale 34 Megabyte 
Arbeitsspeicher... Überdimensioniert? Da haben wir offensichtlich 
verschiedene Ansichten in Bezug auf das Verhältnis von Dimensionierung 
und Komfort.

> Und eine ganze
> Menge Dinge erledigen sie trotzdem nicht. Wenn man von außerhalb der
> Container auf die Datenbanken zugreifen will, muß man sich trotzdem
> Gedanken über TCP-Ports oder UNIX-Socket Pfade machen.

Aber natürlich erledigen sie das. Wenn ich den Port 3306 im Container 
von außen zugänglich machen will, brauche ich dazu nur die Option "-p":

1

docker create -p 3306:3306 <image>

Natürlich kann ich die Ports auch auf beliebige andere Hostports mappen, 
und an beliebige IP-Adressen des Hosts binden.

> Und wie gesagt: eigentlich das trivial.

Richtig -- und mit Containern wird es sogar noch trivialer. Das ist ja 
gerade der Punkt! Warum sollte man Arbeitserleichterungen nicht nutzen, 
wenn es sie gibt?

> https://www.google.de/search?q=raspbian+mysql+tar.gz ist zu fernliegend?

Vielleicht hast Du ja ein anderes Google als ich, aber unter den ersten 
zehn Ergebnissen finde ich leider keinen Downloadlink.

>> Die "ausgezeichnete" Dokumentation (wer hat die eigentlich
>> ausgezeichnet?) ist dazu nämlich leider ein wenig schweigsam.
>
> 1. die Dokumentation von MySQL ist ausgezeichnet. Das weiß jeder, der
> sie mal benutzt hat. Und vielleicht mit der Dokumentation anderer
> Software verglichen hat.

Ich hab' sie öfter benutzt und weiß daher, daß ich die Dokumentation von 
PostgreSQL immer noch wesentlich besser finde.

Ansonsten ist mir schleierhaft, was andere Software damit zu tun hat.

> 2. da der Raspberry Pi keine unterstützte Plattform ist (weder von MySQL
> noch von MariaDB) liefert die Hersteller-Doku folgerichtig auch keine
> Hinweise auf derartige Pakete.

Schade. Die PostgreSQL-Leute sind da schon deutlich weiter und bieten 
ihre offiziellen Docker-Images für x86_64, verschiedene ARM32, ARM64, 
i386, ppc64le und s390x an -- immer auf Basis von Debian und Alpine für 
jeweils die PostgreSQL-Versionen 9.{3,4,5,6} und die aktuelle 10.2.