Mariadb startet nicht mehr

tim11 · March 3, 2025, 9:56am

Hallo zusammen, seit heute streikt mein mariadb. Gestern habe ich nach einem Upgrade die Paketquellen erneuert:

MariaDB Server
To use a different major version of the server, or to pin to a specific minor version, change URI below.
deb [arch=amd64,arm64] https://dlm.mariadb.com/repo/mariadb-server/11.rolling/repo/debian bookworm main

MariaDB MaxScale
To use the latest stable release of MaxScale, use “latest” as the version
To use the latest beta (or stable if no current beta) release of MaxScale, use “beta” as the version
deb [arch=amd64,arm64] https://dlm.mariadb.com/repo/maxscale/latest/apt bookworm main

MariaDB Tools
deb [arch=amd64] Tools/debian/ - MariaDB bookworm main

Apt lief fehlerfrei durch.

Heute nun streikt die db:

Mär 03 10:35:40 ***** systemd[1]: mariadb.service: Main process exited, code=exited, status=7/NOTRUNNING
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: Debian -- User Support
░░
░░ An ExecStart= process belonging to unit mariadb.service has exited.
░░
░░ The process’ exit code is ‘exited’ and its exit status is 7.
Mär 03 10:35:40 ***** systemd[1]: mariadb.service: Failed with result ‘exit-code’.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: Debian -- User Support
░░
░░ The unit mariadb.service has entered the ‘failed’ state with result ‘exit-code’.
Mär 03 10:35:40 ***** systemd[1]: Failed to start mariadb.service - MariaDB 11.7.2 database server.
░░ Subject: A start job for unit mariadb.service has failed
░░ Defined-By: systemd
░░ Support: Debian -- User Support
░░
░░ A start job for unit mariadb.service has finished with a failure.

Warning: The unit file, source configuration file or drop-ins of mariadb.service changed on disk. Run ‘systemctl daemon-reload’ to reload units.
× mariadb.service - MariaDB 11.7.2 database server
Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; preset: enabled)
Drop-In: /etc/systemd/system/mariadb.service.d
└─migrated-from-my.cnf-settings.conf
Active: failed (Result: exit-code) since Mon 2025-03-03 10:43:26 CET; 25s ago
Docs: man:mariadbd(8)
systemd - MariaDB Knowledge Base
Process: 6617 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
Process: 6618 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= || VAR=/usr/bin/galera_recovery; [ $? -eq 0 ] && echo _WSREP_START_POSITION=$VAR > /run/mysqld/wsrep-start-position || e>
Process: 6670 ExecStart=/usr/sbin/mariadbd $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=7)
Main PID: 6670 (code=exited, status=7)
Status: “MariaDB server is down”
CPU: 669ms

Mär 03 10:43:25 **** mariadbd[6670]: 2025-03-03 10:43:25 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
Mär 03 10:43:25 **** mariadbd[6670]: 2025-03-03 10:43:25 0 [ERROR] /usr/sbin/mariadbd: unknown variable ‘provider_bzip2=force_plus_permanent’
Mär 03 10:43:25 **** mariadbd[6670]: 2025-03-03 10:43:25 0 [ERROR] /usr/sbin/mariadbd: unknown variable ‘provider_lz4=force_plus_permanent’
Mär 03 10:43:25 **** mariadbd[6670]: 2025-03-03 10:43:25 0 [ERROR] /usr/sbin/mariadbd: unknown variable ‘provider_lzma=force_plus_permanent’
Mär 03 10:43:25 **** mariadbd[6670]: 2025-03-03 10:43:25 0 [ERROR] /usr/sbin/mariadbd: unknown variable ‘provider_lzo=force_plus_permanent’
Mär 03 10:43:25 **** mariadbd[6670]: 2025-03-03 10:43:25 0 [ERROR] /usr/sbin/mariadbd: unknown variable ‘provider_snappy=force_plus_permanent’
Mär 03 10:43:25 **** mariadbd[6670]: 2025-03-03 10:43:25 0 [ERROR] Aborting
Mär 03 10:43:26 **** systemd[1]: mariadb.service: Main process exited, code=exited, status=7/NOTRUNNING
Mär 03 10:43:26 **** systemd[1]: mariadb.service: Failed with result ‘exit-code’.
Mär 03 10:43:26 **** systemd[1]: Failed to start mariadb.service - MariaDB 11.7.2 database server.

Somit streikt Nextcloud. Alles läuft auf einem Nuc mit Debian bookworm

Das übersteigt jetzt doch mein Wissen, kann ich das irgendwie fixen oder muss ich maria nochmal neu installieren?

Vielen Dank

PS: zwecks besserer Darstellung habe ich die Rautenzeichen hier gelöscht, da sie im Post in riesengroßer Schrift erscheinen. In den Scripten sind die natürlich vorhanden

devnull · March 3, 2025, 10:20am

Ich hoffe du hast ein Backup deiner MariaDB-Datenbank. Wenn nicht dann sichere jetzt selbst wo die Datenbank nicht läuft das gesamte Verzeichnis /var/lib/mysql. Vielleicht wirst du es noch einmal brauchen.

