it-swarm.com.de

MariaDB Protokoll kann nicht initiiert werden

Ich habe jede Lösung im Internet ausprobiert, aber mein MariaDb-Server fällt weiterhin aus, verrät mich weiterhin und zerstört weiterhin meine winzige DevOps-Welt. Meine Versuche, die Situation zu glätten, beinhalteten alle Arten von Zufriedenheit: Ändern von Berechtigungen, Konfigurationen, Entfernen von Protokolldateien, Aktualisieren/Neuinstallieren, Verschieben ihrer internen Dateien nach oben und herum, Entfernen anderer DBMS, Entfernen von allem außer ihr, aber ... das war sie noch nie so lange so viel Widerstand leisten. Meine letzte und einzige Hoffnung für euch, den Weg durch solch einen kritischen Moment in unseren Beziehungen zu weisen.

Ich verwende Vagrant und das Problem liegt in der Option datadir - wenn ich den Standardpfad verwende, ist alles in Ordnung, aber wenn ich ihn in den freigegebenen Vagrant-Ordner ändere, startet Maria nicht einmal. Ich habe alle/var/lib/mysql-Dateien in einen neuen Ordner kopiert.

Ich habe Windows Host, Centos Gast und meine Konfigurationen sind:

MariaDb Version :

mysql  Ver 15.1 Distrib 10.1.17-MariaDB, for Linux (x86_64) using readline 5.1

Vagrantfile :

# -*- mode: Ruby; -*-

ENV['VAGRANT_DEFAULT_PROVIDER'] = 'virtualbox'

Vagrant.configure("2") do |config|
  config.vm.box_url = "https://github.com/tommy-muehle/puppet-vagrant-boxes/releases/download/1.1.0/centos-7.0-x86_64.box"
  config.vm.box = "centos7"

  config.vm.network "private_network", ip: "10.0.1.10"

  config.vm.synced_folder "mysql", "/vagrant/mysql", owner: "mysql", group: "mysql"

  config.vm.provider :virtualbox do |vb|
    vb.customize ["modifyvm", :id, "--memory", "4096"]
    vb.customize ["modifyvm", :id, "--cpus", "4"]
    vb.customize ["modifyvm", :id, "--hwvirtex", "on"]
    vb.customize ["modifyvm", :id, "--audio", "none"]
    vb.customize ["modifyvm", :id, "--nictype1", "virtio"]
    vb.customize ["modifyvm", :id, "--nictype2", "virtio"]
  end
end

/ etc/my.cnf.d/server.cnf :

[mysqld]
user=mysql
datadir=/vagrant/mysql
socket=/var/lib/mysql/mysql.sock
symbolic-links=0
default-storage-engine=innodb

tmpdir = /tmp

character-set-server = utf8
init-connect="SET NAMES utf8"

expire_logs_days=2
skip-external-locking

key_buffer_size = 32M
max_allowed_packet = 32M
table_open_cache = 8192
table_definition_cache = 8192
sort_buffer_size = 16M
net_buffer_length = 16K
read_buffer_size = 8M
read_rnd_buffer_size = 8M
thread_cache_size = 128
thread_concurrency = 16

query_cache_size = 1024M
query_cache_limit = 2M
join_buffer_size = 32M

max_connections = 1024
max_connect_errors = 1024

connect_timeout=5

innodb_file_per_table
innodb_buffer_pool_size=2048M
innodb_read_io_threads=8
innodb_write_io_threads=8
innodb_lock_wait_timeout=5
innodb_flush_log_at_trx_commit=2
innodb_flush_method=O_DSYNC
innodb_log_file_size=64M
innodb_log_buffer_size=32M
innodb_log_files_in_group=2
innodb_thread_concurrency=16
innodb_open_files = 1000
innodb_sync_spin_loops=100

skip-name-resolve

log-error=/var/log/mariadb/mysqld.log

MariaDb-Fehlerprotokoll :

