web-dev-qa-db-fra.com

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 d'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 moment aussi critique dans nos relations.

J'utilise vagrant et le problème est dans l'option datadir - lorsque j'utilise le chemin par défaut, tout est ok 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 Windows Host, 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
mariadbcentos
21
Sam Ivichuk

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 appels à mmap(), et voilà - VirtualBox a un bogue dans cette zone . Heureusement, la même source fait allusion à une solution de contournement - option log_bin . Activez ceci (soit à partir de la ligne de commande en tant que --log_bin ou à partir du fichier de configuration en tant que log_bin=ON) et les choses recommencent à fonctionner!

Mise à jour

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

15
Vilx-

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
27
Flavio Troia

Vous pouvez supprimer le tc.log dans le répertoire de données et supprimez 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 pourrait également être lié aux ID utilisateur entre mysql utilisateur et le propriétaire de l'ID de dossier partagé, ici est un extrait de code pour le faire.

9
3manuek

Si vous voulez juste faire fonctionner mysql/mariadb à nouveau et ça 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 **

1
Kiren

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

0
John Tyner

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 comme le suggère la réponse acceptée.

j'ai trouvé diverses solutions pour corriger cela pour mon scénario.

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

Après avoir installé MySQL Workbench à côté de MariaDB 10.x sur Ubuntu 19.10.x et soudain, MariaDB a été perturbé Sudo mv /var/lib/mysql/tc.log /var/lib/mysql/tc_bkp.log a fonctionné pour moi.

0
Mark Lee

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é.

0
tharanga rajapaksha