Als root:
tar -czvf /root/backup-mysql.tar.gz /var/lib/mysql
oder nicht gezippt:
tar -cvf /root/backup-mysql.tar /var/lib/mysql

Wenn das dein Wissen übersteigt verstehe ich nicht, warum du MariaDB aus einer Fremdquelle installierst. Obwohl ich Debian seit Jahrzehnten (!!!) nutze, habe ich das noch nie für MySQL oder MariaDB gemacht. Gleiches gilt im Übrigen für PHP. Es ist für normale Anwender praktisch vollkommen unnötig jemals für eine Nextcloud-Installation eine Fremdquelle für MariaDB, PHP, … zu verwenden. Das macht man vielleicht bei Windows, um Software aktuell zu halten.

Ich weiß nicht, ob du einfach die Pakete deinstallieren kannst, die Paketquellen rauswerfen kannst und über die normalen Paketquellen MariaDB einfach wieder installierst.

Nur als Idee. Installiere apt-show-versions und schau, was nicht zu Debian Bookworm gehört:

apt-show-versions |grep -v bookworm

Versuch das Zeug was mit MySQ und MariaDB zu tun hat loszuwerden. Poste evtl. vorher die Ausgabe. Nach Deinstallation der Pakete entferne die Quellen aus den Paketlisten. Nutze apt-get update zur Aktualiserung der Paketquellen. Versuch die Pakete aus den Originalquellen wieder zu installieren.

MaxScale kenne ich nicht. Oder brauchst du das wirklich auf deinem Nuc?
Galera-Cluster kenne ich auch nicht. Brauchst du das wirklich auf deinem Nuc?

Vielleicht habe ich aber auch alles falsch verstanden. Warte vielleicht besser auf bessere Antworten.

tim11 · March 3, 2025, 10:42am

Guten Morgen,

danke für Deine schnelle Hilfe

Backup der db läuft jeden Tag per cronjob

Die Frage warum es über Fremdquellen läuft: vereinfacht weil es damals in der Installationsanleitung so beschrieben war. Einen eigenen Debianserver mit Nextcloud, nginx und maria installieren die wenigsten User aus dem Kopf. Der Server läuft nun auf diese Weise inzwischen seit fast 10 Jahren, wobei ich seit 4 Jahren relativ wenig daran mache, da mir aus beruflichen und familiären Gründen die Zeit fehlt. Das war halt damals ein Testserver zum Üben und wurde aus den Jahre zu einer Cloud mit DNS Server und gehosteter Homepage, aber die letzten Jahre habe ich leider viel Wissen verloren.
Dies kurz zum Hintergrund.

Ich würde eine Reparatur der Pakete bevorzugen, weil im Hintergrund halt viel hängt, etwa Sync per DAVx auf dem Smartphone usw. und bin mir nicht sicher, was ich alles neu einrichten muss, wenn ich maria komplett neu aufspiele.
Ich hätte kein Problem, wenn ich die Paketquellen später switche, sobald es wieder läuft. Früher hätte ich da so lange rumgetestet, bis ich eine Lösung gefunden hätte. Heute habe ich Familie und Arbeit und somit wenig Zeit

