MariaDB не вдається запустити журнал tc

Я пробував кожне рішення в Інтернеті, але мій сервер MariaDb продовжує виходити з ладу, продовжуйте зраджувати мене, продовжуйте руйнувати мій крихітний світ DevOps. Мої спроби виправити ситуацію включали всілякі задоволення: зміна дозволів, конфігурацій, видалення файлів журналів, оновлення / перевстановлення, переміщення її внутрішніх файлів вгору та навколо, видалення інших СУБД, видалення всього, крім неї, але .... вона ніколи не була так довго протистояти. Моє останнє і єдине сподівання для вас, хлопці, просвітити шлях через такий критичний момент у наших стосунках.

Я використовую бродягу, і проблема полягає у datadirваріанті - коли я використовую шлях за замовчуванням, все нормально, але коли я змінюю його на загальнодоступну загальну папку, Марія навіть не запускається. Я скопіював усі файли / var / lib / mysql у нову папку.

У мене хост Windows, гость Centos і мої конфігурації:

Версія 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

Журнал помилок 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, я знайшов! Поки щонайменше. Копання джерела говорить про те, що це може мати щось спільне з mmap()дзвінками, і ось - ось VirtualBox має помилку в цій області . На щастя, те саме джерело натякає на вирішення проблеми - варіант log_bin . Увімкніть це (з командного рядка як --log_binабо з конфігураційного файлу як log_bin=ON), і все знову почне працювати!

Оновлення

Вони говорять, що виправили це у VirtualBox 6.0.6!

Я видалив файл tc.log в / var / lib / mysql. Коли я знову запустив mysql, він створив новий tc.log і запустився.

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

Ви можете видалити tc.logдані в каталозі даних та видалити старі записи з mysql-bin.index (це текстовий файл разом зі списком бінарних журналів). Якщо це поле для розробки, ви можете видалити індексний файл (mysql-bin.index), щоб примусити його відтворити.

Також це може бути пов’язано з ідентифікаторами користувача між mysqlкористувачем та власником ідентифікатора спільної папки, ось фрагмент для цього.

Якщо ви просто хочете знову запустити mysql / mariadb і не проти втратити свої дані (у середовищі розробників), це я зробив

Видалити: ib_logfile1 ib_logfile0 aria_log_control aria_log.00000001 tc.log ib_data1

запустити сервер

Видаліть схему (якщо вона містить файли, CD в папку схеми, видаліть усе)

Потім я знову імпортував базу даних зі старого дампа, який я мав.

Потім я почав мариадб, і це виходить чудово. Видалені файли були відтворені. ** Знову це лише для дев. Можливо, ви могли б встановити свій db **

Я зіткнувся з цим питанням, коли спробував скопіювати папку даних бази даних. Тому я змінив папку даних і виконав наступну команду, щоб видалити всі файли журналу:

rm -rf *log*

Потім я відновив докер і видав сортування.

Я також вирішив цю помилку, видаливши tc.log. З XAMPP файл tc.log знаходиться в XAMPP/xamppfiles/var/mysqlпапці - на моєму комп'ютері він знаходиться за адресою: /Applications/XAMPP/xamppfiles/var/mysql/tc.log

У мене виникла ця проблема в офіційному докерному контейнері MariaDB. Видалення файлу журналу, як і інші запропоновані відповіді, мені не допомогло. Однак моє питання було пов’язане з тим, mmapяк підказує прийнята відповідь.

Я знайшов різні рішення, щоб виправити це для свого сценарію.

1. Активуйте Бінарний журнал
2. Видаліть mmap, що гальмує конфлікт, від належного функціонування