MariaDB Impossibile avviare il registro tc

Ho provato tutte le soluzioni su Internet, ma il mio server MariaDb continua a fallire, continua a tradirmi, continua a distruggere il mio piccolo mondo DevOps. I miei tentativi di risolvere la situazione includevano ogni sorta di soddisfazione: modifica delle autorizzazioni, configurazioni, rimozione dei file di registro, aggiornamento / reinstallazione, spostamento dei suoi file interni su e intorno, rimozione di altri DBMS, rimozione di tutto tranne lei ma ... non è mai stata resistere così tanto per così tanto tempo. La mia ultima e unica speranza per voi ragazzi di illuminare la strada attraverso un momento così critico nelle nostre relazioni.

Sto usando Vagrant e il problema è in datadiropzione: quando uso il percorso predefinito tutto è ok ma quando lo cambio nella cartella condivisa Vagrant Maria non si avvia nemmeno. Ho copiato tutti i file / var / lib / mysql in una nuova cartella.

Ho un host Windows, guest Centos e le mie configurazioni sono:

Versione MariaDb:

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

Registro errori MariaDb:

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

Woohoo, l'ho trovato! Per ora, almeno. Scavare attraverso la fonte suggerisce che questo potrebbe avere qualcosa a che fare con le mmap()chiamate, ed ecco - VirtualBox ha un bug in quella zona . Fortunatamente quella stessa fonte suggerisce una soluzione: l' opzione log_bin . Abilita questo (o dalla riga di comando come --log_bino dal file di configurazione come log_bin=ON) e le cose ricominceranno a funzionare!

Aggiornare

Stanno dicendo che l'hanno risolto in VirtualBox 6.0.6!

Ho finito per eliminare il file tc.log in / var / lib / mysql. Quando ho riavviato mysql, ha creato un nuovo tc.log e avviato.

sudo rm -f /var/lib/mysql/tc.log

Puoi rimuovere il file tc.lognella directory dei dati e rimuovere le vecchie voci da mysql-bin.index (è un file di testo, insieme a un elenco di registri binari). Se si tratta di una casella di sviluppo, è possibile rimuovere il file indice (mysql-bin.index) per forzare la sua ricreazione.

Inoltre potrebbe essere correlato agli ID utente tra l' mysqlutente e il proprietario dell'ID cartella condivisa, ecco uno snippet per farlo.

Se vuoi solo riavviare mysql / mariadb e non ti dispiace perdere i tuoi dati (in un ambiente di sviluppo), questo è quello che ho fatto

Elimina: ib_logfile1 ib_logfile0 aria_log_control aria_log.00000001 tc.log ib_data1

avviare il server

Elimina lo schema (se contiene file, cd nella cartella dello schema, elimina tutto)

Ho quindi reimportato il database da un vecchio dump che avevo.

Ho quindi avviato mariadb, e mi risulta che vada bene. I file eliminati sono stati ricreati. ** Anche in questo caso è solo per gli sviluppatori. Probabilmente potresti installare il tuo db **

Ho riscontrato questo problema quando ho provato a copiare la cartella dei dati del database. Quindi sono passato alla cartella dei dati ed eseguito il seguente comando per eliminare tutti i file di registro:

rm -rf *log*

Quindi ho ricostruito la finestra mobile e il problema è stato risolto.

Ho anche risolto questo errore rimuovendo tc.log. Con XAMPP il file tc.log è nella XAMPP/xamppfiles/var/mysqlcartella - sul mio mac si trova in: /Applications/XAMPP/xamppfiles/var/mysql/tc.log

Ho riscontrato questo problema nel contenitore docker ufficiale di MariaDB. La rimozione del file di registro come le altre risposte offerte non mi ha aiutato. Tuttavia, il mio problema era legato a mmapcome suggerisce la risposta accettata.

Ho trovato varie soluzioni per correggere questo per il mio scenario.

1. Attiva registro binario
2. Rimuovere il mmap che inibisce il conflitto dal corretto funzionamento