debsuryorg-archive-keyring:all/bullseye 2024.02.05+0~20240205.1+debian11~1.gbp343037 uptodate
galera-4:arm64 not installed
gcc-10-base:amd64 10.2.1-6 installed: No available version in archive
gcc-9-base:amd64 9.3.0-22 installed: No available version in archive
libabsl20200923:amd64 0~20200923.3-2 installed: No available version in archive
libapache2-mod-php8.1:amd64/bullseye 8.1.31-1+0~20241121.67+debian11~1.gbp9e3dc4 uptodate
libapache2-mod-php8.2:amd64/bullseye 8.2.27-1+0~20241224.69+debian11~1.gbp7d3194 uptodate
libavif9:amd64 0.8.4-2+deb11u1 installed: No available version in archive
libbpf0:amd64 1:0.3-2 installed: No available version in archive
libdav1d4:amd64 0.7.1-3 installed: No available version in archive
libdns-export1110:amd64 1:9.11.19+dfsg-2.1 installed: No available version in archive
libffi7:amd64 3.3-6 installed: No available version in archive
libgav1-0:amd64 0.16.0-5 installed: No available version in archive
libgd3:amd64/bullseye 2.3.3-12+0~20240711.16+debian11~1.gbpd0ea70 uptodate
libicu67:amd64 67.1-7 installed: No available version in archive
libisc-export1105:amd64 1:9.11.19+dfsg-2.1 installed: No available version in archive
libldap-2.4-2:amd64 2.4.57+dfsg-3+deb11u1 installed: No available version in archive
libmariadb3:arm64 not installed
libpcre3:amd64/bullseye 2:8.45-1+0~20230620.10+debian11~1.gbp8792c4 uptodate
libprocps8:amd64 2:3.3.17-5 installed: No available version in archive
libsepol1:amd64 3.1-1 installed: No available version in archive
libssl1.1:amd64 1.1.1w-0+deb11u1 installed: No available version in archive
libtiff5:amd64 4.2.0-1+deb11u4 installed: No available version in archive
libwebp6:amd64 0.6.1-2.1+deb11u2 installed: No available version in archive
mariadb-client:arm64 not installed
mariadb-client-core:arm64 not installed
mariadb-server:arm64 not installed
mariadb-server-core:arm64 not installed
netcat:all 1.10-46 installed: No available version in archive
nginx:amd64 1.27.0-2~bullseye newer than version in archive
php-apcu:all/bullseye 5.1.24-1+0~20241124.41+debian11~1.gbpff678c uptodate
php-apcu:amd64 not installed
php-cgi:all/bullseye 2:8.3+95+0~20240927.54+debian11~1.gbpe0084c uptodate
php-common:all/bullseye 2:95+0~20240927.54+debian11~1.gbpe0084c uptodate
php-curl:all/bullseye 2:8.3+95+0~20240927.54+debian11~1.gbpe0084c uptodate
php-fpm:all/bullseye 2:8.3+95+0~20240927.54+debian11~1.gbpe0084c uptodate
php-gd:all/bullseye 2:8.3+95+0~20240927.54+debian11~1.gbpe0084c uptodate
php-mbstring:all/bullseye 2:8.3+95+0~20240927.54+debian11~1.gbpe0084c uptodate
php-sqlite3:all/bullseye 2:8.3+95+0~20240927.54+debian11~1.gbpe0084c uptodate
php-xml:all/bullseye 2:8.3+95+0~20240927.54+debian11~1.gbpe0084c uptodate
php-zip:all/bullseye 2:8.3+95+0~20240927.54+debian11~1.gbpe0084c uptodate
php8.0-apcu:amd64/bullseye 5.1.24-1+0~20241124.41+debian11~1.gbpff678c uptodate
php8.0-bcmath:amd64/bullseye 1:8.0.30-12+0~20241224.69+debian11~1.gbp8bbec7 uptodate
php8.0-bz2:amd64/bullseye 1:8.0.30-12+0~20241224.69+debian11~1.gbp8bbec7 uptodate
php8.0-cgi:amd64/bullseye 1:8.0.30-12+0~20241224.69+debian11~1.gbp8bbec7 uptodate
php8.0-cli:amd64/bullseye 1:8.0.30-12+0~20241224.69+debian11~1.gbp8bbec7 uptodate
php8.0-common:amd64/bullseye 1:8.0.30-12+0~20241224.69+debian11~1.gbp8bbec7 uptodate
php8.0-curl:amd64/bullseye 1:8.0.30-12+0~20241224.69+debian11~1.gbp8bbec7 uptodate
php8.0-fpm:amd64/bullseye 1:8.0.30-12+0~20241224.69+debian11~1.gbp8bbec7 uptodate
php8.0-gd:amd64/bullseye 1:8.0.30-12+0~20241224.69+debian11~1.gbp8bbec7 uptodate
php8.0-gmp:amd64/bullseye 1:8.0.30-12+0~20241224.69+debian11~1.gbp8bbec7 uptodate
php8.0-igbinary:amd64/bullseye 3.2.16-3+0~20241125.52+debian11~1.gbp2adcb2 uptodate
php8.0-imagick:amd64/bullseye 3.7.0-9+0~20241126.47+debian11~1.gbp7df923 uptodate
php8.0-intl:amd64/bullseye 1:8.0.30-12+0~20241224.69+debian11~1.gbp8bbec7 uptodate
php8.0-ldap:amd64/bullseye 1:8.0.30-12+0~20241224.69+debian11~1.gbp8bbec7 uptodate
php8.0-mbstring:amd64/bullseye 1:8.0.30-12+0~20241224.69+debian11~1.gbp8bbec7 uptodate
php8.0-mysql:amd64/bullseye 1:8.0.30-12+0~20241224.69+debian11~1.gbp8bbec7 uptodate
php8.0-opcache:amd64/bullseye 1:8.0.30-12+0~20241224.69+debian11~1.gbp8bbec7 uptodate
php8.0-readline:amd64/bullseye 1:8.0.30-12+0~20241224.69+debian11~1.gbp8bbec7 uptodate
php8.0-redis:amd64/bullseye 6.1.0-2+0~20241127.62+debian11~1.gbp5ec001 uptodate
php8.0-smbclient:amd64/bullseye 1.1.2-2+0~20241126.30+debian11~1.gbpb221e0 uptodate
php8.0-sqlite3:amd64/bullseye 1:8.0.30-12+0~20241224.69+debian11~1.gbp8bbec7 uptodate
php8.0-xml:amd64/bullseye 1:8.0.30-12+0~20241224.69+debian11~1.gbp8bbec7 uptodate
php8.0-zip:amd64/bullseye 1:8.0.30-12+0~20241224.69+debian11~1.gbp8bbec7 uptodate
php8.1:all/bullseye 8.1.31-1+0~20241121.67+debian11~1.gbp9e3dc4 uptodate
php8.1-cli:amd64/bullseye 8.1.31-1+0~20241121.67+debian11~1.gbp9e3dc4 uptodate
php8.1-common:amd64/bullseye 8.1.31-1+0~20241121.67+debian11~1.gbp9e3dc4 uptodate
php8.1-curl:amd64/bullseye 8.1.31-1+0~20241121.67+debian11~1.gbp9e3dc4 uptodate
php8.1-gd:amd64/bullseye 8.1.31-1+0~20241121.67+debian11~1.gbp9e3dc4 uptodate
php8.1-ldap:amd64/bullseye 8.1.31-1+0~20241121.67+debian11~1.gbp9e3dc4 uptodate
php8.1-mysql:amd64/bullseye 8.1.31-1+0~20241121.67+debian11~1.gbp9e3dc4 uptodate
php8.1-opcache:amd64/bullseye 8.1.31-1+0~20241121.67+debian11~1.gbp9e3dc4 uptodate
php8.1-readline:amd64/bullseye 8.1.31-1+0~20241121.67+debian11~1.gbp9e3dc4 uptodate
php8.1-xml:amd64/bullseye 8.1.31-1+0~20241121.67+debian11~1.gbp9e3dc4 uptodate
php8.1-zip:amd64/bullseye 8.1.31-1+0~20241121.67+debian11~1.gbp9e3dc4 uptodate
php8.2-apcu:amd64/bullseye 5.1.24-1+0~20241124.41+debian11~1.gbpff678c uptodate
php8.2-bcmath:amd64/bullseye 8.2.27-1+0~20241224.69+debian11~1.gbp7d3194 uptodate
php8.2-bz2:amd64/bullseye 8.2.27-1+0~20241224.69+debian11~1.gbp7d3194 uptodate
php8.2-cgi:amd64/bullseye 8.2.27-1+0~20241224.69+debian11~1.gbp7d3194 uptodate
php8.2-cli:amd64/bullseye 8.2.27-1+0~20241224.69+debian11~1.gbp7d3194 uptodate
php8.2-common:amd64/bullseye 8.2.27-1+0~20241224.69+debian11~1.gbp7d3194 uptodate
php8.2-curl:amd64/bullseye 8.2.27-1+0~20241224.69+debian11~1.gbp7d3194 uptodate
php8.2-fpm:amd64/bullseye 8.2.27-1+0~20241224.69+debian11~1.gbp7d3194 uptodate
php8.2-gd:amd64/bullseye 8.2.27-1+0~20241224.69+debian11~1.gbp7d3194 uptodate
php8.2-gmp:amd64/bullseye 8.2.27-1+0~20241224.69+debian11~1.gbp7d3194 uptodate
php8.2-igbinary:amd64/bullseye 3.2.16-3+0~20241125.52+debian11~1.gbp2adcb2 uptodate
php8.2-imagick:amd64/bullseye 3.7.0-9+0~20241126.47+debian11~1.gbp7df923 uptodate
php8.2-intl:amd64/bullseye 8.2.27-1+0~20241224.69+debian11~1.gbp7d3194 uptodate
php8.2-ldap:amd64/bullseye 8.2.27-1+0~20241224.69+debian11~1.gbp7d3194 uptodate
php8.2-mbstring:amd64/bullseye 8.2.27-1+0~20241224.69+debian11~1.gbp7d3194 uptodate
php8.2-mysql:amd64/bullseye 8.2.27-1+0~20241224.69+debian11~1.gbp7d3194 uptodate
php8.2-opcache:amd64/bullseye 8.2.27-1+0~20241224.69+debian11~1.gbp7d3194 uptodate
php8.2-phpdbg:amd64/bullseye 8.2.27-1+0~20241224.69+debian11~1.gbp7d3194 uptodate
php8.2-readline:amd64/bullseye 8.2.27-1+0~20241224.69+debian11~1.gbp7d3194 uptodate
php8.2-redis:amd64/bullseye 6.1.0-2+0~20241127.62+debian11~1.gbp5ec001 uptodate
php8.2-smbclient:amd64/bullseye 1.1.2-2+0~20241126.30+debian11~1.gbpb221e0 uptodate
php8.2-xml:amd64/bullseye 8.2.27-1+0~20241224.69+debian11~1.gbp7d3194 uptodate
php8.2-zip:amd64/bullseye 8.2.27-1+0~20241224.69+debian11~1.gbp7d3194 uptodate
php8.3-cgi:amd64/bullseye 8.3.17-1+0~20250215.52+debian11~1.gbp601917 uptodate
php8.3-cli:amd64/bullseye 8.3.17-1+0~20250215.52+debian11~1.gbp601917 uptodate
php8.3-common:amd64/bullseye 8.3.17-1+0~20250215.52+debian11~1.gbp601917 uptodate
php8.3-curl:amd64/bullseye 8.3.17-1+0~20250215.52+debian11~1.gbp601917 uptodate
php8.3-fpm:amd64/bullseye 8.3.17-1+0~20250215.52+debian11~1.gbp601917 uptodate
php8.3-gd:amd64/bullseye 8.3.17-1+0~20250215.52+debian11~1.gbp601917 uptodate
php8.3-mbstring:amd64/bullseye 8.3.17-1+0~20250215.52+debian11~1.gbp601917 uptodate
php8.3-opcache:amd64/bullseye 8.3.17-1+0~20250215.52+debian11~1.gbp601917 uptodate
php8.3-readline:amd64/bullseye 8.3.17-1+0~20250215.52+debian11~1.gbp601917 uptodate
php8.3-sqlite3:amd64/bullseye 8.3.17-1+0~20250215.52+debian11~1.gbp601917 uptodate
php8.3-xml:amd64/bullseye 8.3.17-1+0~20250215.52+debian11~1.gbp601917 uptodate
php8.3-zip:amd64/bullseye 8.3.17-1+0~20250215.52+debian11~1.gbp601917 uptodate
php8.4-apcu:amd64/bullseye 5.1.24-1+0~20241124.41+debian11~1.gbpff678c uptodate
php8.4-cli:amd64/bullseye 8.4.4-1+0~20250215.23+debian11~1.gbp9a7680 uptodate
php8.4-common:amd64/bullseye 8.4.4-1+0~20250215.23+debian11~1.gbp9a7680 uptodate
php8.4-opcache:amd64/bullseye 8.4.4-1+0~20250215.23+debian11~1.gbp9a7680 uptodate
php8.4-phpdbg:amd64/bullseye 8.4.4-1+0~20250215.23+debian11~1.gbp9a7680 uptodate
php8.4-readline:amd64/bullseye 8.4.4-1+0~20250215.23+debian11~1.gbp9a7680 uptodate

