MariaDB Não é possível iniciar o log do tc

Eu tentei todas as soluções na Internet, mas meu servidor MariaDb continua a falhar, continua a me trair, continua a destruir meu pequeno mundo de DevOps. Minhas tentativas de amenizar a situação incluíam todo tipo de satisfação: alterar permissões, configurações, remover arquivos de log, atualizar / reinstalar, mover seus arquivos internos para cima e para trás, remover outros DBMS, remover tudo, exceto ela, mas ... ela nunca foi. resistindo tanto por tanto tempo. Minha última e única esperança para vocês iluminarem o caminho através de um momento tão crítico em nossos relacionamentos.

Estou usando o vagrant e o problema está na datadiropção - quando eu uso o caminho padrão, tudo está bem, mas quando eu o altero para a pasta compartilhada vagrant, Maria nem inicia. Copiei todos os arquivos / var / lib / mysql para a nova pasta.

Eu tenho host do Windows, convidado do Centos e minhas configurações são:

Versão 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 de erros do 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, eu achei! Por enquanto, pelo menos. A pesquisa na fonte sugere que isso pode ter algo a ver com mmap()chamadas e eis que - o VirtualBox tem um bug nessa área . Felizmente, a mesma fonte sugere uma solução alternativa - a opção log_bin . Habilite isso (a partir da linha de comando --log_binou do arquivo de configuração como log_bin=ON) e tudo começará a funcionar novamente!

Atualizar

Eles estão dizendo que o corrigiram no VirtualBox 6.0.6!

Acabei excluindo o arquivo tc.log em / var / lib / mysql. Quando iniciei o mysql novamente, ele criou um novo tc.log e foi iniciado.

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

Você pode remover o tc.logdiretório de dados e remover entradas antigas do mysql-bin.index (é um arquivo de texto, junto com uma lista de logs binários). Se esta é uma caixa de desenvolvimento, você pode remover o arquivo de índice (mysql-bin.index) para forçar sua recriação.

Também pode estar relacionado aos IDs de usuário entre o mysqlusuário e o proprietário do ID da pasta compartilhada. Aqui está um trecho para fazer isso.

Se você apenas deseja que o mysql / mariadb seja executado novamente e não se importe em perder seus dados (em um ambiente de desenvolvimento), foi o que eu fiz

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

iniciar o servidor

Exclua o esquema (se ele contiver arquivos, cd na pasta do esquema, exclua tudo)

Em seguida, reimportei o banco de dados de um despejo antigo que eu tinha.

Comecei então o mariadb, e tudo corre bem. Os arquivos excluídos foram recriados. ** Novamente, isso é apenas para o desenvolvedor. Você provavelmente poderia instalar seu db **

Eu enfrentei esse problema quando tentei copiar a pasta de dados do banco de dados. Então mudei para a pasta de dados e executei o seguinte comando para excluir todos os arquivos de log:

rm -rf *log*

Depois reconstruí a janela de encaixe e o problema foi resolvido.

Também resolvi esse erro removendo o tc.log. Com o XAMPP, o arquivo tc.log está na XAMPP/xamppfiles/var/mysqlpasta - no meu mac, está localizado em: /Applications/XAMPP/xamppfiles/var/mysql/tc.log

Eu tive esse problema no contêiner de estivador oficial do MariaDB. A remoção do arquivo de log como as outras respostas oferecidas não me ajudou. No entanto, meu problema foi relacionado à mmapsugestão da resposta aceita.

Encontrei várias soluções para corrigir isso no meu cenário.

1. Ativar log binário
2. Remova o mmap de inibição de conflitos de funcionar corretamente