2016-09-30 22:32:46 139758293125248 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2016-09-30 22:32:46 139758293125248 [Note] InnoDB: The InnoDB memory heap is disabled
2016-09-30 22:32:46 139758293125248 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2016-09-30 22:32:46 139758293125248 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2016-09-30 22:32:46 139758293125248 [Note] InnoDB: Compressed tables use zlib 1.2.7
2016-09-30 22:32:46 139758293125248 [Note] InnoDB: Using Linux native AIO
2016-09-30 22:32:46 139758293125248 [Note] InnoDB: Using SSE crc32 instructions
2016-09-30 22:32:46 139758293125248 [Note] InnoDB: Initializing buffer pool, size = 2.0G
2016-09-30 22:32:46 139758293125248 [Note] InnoDB: Completed initialization of buffer pool
2016-09-30 22:32:46 139758293125248 [Note] InnoDB: Highest supported file format is Barracuda.
2016-09-30 22:32:46 139758293125248 [Note] InnoDB: 128 rollback segment(s) are active.
2016-09-30 22:32:46 139758293125248 [Note] InnoDB: Waiting for purge to start
2016-09-30 22:32:46 139758293125248 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.31-77.0 started; log sequence number 1600799
2016-09-30 22:32:46 139754263774976 [Note] InnoDB: Dumping buffer pool(s) not yet started
2016-09-30 22:32:46 139758293125248 [Note] Plugin 'FEEDBACK' is disabled.
2016-09-30 22:32:46 139758293125248 [ERROR] Can't init tc log
2016-09-30 22:32:46 139758293125248 [ERROR] Aborting
21
Sam Ivichuk

Woohoo, ich habe es gefunden! Zumindest für den Moment. Das Durchsuchen der Quelle deutet darauf hin, dass dies möglicherweise etwas mit mmap() -Aufrufen zu tun hat, und siehe da - VirtualBox hat einen Fehler in diesem Bereich . Glücklicherweise deutet dieselbe Quelle auf eine Problemumgehung hin - die Option log_bin . Aktivieren Sie dies (entweder über die Befehlszeile als --log_bin oder aus der Konfigurationsdatei als log_bin=ON) und die Dinge beginnen wieder zu funktionieren!

Aktualisieren

Sie sagen, dass sie es in VirtualBox 6.0.6 behoben haben!

15
Vilx-

Am Ende habe ich die Datei tc.log in/var/lib/mysql gelöscht. Als ich mysql erneut startete, erstellte es ein neues tc.log und startete.

Sudo rm -f /var/lib/mysql/tc.log
27
Flavio Troia

Sie können tc.log Im Datenverzeichnis entfernen und alte Einträge aus mysql-bin.index entfernen (es handelt sich um eine Textdatei zusammen mit einer Liste von Binärprotokollen). Wenn dies eine Entwicklungsbox ist, können Sie die Indexdatei (mysql-bin.index) entfernen, um die Neuerstellung zu erzwingen.

Es könnte auch mit den Benutzer-IDs zwischen mysql Benutzer und dem Eigentümer der freigegebenen Ordner-ID zusammenhängen. hier ist ein Ausschnitt dazu.

9
3manuek

Wenn Sie nur mysql/mariadb wieder zum Laufen bringen möchten und es macht nichts aus, Ihre Daten zu verlieren (in einer Entwicklungsumgebung), habe ich dies getan

Löschen: ib_logfile1 ib_logfile0 aria_log_control aria_log.00000001 tc.log ib_data1

starten Sie den Server

Löschen Sie das Schema (wenn es Dateien enthält, CD in den Ordner des Schemas, löschen Sie alles)

Ich habe dann die Datenbank von einem alten Dump, den ich hatte, erneut importiert.

Ich habe dann Mariadb gestartet, und es kommt gut an. Die gelöschten Dateien wurden neu erstellt. ** Auch dies ist nur für Entwickler. Sie könnten wahrscheinlich Ihre Datenbank installieren **

1
Kiren

Ich habe diesen Fehler auch durch Entfernen des tc.log behoben. Bei XAMPP befindet sich die Datei tc.log im XAMPP/xamppfiles/var/mysql Ordner - auf meinem Mac befindet er sich unter: /Applications/XAMPP/xamppfiles/var/mysql/tc.log

0
John Tyner

Ich hatte dieses Problem im offiziellen Docker-Container von MariaDB. Das Entfernen der Protokolldatei als die anderen angebotenen Antworten hat mir nicht geholfen. Mein Problem bezog sich jedoch auf mmap, wie die akzeptierte Antwort nahelegt.

Ich habe verschiedene Lösungen gefunden um dies für mein Szenario zu korrigieren.

  1. Binärprotokoll aktivieren
  2. Entfernen Sie den Konflikt, der die ordnungsgemäße Funktion von mmap verhindert
0
brettinternet

Nachdem ich MySQL Workbench neben MariaDB 10.x unter Ubuntu 19.10.x installiert hatte und MariaDB plötzlich unterbrochen wurde Sudo mv /var/lib/mysql/tc.log /var/lib/mysql/tc_bkp.log hat für mich gearbeitet.

0
Mark Lee

Dieses Problem trat auf, als ich versuchte, den Datenbankdatenordner zu kopieren. Also habe ich in den Datenordner gewechselt und den folgenden Befehl ausgeführt, um alle Protokolldateien zu löschen:

rm -rf *log*

Dann habe ich den Docker neu aufgebaut und das Problem wurde sortiert.

0