我尝试了 Internet 上的所有解决方案,但我的 MariaDb 服务器继续出现故障,继续背叛我,继续摧毁我小小的 DevOps 世界。我试图缓和这种情况的尝试包括各种满足感:更改权限、配置、删除日志文件、升级/重新安装、上下移动她的内部文件、删除其他 DBMS、删除除了她之外的所有东西......她从来没有抗拒了这么久。我最后也是唯一的希望你们能在我们关系中的关键时刻照亮道路。
我正在使用 vagrant,问题出在datadir
选项中 - 当我使用默认路径时一切正常,但是当我将其更改为 vagrant 共享文件夹时,Maria 甚至没有启动。我已将所有 /var/lib/mysql 文件复制到新文件夹。
我有 Windows 主机,Centos 来宾,我的配置是:
MariaDb 版本:
mysql Ver 15.1 Distrib 10.1.17-MariaDB, for Linux (x86_64) using readline 5.1
流浪文件:
# -*- 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
我最终删除了 /var/lib/mysql 中的 tc.log 文件。当我再次启动 mysql 时,它创建了一个新的 tc.log 并启动。
呜呜,我找到了!至少目前是这样。挖掘源代码表明这可能与
mmap()
调用有关,你瞧——VirtualBox在那个区域有一个错误。幸运的是,相同的来源暗示了一种解决方法 - log_bin 选项。启用它(无论是从命令行--log_bin
还是从配置文件log_bin=ON
),一切又开始工作了!更新
他们说他们已经在 VirtualBox 6.0.6 中修复了它!
您可以删除
tc.log
数据目录中的 并从 mysql-bin.index 中删除旧条目(它是一个文本文件,以及二进制日志列表)。如果这是一个开发框,您可以删除索引文件 (mysql-bin.index) 以强制重新创建它。它也可能与
mysql
用户和共享文件夹 id 所有者之间的用户 id 有关,这是一个片段。如果您只想让 mysql/mariadb 再次运行并且不介意丢失数据(在开发环境中),这就是我所做的
删除:ib_logfile1 ib_logfile0 aria_log_control aria_log.00000001 tc.log ib_data1
启动服务器
删除架构(如果它包含文件,cd 到架构的文件夹中,删除所有内容)
然后我从我拥有的旧转储中重新导入数据库。
然后我启动了mariadb,结果很好。被删除的文件被重新创建。** 同样,这仅适用于开发人员。你可能会安装你的数据库**
我还通过删除 tc.log 解决了这个错误。使用 XAMPP,tc.log 文件位于
XAMPP/xamppfiles/var/mysql
文件夹中 - 在我的 Mac 上,它位于:/Applications/XAMPP/xamppfiles/var/mysql/tc.log
当我尝试复制数据库数据文件夹时,我遇到了这个问题。所以我切换到数据文件夹并执行以下命令删除所有日志文件:
然后我重建了 docker 并解决了问题。
我在 MariaDB 的官方 docker 容器中遇到了这个问题。删除日志文件作为提供的其他答案对我没有帮助。但是,我的问题与
mmap
公认的答案有关。我找到了各种解决方案来纠正我的情况。
在我在 Ubuntu 19.10.x 上在 MariaDB 10.x 旁边安装 MySQL Workbench 之后,突然间 MariaDB 被打乱
sudo mv /var/lib/mysql/tc.log /var/lib/mysql/tc_bkp.log
了。