SQLinfo.ru - Все о MySQL

Форум пользователей MySQL

Задавайте вопросы, мы ответим

Вы не зашли.

#1 10.10.2016 00:51:07

Elimay
Участник
Зарегистрирован: 10.10.2016
Сообщений: 4

не поднимается БД после сбоя

Не запускается сервер бд. ОС debian + MariaDb. Выдает

Код:

Oct 10 03:16:18 server-db /etc/init.d/mysql[9958]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' resulted in
Oct 10 03:16:18 server-db /etc/init.d/mysql[9958]: #007/usr/bin/mysqladmin: connect to server at 'localhost' failed
Oct 10 03:16:18 server-db /etc/init.d/mysql[9958]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111 "Connection refused")'
Oct 10 03:16:18 server-db /etc/init.d/mysql[9958]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!
Oct 10 03:16:18 server-db /etc/init.d/mysql[9958]:

Код:

root@server-db:/etc/mysql# mysqld
161010  2:57:39 [Note] InnoDB: Using mutexes to ref count buffer pool pages
161010  2:57:39 [Note] InnoDB: The InnoDB memory heap is disabled
161010  2:57:39 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
161010  2:57:39 [Note] InnoDB: Memory barrier is not used
161010  2:57:39 [Note] InnoDB: Compressed tables use zlib 1.2.7
161010  2:57:39 [Note] InnoDB: Using Linux native AIO
161010  2:57:39 [Note] InnoDB: Not using CPU crc32 instructions
161010  2:57:39 [Note] InnoDB: Initializing buffer pool, size = 1.0G
161010  2:57:40 [Note] InnoDB: Completed initialization of buffer pool
161010  2:57:40 [Note] InnoDB: Highest supported file format is Barracuda.
161010  2:57:40 [Note] InnoDB: The log sequence numbers 228309613727 and 228309613727 in ibdata files do not match the log sequence number 228309614092 in the ib_logfiles!
161010  2:57:40 [Note] InnoDB: Database was not shutdown normally!
161010  2:57:40 [Note] InnoDB: Starting crash recovery.
161010  2:57:40 [Note] InnoDB: Reading tablespace information from the .ibd files...
161010  2:57:40 [Note] InnoDB: Restoring possible half-written data pages
161010  2:57:40 [Note] InnoDB: from the doublewrite buffer...
2016-10-10 02:57:40 7f32aa16a760 InnoDB: Error: page 7 log sequence number 234570222776
InnoDB: is in the future! Current system log sequence number 228309614092.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: [url]http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html[/url]
InnoDB: for more information.
2016-10-10 02:57:40 7f32aa16a760 InnoDB: Error: page 2 log sequence number 234761995066
InnoDB: is in the future! Current system log sequence number 228309614092.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: [url]http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html[/url]
InnoDB: for more information.
...
...
...
2016-10-10 02:57:41 7f32aa16a760 InnoDB: Error: page 9238 log sequence number 234762417653
InnoDB: is in the future! Current system log sequence number 228309614092.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: [url]http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html[/url]
InnoDB: for more information.
InnoDB: 106 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 0 row operations to undo
InnoDB: Trx id counter is 549099264
InnoDB: Last MySQL binlog file position 0 16883540, file name /var/log/mysql/mariadb-bin.001057
InnoDB: Cleaning up trx with id 549052271
2016-10-10 02:57:42 7f32aa16a760  InnoDB: Assertion failure in thread 139855578703712 in file trx0trx.cc line 462
InnoDB: Failing assertion: trx->update_undo == NULL
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to [url]http://bugs.mysql.com[/url].
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: [url]http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html[/url]
InnoDB: about forcing recovery.
161010  2:57:42 [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 [url]http://kb.askmonty.org/en/reporting-bugs[/url]

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.0.17-MariaDB-1~wheezy-log
key_buffer_size=8489271296
read_buffer_size=16777216
max_used_connections=0
max_threads=102
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 16648235 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 0x48000
addr2line: 'mysqld': No such file
mysqld(my_print_stacktrace+0x2b)[0x7f32aab6d13b]
mysqld(handle_fatal_signal+0x422)[0x7f32aa6fc202]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf0a0)[0x7f32a9d4d0a0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7f32a83a7165]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x180)[0x7f32a83aa3e0]
mysqld(+0x7fd272)[0x7f32aa979272]
mysqld(+0x7f42d5)[0x7f32aa9702d5]
mysqld(+0x761039)[0x7f32aa8dd039]
mysqld(+0x7e02a5)[0x7f32aa95c2a5]
mysqld(+0x71aaeb)[0x7f32aa896aeb]
mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x68)[0x7f32aa6fe8c8]
mysqld(+0x4321c2)[0x7f32aa5ae1c2]
mysqld(_Z11plugin_initPiPPci+0x702)[0x7f32aa5aefd2]
mysqld(+0x39c615)[0x7f32aa518615]
mysqld(_Z11mysqld_mainiPPc+0x487)[0x7f32aa519237]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x7f32a8393ead]
mysqld(+0x391f2d)[0x7f32aa50df2d]
The manual page at [url]http://dev.mysql.com/doc/mysql/en/crashing.html[/url] contains
information that should help you find out what is causing the crash.

