|
Задавайте вопросы, мы ответим
Вы не зашли.
Добрый день. У меня валятся ошибки после добавления ноды в кластер и в итоге нода не хочет запускатся.
2016-09-27 19:06:21 139731328956160 [Warning] WSREP: Failed to report last committed 58088960, -77 (File descriptor in bad state)
2016-09-27 19:06:21 139731328956160 [Warning] WSREP: Failed to report last committed 58089089, -77 (File descriptor in bad state)
2016-09-27 19:06:21 139731328956160 [Warning] WSREP: Failed to report last committed 58089217, -77 (File descriptor in bad state)
2016-09-27 19:06:21 139731328956160 [Warning] WSREP: Failed to report last committed 58089345, -77 (File descriptor in bad state)
2016-09-27 19:06:21 139731328956160 [Warning] WSREP: Failed to report last committed 58089473, -77 (File descriptor in bad state)
/lib64/libpthread.so.0(+0xf100)[0x7f16123a9100]
2016-09-27 19:06:21 139731328956160 [Warning] WSREP: Failed to report last committed 58089601, -77 (File descriptor in bad state)
/lib64/libc.so.6(gsignal+0x37)[0x7f16107025f7]
/lib64/libc.so.6(abort+0x148)[0x7f1610703ce8]
/lib64/libc.so.6(+0x2e566)[0x7f16106fb566]
/lib64/libc.so.6(+0x2e612)[0x7f16106fb612]
/usr/sbin/mysqld(+0x561ecd)[0x7f1612d3becd]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x1478)[0x7f1612b7d9c8]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f16106eeb15]
/usr/sbin/mysqld(+0x39680d)[0x7f1612b7080d]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
Куда копать подскажите плз, гугл толкового ответа не дал?
mysql Ver 15.1 Distrib 10.1.14-MariaDB
Неактивен
Вобощем кому интересно , сделал через костыль.
Запускаю ноду , она синкается с другой нодой и когда применяется лог выпадает ошибка , которую я описал выше.
Что я сделал - зашел в конфиг mysql и изменил :
wsrep_sst_method = xtrabackup-v2 на wsrep_sst_method=rsync так же указал ноду которую можно на время заблокировать wsrep_sst_donor=donor_name
Дождался когда rsync закончит свою работу и переключился обратно на режим xtrabackup-v2
OS centOS 7 - может у него баг с работой xtrabackup-v2. Но пока что так.
Буду рад увидить не такое костыльно решение.
Неактивен
Проверьте, пожалуйста, что xtrabackup, который стоит в системе, основывается на той же версии MySQL, что запущена. Выглядит как несовместимость версий. Особенно если помогает rsync.
Неактивен
Спасибо за совет.
На офф сайте Mariadb написано что надо всегда использовать версию xtrabackup-v2
Собственно вот что у меня
xtrabackup version 2.3.5 based on MySQL server 5.6.24 Linux (x86_64)
mysql Ver 15.1 Distrib 10.1.14-MariaDB, for Linux (x86_64) using readline 5.1
Насколько я понял то 10.1 - это переписаная 5.6 + 5.7
Поидеии должно работать.
Так же перед этим все работало, эта проблема возникла буквально пару недель назад.
Заметил так же что число WSREP: Failed to report last committed стало больше.
Я думал может это лимиты ядра какие-то , но проверял по лимитам все ок.
Отредактированно Dimashu (29.09.2016 16:03:35)
Неактивен
Сегодня обнаружил что и rsync не помагает
Вот полный лог
[ERROR] WSREP: Trying to launch slave threads before creating connection at 'gcomm://10.10.10.30,10.10.10.32,10.10.10.31'
mysqld: /home/buildbot/buildbot/build/mariadb-10.1.14/sql/wsrep_thd.cc:401: void wsrep_create_appliers(long int): Assertion `0' failed.
2016-09-29 17:52:38 140505433983744 [ERROR] WSREP: gcs/src/gcs.cpp:_join():810: Sending JOIN failed: -103 (Software caused connection abort).
160929 17:52:38 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Server version: 10.1.14-MariaDB
key_buffer_size=134217728
read_buffer_size=8388608
max_used_connections=0
max_threads=502
thread_count=2
2016-09-29 17:52:38 140505433983744 [ERROR] WSREP: Failed to JOIN the cluster after SST
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 6309910 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x48400
2016-09-29 17:52:38 140505523996416 [Warning] WSREP: Failed to report last committed 59523966, -77 (File descriptor in bad state)
2016-09-29 17:52:38 140505523996416 [Warning] WSREP: Failed to report last committed 59524094, -77 (File descriptor in bad state)
2016-09-29 17:52:38 140505523996416 [Warning] WSREP: Failed to report last committed 59524222, -77 (File descriptor in bad state)
2016-09-29 17:52:38 140505523996416 [Warning] WSREP: Failed to report last committed 59546869, -77 (File descriptor in bad state)
......
......
/lib64/libc.so.6(+0x2e566)[0x7fcb52184566]
mysys/stacktrace.c:247(my_print_stacktrace)[0x7fcb52184612]
sql/wsrep_thd.cc:401(wsrep_create_appliers(long))[0x7fcb547c4ecd]
sql/mysqld.cc:5891(mysqld_main(int, char**))[0x7fcb546069c8]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7fcb52177b15]
/usr/sbin/mysqld(+0x39680d)[0x7fcb545f980d]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
Неактивен
Вот мой конфиг , на всякий пожарный
[mysqld]
bind-address=0.0.0.0
collation-server = utf8_general_ci
init-connect = 'SET NAMES utf8'
character-set-server = utf8
socket=/var/lib/mysql/mysql.sock
datadir = /var/lib/mysql
#### TIMEOUT
connect_timeout = 600000
wait_timeout = 28800
max_connections = 500
max_allowed_packet = 512M
max_connect_errors = 10000
net_read_timeout = 600000
net_write_timeout = 600000
#### INNODB
innodb_buffer_pool_size = 30G
innodb_buffer_pool_instances = 15
innodb_flush_method = O_DIRECT
innodb_log_buffer_size = 8M
#Innodb_adaptive_hash_index = 0
innodb_thread_concurrency = 4
innodb_file_per_table = 1
innodb_data_file_path=ibdata1:10M:autoextend
#### OTHER
skip-name-resolve
skip-external-locking
skip-innodb_doublewrite
query_cache_size = 256M
query_cache_limit = 64M
query_cache_type = 1
query_cache_min_res_unit = 2K
#thread_handling = pool-of-threads
thread_pool_size = 8
thread_cache_size = 268
thread-pool-max-threads = 20000
sort_buffer_size = 4M
key_buffer_size = 128M
join_buffer_size = 12M
read_rnd_buffer_size = 8M
read_buffer_size = 8M
table_definition_cache = 2048
table_open_cache = 2048
thread_cache_size = 128
tmp_table_size = 4096M
max_heap_table_size = 4096M
log-error=/var/log/mysql/mysql-error.log
general_log_file=/var/log/mysql/general.log
[galera]
wsrep_on=ON
binlog_format=ROW
innodb_autoinc_lock_mode=2
transaction-isolation = READ-COMMITTED
default_storage_engine=InnoDB
innodb_log_file_size=512M
innodb_flush_log_at_trx_commit=2
innodb_rollback_on_timeout=1
#innodb_lock_wait_timeout=600
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://10.10.10.30,10.10.10.32,10.10.10.31"
wsrep_cluster_name='galera_cluster'
wsrep_node_address='10.10.10.31'
wsrep_node_name='name'
wsrep_retry_autocommit = 3
#wsrep_sst_method = xtrabackup-v2
wsrep_sst_method=rsync
wsrep_sst_donor=name-1
wsrep_sst_auth=login:pass
wsrep_provider_options="gcache.size = 5G"
[mysqldump]
quick
max_allowed_packet = 16M
Неактивен
Вообщем в моем случае проблема была в следующем
mysql был в контейнере openVZ
и все упиралось в лимиты
утсановил ulimit -n 99999 на харде и в контейнере, все заработало и заводится с первого раза. Надеюсь кому-то поможет
Неактивен
Спасибо, что указали решение. Приятно, когда есть обратная связь и возможность узнать новое.
Неактивен
