MariaDB không thể init tc log

Tôi đã thử mọi giải pháp trên Internet nhưng máy chủ MariaDb của tôi tiếp tục thất bại, tiếp tục phản bội tôi, tiếp tục phá hủy thế giới DevOps nhỏ bé của tôi. Những nỗ lực của tôi để giải quyết tình huống bao gồm tất cả các loại thỏa mãn: thay đổi quyền, cấu hình, xóa tệp nhật ký, nâng cấp / cài đặt lại, di chuyển các tệp nội bộ của cô ấy lên và xóa, loại bỏ DBMS khác, xóa mọi thứ trừ cô ấy nhưng .... cô ấy chưa bao giờ chống cự rất lâu Hy vọng cuối cùng và duy nhất của tôi cho các bạn để làm sáng tỏ thời điểm quan trọng như vậy trong các mối quan hệ của chúng tôi.

Tôi đang sử dụng vagrant và vấn đề nằm ở datadirtùy chọn - khi tôi sử dụng đường dẫn mặc định thì mọi thứ đều ổn nhưng khi tôi thay đổi nó thành thư mục chia sẻ mơ hồ thì Maria thậm chí không bắt đầu. Tôi đã sao chép tất cả các tập tin / var / lib / mysql vào thư mục mới.

Tôi có máy chủ Windows, máy khách Centos và cấu hình của tôi là:

Phiên bản 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

Nhật ký lỗi 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, tôi đã tìm thấy nó! Ít nhất cho tới hiện tại. Việc tìm hiểu kỹ về nguồn cho thấy điều này có thể có liên quan đến mmap()các cuộc gọi và lo và kìa - VirtualBox có một lỗi trong khu vực đó . May mắn thay, cùng một gợi ý nguồn tại một cách giải quyết - tùy chọn log_bin . Kích hoạt tính năng này (từ dòng lệnh dưới dạng --log_binhoặc từ tệp cấu hình dưới dạng log_bin=ON) và mọi thứ bắt đầu hoạt động trở lại!

Cập nhật

Họ nói rằng họ đã sửa nó trong VirtualBox 6.0.6!

Tôi đã kết thúc việc xóa tệp tc.log trong / var / lib / mysql. Khi tôi khởi động lại mysql, nó đã tạo ra một tc.log mới và khởi động.

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

Bạn có thể xóa tc.logthư mục dữ liệu và xóa các mục cũ khỏi mysql-bin.index (nó là một tệp văn bản, cùng với một danh sách các bản ghi nhị phân). Nếu đây là hộp phát triển, bạn có thể xóa tệp chỉ mục (mysql-bin.index) để buộc giải trí.

Ngoài ra, nó có thể liên quan đến id người dùng giữa mysqlngười dùng và chủ sở hữu id thư mục dùng chung, đây là đoạn trích để làm như vậy.

Nếu bạn chỉ muốn chạy mysql / mariadb và không mất dữ liệu (trong môi trường dev), đây là những gì tôi đã làm

Xóa: ib_logfile1 ib_logfile0 aria_log_control aria_log.00000001 tc.log ib_data1

khởi động máy chủ

Xóa lược đồ (nếu nó chứa tệp, cd vào thư mục của lược đồ, xóa mọi thứ)

Sau đó tôi nhập lại cơ sở dữ liệu từ một bãi chứa cũ mà tôi có.

Sau đó tôi bắt đầu mariadb, và nó đi lên tốt. Các tập tin bị xóa đã được tạo lại. ** Một lần nữa điều này chỉ dành cho dev. Bạn có thể có thể cài đặt db ** của bạn

Tôi gặp phải vấn đề này khi tôi cố gắng sao chép thư mục dữ liệu cơ sở dữ liệu. Vì vậy, tôi đã thay đổi thư mục dữ liệu và thực hiện lệnh sau để xóa tất cả các tệp nhật ký:

rm -rf *log*

Sau đó, tôi xây dựng lại docker và vấn đề đã được sắp xếp.

Tôi cũng đã giải quyết lỗi này bằng cách xóa tc.log. Với XAMPP, tệp tc.log nằm trong XAMPP/xamppfiles/var/mysqlthư mục - trên máy mac của tôi, nó nằm ở: /Applications/XAMPP/xamppfiles/var/mysql/tc.log

Tôi gặp vấn đề này trong container docker chính thức của MariaDB. Xóa tệp nhật ký như các câu trả lời khác được cung cấp không giúp tôi. Tuy nhiên, vấn đề của tôi liên quan đến mmapnhư câu trả lời được chấp nhận cho thấy.

Tôi tìm thấy nhiều giải pháp để sửa lỗi này cho kịch bản của mình.

1. Kích hoạt Nhật ký nhị phân
2. Loại bỏ xung đột ức chế mmap khỏi hoạt động đúng