Eu tentei todas as soluções na Internet, mas meu servidor MariaDb continua falhando, continua a me trair, continua a destruir meu pequeno mundo DevOps. Minhas tentativas de suavizar a situação incluíram todos os tipos de satisfação: alterar permissões, configurações, remover arquivos de log, atualizar / reinstalar, mover seus arquivos internos para cima e para baixo, 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 datadir
opção - quando uso o caminho padrão tudo está ok, mas quando altero para a pasta compartilhada do vagrant a Maria nem inicia. Copiei todos os arquivos /var/lib/mysql para a nova pasta.
Eu tenho Windows host, Centos guest 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
Log 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
Acabei excluindo o arquivo tc.log em /var/lib/mysql. Quando iniciei o mysql novamente, ele criou um novo tc.log e inicializou.
Uhuuul, encontrei! Por enquanto, pelo menos. Escavar a fonte sugere que isso pode ter algo a ver com
mmap()
chamadas, e eis que - o VirtualBox tem um bug nessa área . Felizmente, essa mesma fonte sugere uma solução alternativa - a opção log_bin . Habilite isso (a partir da linha de comando--log_bin
ou do arquivo de configuração comolog_bin=ON
) e as coisas começam a funcionar novamente!Atualizar
Eles estão dizendo que consertaram no VirtualBox 6.0.6!
Você pode remover o
tc.log
no diretório de dados e remover entradas antigas de mysql-bin.index (é um arquivo de texto, junto com uma lista de logs binários). Se esta for 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
mysql
o usuário e o proprietário do ID da pasta compartilhada, aqui está um trecho para fazer isso.Se você deseja apenas executar o mysql/mariadb novamente e não se importa 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 contiver arquivos, cd na pasta do esquema, exclua tudo)
Em seguida, reimportei o banco de dados de um dump antigo que eu tinha.
Eu então comecei o mariadb, e deu tudo certo. Os arquivos excluídos foram recriados. ** Novamente, isso é apenas para dev. Você provavelmente poderia instalar seu db **
Eu também resolvi esse erro removendo o tc.log. Com o XAMPP, o arquivo tc.log está na
XAMPP/xamppfiles/var/mysql
pasta - no meu mac está localizado em:/Applications/XAMPP/xamppfiles/var/mysql/tc.log
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:
Então eu reconstruí o docker e o problema foi resolvido.
Eu tive esse problema no contêiner oficial do docker do MariaDB. A remoção do arquivo de log como as outras respostas oferecidas não me ajudou. No entanto, meu problema estava relacionado ao
mmap
que a resposta aceita sugere.Encontrei várias soluções para corrigir isso para o meu cenário.
Depois que eu instalei o MySQL Workbench ao lado do MariaDB 10.x no Ubuntu 19.10.xe de repente o MariaDB foi interrompido
sudo mv /var/lib/mysql/tc.log /var/lib/mysql/tc_bkp.log
funcionou para mim.