пробовал как написано здесь http://dev.mysql.com/doc/refman/5.6/en/ … overy.html добавлять в конфиг innodb_force_recovery = 1, никаких изменений. Удалять файлы ib_logfile0 и  ib_logfile1 тоже пробовал.

Вот конфиг:

Код:

# MariaDB database server configuration file.
#
# You can copy this file to one of:
# - "/etc/mysql/my.cnf" to set global options,
# - "~/.my.cnf" to set user-specific options.
# 
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#
# For explanations see
# [url]http://dev.mysql.com/doc/mysql/en/server-system-variables.html[/url]

# This will be passed to all mysql clients
# It has been reported that passwords should be enclosed with ticks/quotes
# escpecially if they contain "#" chars...
# Remember to edit /etc/mysql/debian.cnf when changing the socket location.
[client]
port        = 3306
socket        = /var/run/mysqld/mysqld.sock

# Here is entries for some specific programs
# The following values assume you have at least 32M ram

# This was formally known as [safe_mysqld]. Both versions are currently parsed.
[mysqld_safe]
socket        = /var/run/mysqld/mysqld.sock
nice        = 0

[mysqld]
#
# * Basic Settings
#
#innodb_force_recovery = 1
user        = mysql
pid-file    = /var/run/mysqld/mysqld.pid
socket        = /var/run/mysqld/mysqld.sock
port        = 3306
basedir        = /usr
datadir        = /var/lib/mysql
tmpdir        = /tmp
lc_messages_dir    = /usr/share/mysql
lc_messages    = en_US
skip-external-locking
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
#bind-address        = 127.0.0.1
bind-address           = 10.0.2.15
#
# * Fine Tuning
#
max_connections        = 100
connect_timeout        = 5
wait_timeout        = 600
max_allowed_packet    = 32M
thread_cache_size       = 256
sort_buffer_size    = 64M
bulk_insert_buffer_size    = 32M
tmp_table_size        = 64M
max_heap_table_size    = 64M
#
# * MyISAM
#
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched. On error, make copy and try a repair.
myisam_recover          = BACKUP
key_buffer_size        = 8096M
#open-files-limit    = 2000
table_open_cache    = 2000
myisam_sort_buffer_size    = 1024M
concurrent_insert    = 2
read_buffer_size    = 16M
read_rnd_buffer_size    = 8M
#
# * Query Cache Configuration
#
# Cache only tiny result sets, so we can fit more in the query cache.
query_cache_limit        = 256K
query_cache_size        = 128M
# for more write intensive setups, set to DEMAND or OFF
#query_cache_type        = DEMAND
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
# As of 5.1 you can enable the log at runtime!
general_log_file        = /var/log/mysql/mysql.log
general_log             = 1
#
# Error logging goes to syslog due to /etc/mysql/conf.d/mysqld_safe_syslog.cnf.
#
# we do want to know about network errors and such
log_warnings        = 2
#
# Enable the slow query log to see queries with especially long duration
#slow_query_log[={0|1}]
slow_query_log_file    = /var/log/mysql/mariadb-slow.log
long_query_time = 10
#log_slow_rate_limit    = 1000
log_slow_verbosity    = query_plan

#log-queries-not-using-indexes
#log_slow_admin_statements
#
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
#       other settings you may need to change.
#server-id        = 1
#report_host        = master1
#auto_increment_increment = 2
#auto_increment_offset    = 1
log_bin            = /var/log/mysql/mariadb-bin
log_bin_index        = /var/log/mysql/mariadb-bin.index
# not fab for performance, but safer
#sync_binlog        = 1
expire_logs_days    = 10
max_binlog_size         = 200M
# slaves
#relay_log        = /var/log/mysql/relay-bin
#relay_log_index    = /var/log/mysql/relay-bin.index
#relay_log_info_file    = /var/log/mysql/relay-bin.info
#log_slave_updates
#read_only
#
# If applications support it, this stricter sql_mode prevents some
# mistakes like inserting invalid dates etc.
#sql_mode        = NO_ENGINE_SUBSTITUTION,TRADITIONAL
#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
default_storage_engine    = InnoDB
# you can't just change log file size, requires special procedure
innodb_log_file_size    = 128M
innodb_buffer_pool_size    = 2048M
innodb_log_buffer_size    = 32M
innodb_file_per_table    = 1
innodb_open_files    = 200
innodb_io_capacity    = 200
innodb_flush_method    = O_DIRECT
#
# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
#
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem



