löscht "apt-get remove mariadb-server mariadb-client" meine db's?

S

stefkey

Member
Hi, auf meinem Ubuntu 16.04 funktioniert das update des mariadb-server nicht. Es hängt eine Weile und dann kommt:

Code: 
Setting up mariadb-server-10.0 (10.0.28-0ubuntu0.16.04.1) ...
dpkg: error processing package mariadb-server-10.0 (--configure):
 subprocess installed post-installation script returned error exit status 7
dpkg: dependency problems prevent configuration of mariadb-server:
 mariadb-server depends on mariadb-server-10.0 (>= 10.0.28-0ubuntu0.16.04.1); however:
  Package mariadb-server-10.0 is not configured yet.

dpkg: error processing package mariadb-server (--configure):
 dependency problems - leaving unconfigured
No apport report written because the error message indicates its a followup error from a previous failure.
                                                                                                          Errors were encountered while processing:
 mariadb-server-10.0
 mariadb-server
E: Sub-process /usr/bin/dpkg returned an error code (1)

Nun möchte ich den mariadb-server löschen und erneut installieren. Löscht es mir dabei meine db's eigentlich?

Ich würde mit folgendem Kommando löschen:
Code: 
apt-get remove mariadb-server mariadb-client
 
Nein, die Datenverzeichnisse bleiben bei einem "remove" bestehen. Auch Konfigurationsdateien werden von "remove" nicht entfernt.
Statt einer Neuinstallation kannst du auch nur die Konfiguration laufen lassen:
Code: 
dpkg --configure mariadb-server-10.0
Apt-get beschwert sich ja explizit darüber, dass dieses Paket nicht konfiguriert sei.
 
hey danke! Ja, aber das funktioniert auch nicht. Hier das zeigt es mir an:
Code: 
dpkg --configure mariadb-server-10.0
Setting up mariadb-server-10.0 (10.0.28-0ubuntu0.16.04.1) ...
dpkg: error processing package mariadb-server-10.0 (--configure):
 subprocess installed post-installation script returned error exit status 7
Errors were encountered while processing:
 mariadb-server-10.0

Soll ich es mal mit remove versuchen? Oder würdest du das Problem suchen. Wie?
 
Schon ein
Code: 
apt-get install --reinstall mariadb-server
probiert, um die Installation erneut durchzuführen?

Eventuell auch mal ein
Code: 
apt-get install -f
ausführen, um mögliche fehlende Abhängigkeiten aufzulösen.
 
Hast Du mal irgend etwas an den Paketquellen geändert. Das sieht nach einer zerschossenen Paketverwaltung aus.
 
Das hatte ich die letzten Wochen beim installieren und deinstallieren von mysql auf Debian Jessie auch immer mal wieder.

Hier die Holzhammermethode:

Da der DB-Server ja nicht mehr läuft und Du keinen Dump mehr ziehen kannst erst einmal vom Daten- und Konfigurationsverzeichnis(Also /etc/mysql und /var/lib/mysql) ein Backup per Kopie zu ziehen. Der MariaDB/MySQL-Prozess darf dabei nicht laufen.

Dann alle Pakete restlos löschen:

Code: 
apt-get remove --purge remove mariadb*

Die Fehlermeldungen, dass hier versucht wird ,nicht installierte Pakete zu löschen kann man ignorieren(Das Muster mariadb* greift für alle verfügbaren Pakete und nicht nur auf die installierten).

Anschliessend die Verzeichnisse löschen (rm -rf /etc/mysql /var/lib/mysql) und die Pakete wieder installieren:

Code: 
apt-get install mariadb-client mariadb-server

Damit sollte mariadb wieder laufen. Um die eigens vorher gesicherten Daten wieder einzuspielen, mariadb nochmal anhalten, das Datenverzeichnis löschen und die eigene Sicherung wieder dorthin kopieren:

Code: 
find /var/lib/mysql -type f -exec rm -f "{}" +
cp -ax /backup_mysql/. /var/lib/mysql

