Hallo Leute, Ich habe ein kleines Problem mit MariaDB. Da ich zwischen mehreren MySQL Versionen hin und herschalten muss, 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 sudo ps ax | grep mysql liefert: 645 ? S 0:00 /bin/bash /usr/bin/mysqld_safe 796 ? Sl 0:01 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/arm-linux-gnueabihf/mariadb18/plugin --user=mysql --skip-log-error --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --port=3048 797 ? S 0:00 logger -t mysqld -p daemon error 1819 pts/0 S+ 0:00 grep --color=auto mysql sudo find / -type s liefert: /run/mysqld/mysqld.sock Hat da jemand eine Idee?
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
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
Auf einem RPI. Ist aus der Dist und wurde auch über apg-get installiert.
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 ...
:
Bearbeitet durch User
[Exkurs] Kann ich eine bestehende MariaDB 10.0.x-Version einfach mit apt-get upgrade auf die 10.2.x aktualisieren oder gilt es da einiges zu beachten? Werden existierende Datenbank beibehalten? [/Exkurs]
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: > 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. 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?
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.