MariaDB Nie można zainicjować dziennika TC


21

Wypróbowałem wszystkie rozwiązania w Internecie, ale mój serwer MariaDb nadal zawodzi, dalej mnie zdradza, nadal niszczy mój mały świat DevOps. Moje próby złagodzenia sytuacji obejmowały różnego rodzaju satysfakcję: zmienianie uprawnień, konfiguracje, usuwanie plików dziennika, uaktualnianie / ponowne instalowanie, przenoszenie jej wewnętrznych plików w górę i dookoła, usuwanie innych DBMS, usuwanie wszystkiego oprócz niej, ale ... nigdy nie była tak długo się opierać. Moją ostatnią i jedyną nadzieją dla was, abyście przebili drogę przez tak krytyczny moment w naszych związkach.

Używam włóczęgi, a problem jest w datadiropcji - kiedy używam domyślnej ścieżki wszystko jest w porządku, ale kiedy zmieniam ją na włóczęgę udostępnionego folderu, Maria nawet się nie uruchamia. Skopiowałem wszystkie pliki / var / lib / mysql do nowego folderu.

Mam hosta Windows, gościa Centos, a moje konfiguracje to:

Wersja 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

Dziennik błędów 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

1
Czy masz wystarczającą ilość miejsca na partycji z dziennikiem? Czy możesz usunąć plik dziennika i uruchomić ponownie?
Stoleg

@Stoleg Cześć Stoleg, dziękuję za odpowiedź. Na partycji jest dużo wolnego miejsca. Próbowałem usunąć plik, ponownie uruchomić, a MariaDb tworzy go i nie uruchamia się
Sam Ivichuk

Czy konto używane przez Marię ma READuprawnienia do folderu docelowego? Może istnieć szansa, że ​​może utworzyć plik z zapisem, ale nie ma uprawnień do odczytu. Spróbuj wykonać te same operacje, które Maria wykonałaby na swoim koncie. Może to nie może utrzymać pliku otwartego i zablokowanego?
Stoleg 10.10.16

Odpowiedzi:


15

Woohoo, znalazłem to! Przynajmniej na razie. Przekopienie źródła sugeruje, że może to mieć coś wspólnego z mmap()wywołaniami, i oto - VirtualBox ma błąd w tym obszarze . Na szczęście to samo źródło sugeruje obejście - opcja log_bin . Włącz to (z wiersza poleceń jako --log_binlub z pliku konfiguracyjnego jako log_bin=ON), a wszystko zacznie znowu działać!

Aktualizacja

Mówią, że naprawili to w VirtualBox 6.0.6!


Dziękuję bardzo! To naprawiło mój tc.logbłąd przy użyciu Virtualbox na hoście Windows 10.
Ricky Boyce,

Wydaje mi się, że był to również znaczący postęp, Windows 10 Home, Docker Toolbox 18.03.
rfay

22

Skończyło się usuwanie pliku tc.log w / var / lib / mysql. Kiedy ponownie uruchomiłem mysql, utworzyłem nowy tc.log i uruchomiłem.

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

choć wydaje się to trochę niebezpieczne, w moim przypadku zadziałało!
Peter

2
Udało się, ale bezpieczniej jest używać:sudo mv /var/lib/mysql/tc.log /var/lib/mysql/tc_bkp.log
Pedro Lobito

9

Możesz usunąć tc.logw katalogu danych i usunąć stare wpisy z mysql-bin.index (jest to plik tekstowy wraz z listą dzienników binarnych). Jeśli jest to pole programistyczne, możesz usunąć plik indeksu (mysql-bin.index), aby wymusić jego odtworzenie.

Może to być również powiązane z identyfikatorami użytkowników między mysqlużytkownikiem a właścicielem identyfikatora folderu współdzielonego, oto fragment tego kodu.


Ciekawy temat przyczyny tego problemu chociaż, jak można uniknąć? Dzięki
3zzy

@ 3zzy - Przeczytaj moją odpowiedź.
Vilx-

@ 3zzy Nie odtworzyłem jeszcze błędu.
3manuek

To rzeczywiście dziwny problem. Co dokładnie jest przechowywane w tym pliku? Spieszyłem się z rozwiązaniem problemu i zapomniałem spojrzeć na ten, który tam był. Mogę podać więcej szczegółów.
MageProspero

Podejrzewam, że błąd „brak miejsca na dysku” uszkodził dziś mój tc.log.
jchook

1

Jeśli chcesz po prostu ponownie uruchomić mysql / mariadb i nie masz nic przeciwko utracie danych (w środowisku deweloperskim ), to właśnie zrobiłem

Usuń: ib_logfile1 ib_logfile0 aria_log_control aria_log.00000001 tc.log ib_data1

uruchom serwer

Usuń schemat (jeśli zawiera pliki, włóż płytę CD do folderu schematu, usuń wszystko)

Następnie ponownie zaimportowałem bazę danych ze starego zrzutu, który miałem.

Potem zacząłem mariadb i wszystko idzie dobrze. Usunięte pliki zostały ponownie utworzone. ** Ponownie dotyczy to tylko deweloperów. Prawdopodobnie możesz zainstalować swoją bazę danych **


0

Napotkałem ten problem, gdy próbowałem skopiować folder danych bazy danych. Więc zmieniłem folder danych i wykonałem następujące polecenie, aby usunąć wszystkie pliki dziennika:

rm -rf *log*

Następnie przebudowałem okno dokowane i problem został rozwiązany.


0

Rozwiązałem również ten błąd, usuwając tc.log. W XAMPP plik tc.log znajduje się w XAMPP/xamppfiles/var/mysqlfolderze - na moim Macu znajduje się w: /Applications/XAMPP/xamppfiles/var/mysql/tc.log


Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.