Nach dem erneuten Start von mariadb sollte alles wieder da sein.

----

Alternative dazu: Schauen, warum das postinstall Script fehlschlägt. Das Script befindet sich in /var/lib/dpkg/info/mariadb-server*.postinst.
 
greystone said:
Hier die Holzhammermethode:
Click to expand...

Ergänzend vielleicht noch der Hinweis, daß auch die 'Holzhammermethode' nicht unbedingt funktionieren muß!
Denn nach der Neuinstallation des Paketes läuft eine höhere version des DB-Servers als bisher und da muß es zwar nicht, kann es aber zu Problemen mit den wiedereingespielten Daten wegen möglicher Inkompatibilitäten kommen.
Im schlimmsten Fall die Methode noch etwas erweitern, indem man die bisher verwendete DB-Version installiert, die gesicherten Daten dort einspielt, dann einen normalen Dump zieht und dann erst das Upgrade auf die aktuelle Version macht.

Und für die Zukunft eine funktionierende(!) Backup-/Restorestrategie etablieren, damit man immer aktuelle Backups aller Nutzdaten zur Verfügung hat!
Funktionierende Backups sind die Lebensenergie eines guten Admins ;)
 
Wie wäre es denn mal damit, nach der Ursache des Fehlers zu suchen? Erster Ansatzpunkt wäre die mysql.log unter /var/log bzw. /var/log/mysql - oft ist es nur eine Kleinigkeit (korrupte Datenbank, eine veraltete/inkompatible Konfigurationsanweisung in der my.cnf o.ä.) die sich in den Logs bemerkbar macht. Problem beseitigen und mit
Code: 
dpkg --configure --pending
den Konfigurationsprozess noch mal anstossen.
 
Danke an alle! Gelöst!

@danton. Manchmal hilft es schon wenn jagend sagt: Schau doch mal ins log-file. Klar, frage ich mich warum ich das nicht gemacht habe :mad::confused:

Es ist eine fehlerhafte mysql Konfiguration gewesen. Ich weiß aber nicht warum diese fehlerhaft ist. Ich habe lediglich die Zeile
Code: 
default_table_type             = InnoDB
auskommentiert. Kann mir da jemand etwas zu sagen?

Code: 
...
...
# InnoDB
#    default_table_type             = InnoDB

    # 80% of ram that is dedicated for the database (this needs to be adjusted to your system)
    innodb_buffer_pool_size        = 2G
    # number of CPU cores dedicated to the MySQL InnoDB backend 
    innodb_buffer_pool_instances = 2

    innodb_data_file_path          = ibdata1:12M:autoextend
    innodb_file_per_table          = 1
    innodb_log_file_size           = 512M
    innodb_log_files_in_group      = 2

    # MyISAM
    myisam_recover                 = backup,force

    # Logging
    log_warnings                   = 2
    log_error                      = /var/log/mysql/error.log

    slow_query_log                 = 1
    slow_query_log_file            = /var/log/mysql/mysql-slow.log
    long_query_time                = 1
    log_queries_not_using_indexes  = 1
    min_examined_row_limit         = 20

    # Binary Log / Replication
    server_id                      = 1
    log-bin                        = mysql-bin
    binlog_cache_size              = 1M 
    sync_binlog                    = 8
    binlog_format                  = row
    expire_logs_days               = 7
    max_binlog_size                = 128M 
    relay-log                      = /var/log/mysql/slave-relay.log
    relay-log-index                = /var/log/mysql/slave-relay-log.index 

    [mysqldump]
    quick
    single-transaction
    max_allowed_packet             = 16M

    [mysql]
    no_auto_rehash

    [myisamchk]
    key_buffer                     = 512M
    sort_buffer_size               = 512M
    read_buffer                    = 8M
    write_buffer                   = 8M

    [mysqld_safe]
    open-files-limit               = 8192
 
You must log in or register to reply here.
Back
Top