devnull · March 3, 2025, 12:52pm

Leider hast du versäumt für den Code-Block den zugehörigen aufgeführten Befehl anzugeben. Gebe immer den Befehl und die Ausgabe an.

Ich frage mich ein wenig, warum dort PHP8.0, PHP8.1, PHP8.2, PHP8.3 und PHP8.4 vorkommt. Bei Debian Bookworm ist nur PHP8.2 enthalten siehe z. B. hier.

Bei einer Standardinstallation hätte man mit Debian Bookworm nur PHP8.2. Hier mal eine Anleitung, die empfohlen hätte.

tim11 · March 3, 2025, 1:37pm

Eingabe war wie von Dir gepostet, also

@:~$ apt-show-versions |grep -v bookworm

(ohne sudo)

Zum Thema php: die Installation ist wie schon erwähnt etwas älter, ich glaube ich habe den Server seit 2016, zwischenzeitlich ein Mal neu aufgesetzt. Entsprechend hat er auch schon einige Versionen von Nextcloud gesehen, und teilweise haben Versionssprünge von Nextcloud eine andere php Version vorausgesetzt.

Ich hätte kein Problem damit, wenn ich das System in Ruhe nebenher mal neu aufsetzte, allerdings halt im Parallelbetrieb, schon alleine meinen Kalender in Nextcloud würde ich echt vermissen, auch den automatischen Upload von Bildern am Smartphone.

