MariaDB no puede iniciar el registro de tc

He probado todas las soluciones en Internet, pero mi servidor MariaDb sigue fallando, sigue traicionándome, sigue destruyendo mi pequeño mundo DevOps. Mis intentos de suavizar la situación incluyeron todo tipo de satisfacción: cambiar permisos, configuraciones, eliminar archivos de registro, actualizar / reinstalar, mover sus archivos internos, eliminar otros DBMS, eliminar todo excepto ella, pero ... ella nunca ha estado resistiendo tanto por tanto tiempo. Mi última y única esperanza para ustedes es que iluminen el camino a través de un momento tan crítico en nuestras relaciones.

Estoy usando vagabundo y el problema está en la datadiropción: cuando uso la ruta predeterminada, todo está bien, pero cuando lo cambio a una carpeta compartida vagabunda, María ni siquiera se inicia. Copié todos los archivos / var / lib / mysql a una nueva carpeta.

Tengo un host de Windows, un invitado de Centos y mis configuraciones son:

Versión MariaDb:

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

Archivo Vagabundo:

# -*- 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 errores de 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, lo encontré! Por ahora al menos. Excavar a través de la fuente sugiere que esto podría tener algo que ver con las mmap()llamadas, y he aquí: VirtualBox tiene un error en esa área . Afortunadamente, esa misma fuente sugiere una solución alternativa: la opción log_bin . ¡Habilite esto (ya sea desde la línea de comando como --log_bindesde el archivo de configuración como log_bin=ON) y las cosas comenzarán a funcionar nuevamente!

Actualizar

¡Dicen que lo arreglaron en VirtualBox 6.0.6!

Terminé eliminando el archivo tc.log en / var / lib / mysql. Cuando comencé mysql nuevamente, creó un nuevo tc.log y se inició.

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

Puede eliminar el tc.logen el directorio de datos y eliminar las entradas antiguas de mysql-bin.index (es un archivo de texto, junto con una lista de registros binarios). Si se trata de un cuadro de desarrollo, puede eliminar el archivo de índice (mysql-bin.index) para forzar su recreación.

También podría estar relacionado con los mysqlID de usuario entre el usuario y el propietario del ID de la carpeta compartida, aquí hay un fragmento para hacerlo.

Si solo desea volver a ejecutar mysql / mariadb y no le importa perder sus datos (en un entorno de desarrollo), esto es lo que hice

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

iniciar el servidor

Elimine el esquema (si contiene archivos, cd en la carpeta del esquema, elimine todo)

Luego reimporté la base de datos de un viejo basurero que tenía.

Entonces comencé mariadb, y sale bien. Los archivos eliminados se recrearon. ** Nuevamente, esto es solo para desarrolladores. Probablemente puedas instalar tu db **

Me enfrenté a este problema cuando intenté copiar la carpeta de datos de la base de datos. Así que cambié a la carpeta de datos y ejecuté el siguiente comando para eliminar todos los archivos de registro:

rm -rf *log*

Luego reconstruí la ventana acoplable y se solucionó el problema.

También resolví este error eliminando el tc.log. Con XAMPP, el archivo tc.log está en la XAMPP/xamppfiles/var/mysqlcarpeta, en mi Mac está ubicado en: /Applications/XAMPP/xamppfiles/var/mysql/tc.log

Tuve este problema dentro del contenedor acoplable oficial de MariaDB. Eliminar el archivo de registro como las otras respuestas ofrecidas no me ayudó. Sin embargo, mi problema estaba relacionado con lo mmapque sugiere la respuesta aceptada.

Encontré varias soluciones para corregir esto para mi escenario.

1. Activar registro binario
2. Eliminar el conflicto que inhibe mmap de funcionar correctamente