MariaDB tc günlüğü başlatılamıyor

İnternetteki her çözümü denedim ama MariaDb sunucum başarısız olmaya devam etti, bana ihanet etmeye devam et, minik DevOps dünyamı mahvetmeye devam et. Durumu düzeltmek için yaptığım girişimlerde her türlü memnuniyet vardı: izinleri değiştirmek, yapılandırmaları, günlük dosyalarını kaldırmak, yükseltmek / yeniden yüklemek, dahili dosyalarını yukarı ve aşağı taşımak, diğer DBMS'leri kaldırmak, onun dışındaki her şeyi kaldırmak ... çok uzun süredir direniyor. Sizin son ve tek umudum sizler için ilişkilerimizde bu kadar kritik bir anı aydınlatacaksınız.

Serseri kullanıyorum ve sorun datadirseçeneği - varsayılan yol kullandığımda her şey yolunda ama serseri paylaşılan klasöre değiştirdiğimde Maria bile başlamıyor. Tüm / var / lib / mysql dosyalarını yeni klasöre kopyaladım.

Windows sunucum var, Centos konuğum ve konfigürasyonlarım:

MariaDb sürümü:

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 hata günlüğü:

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, buldum! Şimdilik, en azından. Kaynağa bakmak, bunun mmap()çağrılarla bir ilgisi olabileceğini ve bununla ilgilendiğini gösteriyor - VirtualBox bu alanda bir hata yaptı . Neyse ki aynı kaynak bir geçici çözümü işaret ediyor - log_bin seçeneği . Bunu etkinleştirin (komut satırından --log_binveya config dosyasındaki gibi log_bin=ON) ve işler yeniden çalışmaya başlar!

Güncelleştirme

VirtualBox 6.0.6’da düzelttiklerini söylüyorlar!

/ Var / lib / mysql içindeki tc.log dosyasını silmeye başladım. MySQL'i tekrar başlattığımda yeni bir tc.log dosyası yarattı ve başlattı.

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

Sen kaldırabilirsiniz tc.logveri dizininde ve mysql-bin.index (Bu ikili günlüklerinin bir listesi ile birlikte, bir metin dosyası) eski girdileri kaldırın. Bu bir geliştirme kutusuysa, yeniden oluşturmaya zorlamak için dizin dosyasını (mysql-bin.index) kaldırabilirsiniz.

Ayrıca mysqlkullanıcı ve paylaşılan klasör kimliği sahibi arasındaki kullanıcı kimlikleriyle ilgili olabilir , işte bunun için bir pasaj.

Eğer sadece mysql / mariadb'nin tekrar çalışmasını sağlamak ve verilerinizi kaybetmek istemezseniz (dev bir ortamda), yaptığım şey buydu.

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

sunucuyu başlat

Şemayı silin (dosya içeriyorsa, şema klasörüne cd, her şeyi silin)

Sonra veritabanını eski bir çöplükten yeniden aldım.

Daha sonra mariadb'a başladım ve iyi sonuçlandı. Silinen dosyalar yeniden oluşturuldu. ** Yine, bu sadece dev içindir. Muhtemelen db'nizi kurabilirsiniz **

Veritabanı veri klasörünü kopyalamaya çalıştığımda bu sorunla karşılaştım. Böylece veri klasörüne döndüm ve tüm günlük dosyalarını silmek için aşağıdaki komutu kullandım:

rm -rf *log*

Sonra liman işçisi yeniden yaptım ve sorun sıralandı.

Bu hatayı tc.log dosyasını kaldırarak da çözdüm. XAMPP ile tc.log dosyası XAMPP/xamppfiles/var/mysqlklasördedir - mac'umda bulunduğu yer: /Applications/XAMPP/xamppfiles/var/mysql/tc.log

Bu sorunu MariaDB'nin resmi liman işçisi konteynırında yaşadım. Günlük dosyasını sunulan diğer cevaplar gibi kaldırmak bana yardımcı olmadı. Ancak benim sorunum mmapkabul edilen cevabın önerdiği gibi oldu.

Senaryomu düzeltmek için çeşitli çözümler buldum .

1. İkili Günlüğü Etkinleştir
2. Çatışmayı önleyen mmap'in düzgün çalışmasını engelleyin