Daher wäre es super, wenn ich die aktuelle Version irgendwie fixen könnte und dann in Ruhe eine neue Installation aufsetzen, habe noch einen neueren NUC hier, auf dem aktuell Libreelec läuft.
Ist es möglich, dass ich die mariadb.list aus der sources.list.d auf die offiziellen Paketquellen aus dem Repository switche?

devnull · March 3, 2025, 1:43pm

Falls du mal was probieren willst. Du könntest in /pfad/zur/nextcloud/config/config.php mal schauen welche genaue Nextcloud-Version du hast. Du könntest dann im Parallelbetrieb genau die Version installieren schaue dafür hier. Lege deinen alten Benutzer auf dem neuen Testsystem wieder an. Spiele das hoffentlich existieren Backup der Datenbank auf dem Testsystem ein. Kopiere gerne die Dateien /pfad/zur/nextcloud/data/username oder auch nicht. Lass sudo -u www-data php /pfad/zur/nextcloud/occ files:scan --all durchlaufen. Nutze das Parallelsystem zum testen. Verzichte wenn möglich auf Fremdquellen. Mit etwas Glück kannst du es dort zum laufen bringen. Schau auch noch Backup und Restore.

Ich denke schon, dass man dein altes System bereinigen kann. Aber das lässt sich in einem Forum kaum diskutieren. Vielleicht hast du auch viele alte Konfigurationen, die einfach gelöscht werden müssen.

dpkg -l |grep "^rc"
Dokumenation

tim11 · March 3, 2025, 1:55pm

Meine NC Version ist

‘version’ => ‘30.0.6.2’,

Wäre es möglich dass ich mariadb per apt neu installiere? Eigentlich dürfte es meine db für Nextcloud nicht löschen und müsste danach automatisch integriert werden. Wenn ich es aus dem Repository installiere und die mariadb.list danach lösche, müsste es doch eigentlich auch die config für die Paketquellen neu schreiben, oder sehe ich das falsch? Oder gibt es dann Probleme mit einer Parallelinstallation?