[mysqldump]
quick
quote-names
max_allowed_packet    = 32M

[mysql]
#no-auto-rehash    # faster start of mysql but no tab completition

[isamchk]
key_buffer        = 32M

#
# * IMPORTANT: Additional settings that can override those from this file!
#   The files must end with '.cnf', otherwise they'll be ignored.
#
!includedir /etc/mysql/conf.d/

Неактивен

 

#2 10.10.2016 16:03:09

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6581

Re: не поднимается БД после сбоя

Удалять ib_logfile — плохо, если база остановлена нештатно. Попробуйте поднять force_recovery до максимального уровня, когда стартует (например, 6 должно завестись, но может и раньше). И после этого dump/restore.

Неактивен

 

#3 10.10.2016 16:21:41

Elimay
Участник
Зарегистрирован: 10.10.2016
Сообщений: 4

Re: не поднимается БД после сбоя

paulus написал:

Удалять ib_logfile — плохо, если база остановлена нештатно. Попробуйте поднять force_recovery до максимального уровня, когда стартует (например, 6 должно завестись, но может и раньше). И после этого dump/restore.

ib_logfile удалялось лишь в качестве экперимента и само собой с откатом, бывали случаи в практике что помогало. По force_recovery  поднимал и до 6, безрезультатно. Попробовал переставить MariaDB. В итоге завелась на force_recovery=6. Делаю бэкап, но полет не стабильный, периодически теряет соединение и не все дампится. Приходится дампить кусками...

mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table `attachments` at row: 33338330
 

Неактивен

 

#4 10.10.2016 18:31:36

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6581

Re: не поднимается БД после сбоя

А что в логе при этом? По идее, с шестеркой не должно падать и должно отдавать пустые данные, если страница не читается.

Неактивен

 

#5 10.10.2016 22:07:47

Elimay
Участник
Зарегистрирован: 10.10.2016
Сообщений: 4

Re: не поднимается БД после сбоя

paulus написал:

А что в логе при этом? По идее, с шестеркой не должно падать и должно отдавать пустые данные, если страница не читается.

Oct 11 06:21:08 server-db mysqld: 161011  6:21:08 [ERROR] InnoDB: Failed to find tablespace for table '"imas"."attachments"' in the cache. Attempting to load the tablespace with space id 376.
Oct 11 06:23:53 server-db mysqld: 2016-10-11 06:23:53 7f6e706f1700  InnoDB: Assertion failure in thread 140112309458688 in file btr0pcur.cc line 445
Oct 11 06:23:53 server-db mysqld: InnoDB: Failing assertion: page_is_comp(next_page) == page_is_comp(page)
Oct 11 06:23:53 server-db mysqld: InnoDB: We intentionally generate a memory trap.
Oct 11 06:23:53 server-db mysqld: InnoDB: Submit a detailed bug report to <a href="http://bugs.mysql.com">http://bugs.mysql.com</a>.
 

Неактивен

 

#6 12.10.2016 01:05:54

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6581

Re: не поднимается БД после сбоя

Ого. А остальные таблички, кроме этой, дампятся? Или на многих такая штука? Я бы попробовал сдампить все, кроме этой, а потом эту вручную — сколько получится.

Неактивен

 

#7 12.10.2016 08:36:23

Elimay
Участник
Зарегистрирован: 10.10.2016
Сообщений: 4

Re: не поднимается БД после сбоя

на нескольких, но их содержание было не интересно. Как оказалось сбой в этой таблице происходил почти в самом конце, если потери и есть то микроскопические в сравнении с размером таблицы. Но столкнулся с проблемой что дробнуть БД не получилось опять же из-за этой таблицы, все время слетал мускл. Пришлось решать проблему физическим удалением из /var/lib/mysql

Неактивен

 

#8 12.10.2016 22:37:39

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6581

Re: не поднимается БД после сбоя

При таких сбоях все равно придется все перезаливать, т.к. InnoDB неконсистентен, так что всё правильно сделали.

Неактивен

 

Board footer

Работает на PunBB
© Copyright 2002–2008 Rickard Andersson