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 datadir
opcji - 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
READ
uprawnienia 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?Odpowiedzi:
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_bin
lub z pliku konfiguracyjnego jakolog_bin=ON
), a wszystko zacznie znowu działać!Aktualizacja
Mówią, że naprawili to w VirtualBox 6.0.6!
źródło
tc.log
błąd przy użyciu Virtualbox na hoście Windows 10.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.
źródło
sudo mv /var/lib/mysql/tc.log /var/lib/mysql/tc_bkp.log
Możesz usunąć
tc.log
w 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
mysql
użytkownikiem a właścicielem identyfikatora folderu współdzielonego, oto fragment tego kodu.źródło
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 **
źródło
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:
Następnie przebudowałem okno dokowane i problem został rozwiązany.
źródło
Rozwiązałem również ten błąd, usuwając tc.log. W XAMPP plik tc.log znajduje się w
XAMPP/xamppfiles/var/mysql
folderze - na moim Macu znajduje się w:/Applications/XAMPP/xamppfiles/var/mysql/tc.log
źródło
Miałem ten problem w oficjalnym kontenerze dokującym MariaDB. Usunięcie pliku dziennika, ponieważ inne oferowane odpowiedzi nie pomogły mi. Mój problem był jednak związany,
mmap
jak sugeruje zaakceptowana odpowiedź.Znalazłem różne rozwiązania tego problemu w moim scenariuszu.
źródło