Ein Testbestrieb auf einem parallelen NUC ist halt eine Zeitfrage, ich würde es riskieren dass ich maria neu installiere, mehr als nicht laufen kann es ja irgendwie nicht.

tim11 · March 3, 2025, 2:06pm

root@****:/etc/apt/sources.list.d# rc libpython3.9-minimal:amd64 rc linux-image-5.10.0-10-amd64 rc linux-image-5.10.0-11-amd64 rc linux-image-5.10.0-12-amd64 rc linux-image-5.10.0-13-amd64 rc linux-image-5.10.0-14-amd64 rc linux-image-5.10.0-15-amd64 rc linux-image-5.10.0-16-amd64 rc linux-image-5.10.0-17-amd64 rc linux-image-5.10.0-18-amd64 rc linux-image-5.10.0-19-amd64 rc linux-image-5.10.0-20-amd64 rc linux-image-5.10.0-21-amd64 rc linux-image-5.10.0-22-amd64 rc linux-image-5.10.0-23-amd64 rc linux-image-5.10.0-24-amd64 rc linux-image-5.10.0-25-amd64 rc linux-image-5.10.0-26-amd64 rc linux-image-5.10.0-8-amd64 rc linux-image-6.1.0-13-amd64 rc linux-image-6.1.0-14-amd64 rc linux-image-6.1.0-15-amd64 rc linux-image-6.1.0-16-amd64 rc linux-image-6.1.0-17-amd64 rc linux-image-6.1.0-18-amd64 rc linux-image-6.1.0-20-amd64 rc linux-image-6.1.0-21-amd64 rc linux-image-6.1.0-22-amd64 rc linux-image-6.1.0-23-amd64 rc linux-image-6.1.0-25-amd64 rc linux-image-6.1.0-26-amd64 rc linux-image-6.1.0-27-amd64 rc linux-image-6.1.0-28-amd64 rc linux-image-6.1.0-29-amd64 rc mariadb-client-10.6 rc mariadb-plugin-provider-bzip2 rc mariadb-plugin-provider-lz4 rc mariadb-plugin-provider-lzma rc mariadb-plugin-provider-lzo rc mariadb-plugin-provider-snappy rc mariadb-server-10.6 rc php7.4-apcu rc php7.4-apcu-bc rc php7.4-cli rc php7.4-common rc php7.4-json rc php7.4-opcache rc php7.4-phpdbg rc php7.4-readline rc php8.1-apcu rc php8.1-cgi rc php8.1-fpm rc php8.1-mbstring rc php8.1-sqlite3 rc php8.2-sqlite3 rc php8.3-apcu rc php8.3-phpdbg rc python3.9-minimal dpkg -l |grep “^rc”
3.9.2-1 amd64 Minimal subset of the Python language (version 3.9)
5.10.84-1 amd64 Linux 5.10 for 64-bit PCs (signed)
5.10.92-2 amd64 Linux 5.10 for 64-bit PCs (signed)
5.10.103-1 amd64 Linux 5.10 for 64-bit PCs (signed)
5.10.106-1 amd64 Linux 5.10 for 64-bit PCs (signed)
5.10.113-1 amd64 Linux 5.10 for 64-bit PCs (signed)
5.10.120-1 amd64 Linux 5.10 for 64-bit PCs (signed)
5.10.127-2 amd64 Linux 5.10 for 64-bit PCs (signed)
5.10.136-1 amd64 Linux 5.10 for 64-bit PCs (signed)
5.10.140-1 amd64 Linux 5.10 for 64-bit PCs (signed)
5.10.149-2 amd64 Linux 5.10 for 64-bit PCs (signed)
5.10.158-2 amd64 Linux 5.10 for 64-bit PCs (signed)
5.10.162-1 amd64 Linux 5.10 for 64-bit PCs (signed)
5.10.178-3 amd64 Linux 5.10 for 64-bit PCs (signed)
5.10.179-3 amd64 Linux 5.10 for 64-bit PCs (signed)
5.10.179-5 amd64 Linux 5.10 for 64-bit PCs (signed)
5.10.191-1 amd64 Linux 5.10 for 64-bit PCs (signed)
5.10.197-1 amd64 Linux 5.10 for 64-bit PCs (signed)
5.10.46-5 amd64 Linux 5.10 for 64-bit PCs (signed)
6.1.55-1 amd64 Linux 6.1 for 64-bit PCs (signed)
6.1.64-1 amd64 Linux 6.1 for 64-bit PCs (signed)
6.1.66-1 amd64 Linux 6.1 for 64-bit PCs (signed)
6.1.67-1 amd64 Linux 6.1 for 64-bit PCs (signed)
6.1.69-1 amd64 Linux 6.1 for 64-bit PCs (signed)
6.1.76-1 amd64 Linux 6.1 for 64-bit PCs (signed)
6.1.85-1 amd64 Linux 6.1 for 64-bit PCs (signed)
6.1.90-1 amd64 Linux 6.1 for 64-bit PCs (signed)
6.1.94-1 amd64 Linux 6.1 for 64-bit PCs (signed)
6.1.99-1 amd64 Linux 6.1 for 64-bit PCs (signed)
6.1.106-3 amd64 Linux 6.1 for 64-bit PCs (signed)
6.1.112-1 amd64 Linux 6.1 for 64-bit PCs (signed)
6.1.115-1 amd64 Linux 6.1 for 64-bit PCs (signed)
6.1.119-1 amd64 Linux 6.1 for 64-bit PCs (signed)
6.1.123-1 amd64 Linux 6.1 for 64-bit PCs (signed)
1:10.6.15+maria~deb11 amd64 MariaDB database client binaries
1:11.7.2+maria~deb12 amd64 BZip2 compression support in the server and storage engines
1:11.7.2+maria~deb12 amd64 LZ4 compression support in the server and storage engines
1:11.7.2+maria~deb12 amd64 LZMA compression support in the server and storage engines
1:11.7.2+maria~deb12 amd64 LZO compression support in the server and storage engines
1:11.7.2+maria~deb12 amd64 Snappy compression support in the server and storage engines
1:10.6.15+maria~deb11 amd64 MariaDB database server binaries
5.1.21+4.0.11-8+0~20220625.32+debian11~1.gbpa7cde5 amd64 APC User Cache for PHP
1.0.5-14+0~20211115.22+debian11~1.gbpa00758 amd64 APCu Backwards Compatibility Module
1:7.4.30-3+0~20220627.69+debian11~1.gbpf2b381 amd64 command-line interpreter for the PHP scripting language
1:7.4.30-3+0~20220627.69+debian11~1.gbpf2b381 amd64 documentation, examples and common module for PHP
1:7.4.30-3+0~20220627.69+debian11~1.gbpf2b381 amd64 JSON module for PHP
1:7.4.30-3+0~20220627.69+debian11~1.gbpf2b381 amd64 Zend OpCache module for PHP
1:7.4.30-3+0~20220627.69+debian11~1.gbpf2b381 amd64 server-side, HTML-embedded scripting language (PHPDBG binary)
1:7.4.30-3+0~20220627.69+debian11~1.gbpf2b381 amd64 readline module for PHP
5.1.22+4.0.11-2+0~20221209.34+debian11~1.gbp2b07cb amd64 APC User Cache for PHP
8.1.13-1+0~20221126.29+debian11~1.gbpfee7cc amd64 server-side, HTML-embedded scripting language (CGI binary)
8.1.13-1+0~20221126.29+debian11~1.gbpfee7cc amd64 server-side, HTML-embedded scripting language (FPM-CGI binary)
8.1.13-1+0~20221126.29+debian11~1.gbpfee7cc amd64 MBSTRING module for PHP
8.1.13-1+0~20221126.29+debian11~1.gbpfee7cc amd64 SQLite3 module for PHP
8.2.14-1+0~20231221.38+debian11~1.gbp698136 amd64 SQLite3 module for PHP
5.1.24-1+0~20241124.41+debian11~1.gbpff678c amd64 APC User Cache for PHP
8.3.17-1+0~20250215.52+debian11~1.gbp601917 amd64 server-side, HTML-embedded scripting language (PHPDBG binary)
3.9.2-1 amd64 Minimal subset of the Python language (version 3.9)

