MariaDB ne peut pas initier le journal tc

J'ai essayé toutes les solutions sur Internet mais mon serveur MariaDb continue d'échouer, continue de me trahir, continue de détruire mon petit monde DevOps. Mes tentatives pour lisser la situation incluaient toutes sortes de satisfaction: changer les autorisations, les configurations, supprimer les fichiers journaux, mettre à niveau / réinstaller, déplacer ses fichiers internes vers le haut et autour, supprimer les autres SGBD, tout supprimer sauf elle mais .... elle n'a jamais été tant résister pendant si longtemps. Mon dernier et unique espoir pour vous d'éclairer le chemin à travers un tel moment critique dans nos relations.

J'utilise vagrant et le problème est en datadiroption - quand j'utilise le chemin par défaut tout va bien mais quand je le change en dossier partagé vagrant, Maria ne démarre même pas. J'ai copié tous les fichiers / var / lib / mysql dans un nouveau dossier.

J'ai un hôte Windows, un invité Centos et mes configurations sont:

Version 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

Journal des erreurs 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, je l'ai trouvé! Pour l'instant, au moins. L'exploration de la source suggère que cela pourrait avoir quelque chose à voir avec les mmap()appels, et voilà, VirtualBox a un bogue dans ce domaine . Heureusement, cette même source suggère une solution de contournement - l' option log_bin . Activez ceci (soit depuis la ligne de commande en tant que --log_binou depuis le fichier de configuration en tant que log_bin=ON) et les choses recommenceront à fonctionner!

Mise à jour

Ils disent qu'ils l'ont corrigé dans VirtualBox 6.0.6!

J'ai fini par supprimer le fichier tc.log dans / var / lib / mysql. Quand j'ai redémarré mysql, il a créé un nouveau tc.log et a démarré.

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

Vous pouvez supprimer le tc.logdans le répertoire de données et supprimer les anciennes entrées de mysql-bin.index (il s'agit d'un fichier texte, avec une liste de journaux binaires). S'il s'agit d'une boîte de développement, vous pouvez supprimer le fichier d'index (mysql-bin.index) pour forcer sa recréation.

Il peut également être lié aux ID utilisateur entre l' mysqlutilisateur et le propriétaire de l'ID du dossier partagé, voici un extrait pour le faire.

Si vous voulez simplement relancer mysql / mariadb et que cela ne vous dérange pas de perdre vos données (dans un environnement de développement), c'est ce que j'ai fait

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

démarrer le serveur

Supprimez le schéma (s'il contient des fichiers, cd dans le dossier du schéma, supprimez tout)

J'ai ensuite réimporté la base de données d'une ancienne décharge que j'avais.

J'ai ensuite commencé mariadb, et ça se passe bien. Les fichiers supprimés ont été recréés. ** Encore une fois, c'est uniquement pour les développeurs. Vous pourriez probablement installer votre db **

J'ai rencontré ce problème lorsque j'ai essayé de copier le dossier de données de la base de données. J'ai donc changé pour le dossier de données et exécuté la commande suivante pour supprimer tous les fichiers journaux:

rm -rf *log*

Ensuite, j'ai reconstruit le docker et le problème a été trié.

J'ai également résolu cette erreur en supprimant le tc.log. Avec XAMPP, le fichier tc.log est dans le XAMPP/xamppfiles/var/mysqldossier - sur mon mac, il se trouve à: /Applications/XAMPP/xamppfiles/var/mysql/tc.log

J'ai eu ce problème dans le conteneur Docker officiel de MariaDB. La suppression du fichier journal car les autres réponses proposées ne m'a pas aidé. Cependant, mon problème était lié àmmap que la réponse acceptée suggère.

J'ai trouvé différentes solutions pour corriger cela pour mon scénario.

1. Activer le journal binaire
2. Supprimer le mmap empêchant le conflit de fonctionner correctement