devnull · March 3, 2025, 2:12pm

Ich denke die Konfigurationen (alles beginnend mit rc) kannst du schon mal löschen. Dann ist es schon mal etwas aufgeräumter:
apt-get purge $(dpkg -l | awk '/^rc/ { print $2 }')

tim11 · March 3, 2025, 2:30pm

Ich glaub es nicht, nach purge war die Liste leer, mariadb per systemctl neu gestartet und keine Fehlermeldung:

root@:/home/ systemctl status mariadb.service
● mariadb.service - MariaDB 11.7.2 database server
Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; preset: enabled)
Drop-In: /etc/systemd/system/mariadb.service.d
└─migrated-from-my.cnf-settings.conf
Active: active (running) since Mon 2025-03-03 15:23:36 CET; 50s ago
Docs: man:mariadbd(8)
systemd - MariaDB Knowledge Base
Process: 18167 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
Process: 18168 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= || VAR=/usr/bin/galera_recovery; [ $? -eq 0 ] && echo _WSREP_START_POSITION=$VAR > /run/mysqld/wsrep-start-position || >
Process: 18200 ExecStartPost=/bin/rm -f /run/mysqld/wsrep-start-position (code=exited, status=0/SUCCESS)
Process: 18201 ExecStartPost=/etc/mysql/debian-start (code=exited, status=0/SUCCESS)
Main PID: 18190 (mariadbd)
Status: “Taking your SQL requests now…”
Tasks: 13 (limit: 26092)
Memory: 283.2M
CPU: 24.169s
CGroup: /system.slice/mariadb.service
└─18190 /usr/sbin/mariadbd

Mär 03 15:23:24 *** mariadbd[18190]: 2025-03-03 15:23:24 0 [Note] Plugin ‘wsrep-provider’ is disabled.
Mär 03 15:23:24 *** mariadbd[18190]: 2025-03-03 15:23:24 0 [Note] InnoDB: Buffer pool(s) load completed at 250303 15:23:24
Mär 03 15:23:36 *** mariadbd[18190]: 2025-03-03 15:23:36 0 [Note] Server socket created on IP: ‘127.0.0.1’.

Vermutlich hat es nach dem Script von gestern eine neue Version von maria aufgespielt, die nun mit der alten kollidiert ist und nach dem löschen nun wieder funktioniert.

Herrlich, Anmeldung bei Nextcloud geht ohne Probleme, Sync läuft von heute durch. Ich kann Dir für Deine Hilfe nicht genug danken, Du bist mein Faschingheld des Jahres, tausend Dank für Deine Hilfe!

devnull · March 3, 2025, 2:35pm

Kein Problem. Aber damit habe ich nun gar nicht gerechnet.

Sehr wichtig:
a.) Mach jetzt ein neues Backup aus Dateien und Datenbankdump
b.) Teste das Backup auch mal aus → Restore auf Testsystem

tim11 · March 3, 2025, 2:40pm

Danke. Eigentlich sichere ich per cron die sda, auf der das os liegt, monatlich auf einem USB Stick, allerdings bin ich gerade dabei per dd eine komplette Spiegelung der SSD zu machen, danach schaue ich in Ruhe ob alles wieder normal läuft und installiere auf den neuen NUC eine komplett frische Installation.

devnull · March 3, 2025, 2:43pm

Mache auf jeden Fall auch einen Datenbankdump. Leg ihn einfach vor dem Backup mit auf der Platte ab. Schau hier.

mysqldump --single-transaction -h [server] -u [username] -p[password] [db_name] > nextcloud-sqlbkp_date +“%Y%m%d”.bak

mysqldump gehört zum Paket mariadb-client.

tim11 · March 3, 2025, 2:45pm

In Nextcloud sehe ich jetzt dass es eine neue Version von maria aufgespielt hat:

MariaDB-Version “11.7.2-MariaDB-deb12” erkannt. Für optimale Leistung, Stabilität und Funktionalität mit dieser Version von Nextcloud wird MariaDB >= 10.6 und 11.4 <= empfohlen.

devnull · March 3, 2025, 2:46pm

Mag ja alles sein. Bei mir läuft Debian Bookworm und da gibt es aktuell Debian -- Details of package mariadb-server in bookworm evtl. mit Sicherheitsupdates. Eine neue Version gibt es wieder mit Debian Trixie. Vorher passiert auf meinen Debian-Systemen vor allen eins: nichts.

Debian Bookworm mariadb-server
Paket: mariadb-server (1:10.11.6-0+deb12u1)

tim11 · March 3, 2025, 2:51pm

Backup ist wie schon erwähnt per cron täglich eingerichtet:

mysqldump --lock-tables -u *** -p*** nextclouddb > “/mnt/backup/backup_db/backup$(date +%Y-%m-%d-%H.%M.%S).sql”

Und ja, auf meinem neuen System werde ich alles nach repository installieren. Sobald ich die SSD gespiegelt habe, kann ich mal vorsichtig testen ob ich die verbleibenden Installationen, die noch die Fremdquellen arbeiten (php, maria und nginx) auf repository umstelle, aber aktuell bin ich erst mal froh dass alles läuft und wenn die Spiegelung komplett durch ist.

Newling · March 9, 2025, 3:33pm

Hi, ich komm zwar etwas spät zu dieser Party, will aber meinen Senf noch dazugeben.
Ich hatte vor kurzem auch Streß mit der MariaDB in der Nextcloud lief.
(das eigentliche Problem war: eine Qnap deren Platte Lesefehler hatte und deshalb nicht gemoutet wurde). Ich konnte zwar die Platte noch von Hand mounten und die Daten aus dem MariaDB Verzeichnis rauskopieren, aber mehr auch nicht. MariadB konnte nicht starten, weil die Platte sich nur im Read-Only Modus von mir mounten lies).

Versuch: auf einem anderen Server (alles Bookworm) eine bestehenden MariaDB das Verzeichnis unter die Nase halten und versuchen zu Starten.
Das hat tatsächlich auf einem Server funktioniert und ich konnte über Nextcloud den für mich wichtigen Kalender exportieren.

Im nächsten Schritt wurde Nextcloud in aktueller Version und MariaDB in aktueller Version (immer aus Debian Standard Paketquellen) neu installiert.
Jetzt konnte ich den exportierten Kalender wieder importieren.

Zusammenfassung: wenn nur eine der Versionen (entweder Nextcloud oder MariadB) nicht mit dem Ursprung übereinstimmt, klappt es nicht.
Ein Export/Import funktioniert aber sehr gut, dabei übernimmt die Import-Version die Aufgabe falsche Tabelle/Spalten anzupassen.

Gruß
Andi

system · March 17, 2025, 3:34pm

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.