Помогите восстановить сайты
Помогите восстановить сайты
После непонятной причини лег mysqld, не запускается ни при какой конфигурации что нашел на этом форуме, спросил в соответствующем разделе http://forum.vestacp.com/viewtopic.php?f=32&t=5463 но без ответа, все службы работают кроме mysqld, решил поднимать сайты на другом сервере, установил аналогичную систему с той же конфигурации с пользователями, паролями т.д. тупо копирование папку база данных /var/lib/mysql/имя_базы не работает. прошу помогите месяца работы над сайтом около 800 новостей пропадут, да я знаю что надо было сделать бекап но по объективными причинами этого не было сделано, я не профессионал по администрирование серверов сильно не пинайте, прошу помощи
система
CentOS 6.6 i686
Версия:0.9.8 (i686) Релиз:14 на новом 15
посоветуйте как запустить на старом сервере mysqld или как перенести базу данных на новом сервере
система
CentOS 6.6 i686
Версия:0.9.8 (i686) Релиз:14 на новом 15
посоветуйте как запустить на старом сервере mysqld или как перенести базу данных на новом сервере
Re: Помогите восстановить сайты
неужели ни кто не может помочь???
Re: Помогите восстановить сайты
привет, что в логе ошибок mysql на старом сервере?
Re: Помогите восстановить сайты
SpoilerShow
Code: Select all
key_buffer_size=16777216
read_buffer_size=1048576
max_used_connections=0
max_threads=70
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 231941 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
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 = 0 thread_stack 0x30000
/usr/libexec/mysqld(my_print_stacktrace+0x34)[0x83effe4]
/usr/libexec/mysqld(handle_fatal_signal+0x48c)[0x82bdd0c]
[0xb77b6500]
[0xb77b6420]
/lib/libc.so.6(gsignal+0x51)[0xb726d871]
/lib/libc.so.6(abort+0x17a)[0xb726f14a]
/usr/libexec/mysqld[0x84b22a7]
/usr/libexec/mysqld[0x84b2890]
/usr/libexec/mysqld[0x857da3a]
/usr/libexec/mysqld[0x85734fe]
/usr/libexec/mysqld[0x84b0f59]
/usr/libexec/mysqld[0x84a2f56]
/usr/libexec/mysqld[0x84a7599]
/lib/libpthread.so.0(+0x6b39)[0xb7799b39]
/lib/libc.so.6(clone+0x5e)[0xb7325c2e]
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.
151118 21:45:30 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
151119 01:46:47 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
151119 1:46:47 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
151119 1:46:47 [Note] /usr/libexec/mysqld (mysqld 5.5.44) starting as process 12504 ...
151119 1:46:47 [Note] Plugin 'FEDERATED' is disabled.
151119 1:46:47 InnoDB: The InnoDB memory heap is disabled
151119 1:46:47 InnoDB: Mutexes and rw_locks use GCC atomic builtins
151119 1:46:47 InnoDB: Compressed tables use zlib 1.2.3
151119 1:46:47 InnoDB: Using Linux native AIO
151119 1:46:47 InnoDB: Initializing buffer pool, size = 128.0M
151119 1:46:47 InnoDB: Completed initialization of buffer pool
151119 1:46:47 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
151119 1:46:47 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: 2 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 2 row operations to undo
InnoDB: Trx id counter is 4EA00
InnoDB: Cleaning up trx with id 4EA90
InnoDB: Cleaning up trx with id 4EA8A
151119 1:46:47 InnoDB: Waiting for the background threads to start
151119 1:46:48 InnoDB: 5.5.44 started; log sequence number 183581774
151119 1:46:48 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
151119 1:46:48 [Note] - '0.0.0.0' resolves to '0.0.0.0';
151119 1:46:48 [Note] Server socket created on IP: '0.0.0.0'.
151119 1:46:48 InnoDB: Assertion failure in thread 2743122800 in file trx0purge.c line 840
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
21:46:48 UTC - 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.
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.
key_buffer_size=16777216
read_buffer_size=1048576
max_used_connections=0
max_threads=70
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 231941 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
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 = 0 thread_stack 0x30000
/usr/libexec/mysqld(my_print_stacktrace+0x34)[0x83effe4]
/usr/libexec/mysqld(handle_fatal_signal+0x48c)[0x82bdd0c]
[0xb77a9500]
[0xb77a9420]
/lib/libc.so.6(gsignal+0x51)[0xb7260871]
/lib/libc.so.6(abort+0x17a)[0xb726214a]
/usr/libexec/mysqld[0x84b22a7]
/usr/libexec/mysqld[0x84b2890]
/usr/libexec/mysqld[0x857da3a]
/usr/libexec/mysqld[0x85734fe]
/usr/libexec/mysqld[0x84b0f59]
/usr/libexec/mysqld[0x84a2f56]
/usr/libexec/mysqld[0x84a7599]
/lib/libpthread.so.0(+0x6b39)[0xb778cb39]
/lib/libc.so.6(clone+0x5e)[0xb7318c2e]
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.
151119 01:46:48 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
151121 04:23:32 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
151121 4:23:32 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
151121 4:23:32 [Note] /usr/libexec/mysqld (mysqld 5.5.44) starting as process 22260 ...
151121 4:23:32 [Note] Plugin 'FEDERATED' is disabled.
151121 4:23:32 InnoDB: The InnoDB memory heap is disabled
151121 4:23:32 InnoDB: Mutexes and rw_locks use GCC atomic builtins
151121 4:23:32 InnoDB: Compressed tables use zlib 1.2.3
151121 4:23:32 InnoDB: Using Linux native AIO
151121 4:23:32 InnoDB: Initializing buffer pool, size = 128.0M
151121 4:23:32 InnoDB: Completed initialization of buffer pool
151121 4:23:32 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
151121 4:23:32 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: 2 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 2 row operations to undo
InnoDB: Trx id counter is 4EA00
InnoDB: Cleaning up trx with id 4EA90
InnoDB: Cleaning up trx with id 4EA8A
151121 4:23:32 InnoDB: Waiting for the background threads to start
151121 4:23:33 InnoDB: 5.5.44 started; log sequence number 183581774
151121 4:23:33 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
151121 4:23:33 [Note] - '0.0.0.0' resolves to '0.0.0.0';
151121 4:23:33 [Note] Server socket created on IP: '0.0.0.0'.
151121 4:23:33 InnoDB: Assertion failure in thread 2743122800 in file trx0purge.c line 840
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
00:23:33 UTC - 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.
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.
key_buffer_size=16777216
read_buffer_size=1048576
max_used_connections=0
max_threads=70
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 231941 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
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 = 0 thread_stack 0x30000
/usr/libexec/mysqld(my_print_stacktrace+0x34)[0x83effe4]
/usr/libexec/mysqld(handle_fatal_signal+0x48c)[0x82bdd0c]
[0xb77c2500]
[0xb77c2420]
/lib/libc.so.6(gsignal+0x51)[0xb7279871]
/lib/libc.so.6(abort+0x17a)[0xb727b14a]
/usr/libexec/mysqld[0x84b22a7]
/usr/libexec/mysqld[0x84b2890]
/usr/libexec/mysqld[0x857da3a]
/usr/libexec/mysqld[0x85734fe]
/usr/libexec/mysqld[0x84b0f59]
/usr/libexec/mysqld[0x84a2f56]
151121 4:23:33 [Note] Event Scheduler: Loaded 0 events
151121 4:23:33 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.5.44' socket: '/var/lib/mysql/mysql.sock' port: 3306 MySQL Community Server (GPL) by Remi
/usr/libexec/mysqld[0x84a7599]
/lib/libpthread.so.0(+0x6b39)[0xb77a5b39]
/lib/libc.so.6(clone+0x5e)[0xb7331c2e]
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.
151121 04:23:33 mysqld_safe Number of processes running now: 0
151121 04:23:33 mysqld_safe mysqld restarted
151121 4:23:33 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
151121 4:23:33 [Note] /usr/libexec/mysqld (mysqld 5.5.44) starting as process 22298 ...
151121 4:23:33 [Note] Plugin 'FEDERATED' is disabled.
151121 4:23:33 InnoDB: The InnoDB memory heap is disabled
151121 4:23:33 InnoDB: Mutexes and rw_locks use GCC atomic builtins
151121 4:23:33 InnoDB: Compressed tables use zlib 1.2.3
151121 4:23:33 InnoDB: Using Linux native AIO
151121 4:23:33 InnoDB: Initializing buffer pool, size = 128.0M
151121 4:23:33 InnoDB: Completed initialization of buffer pool
151121 4:23:33 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
151121 4:23:33 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: 2 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 2 row operations to undo
InnoDB: Trx id counter is 4EA00
InnoDB: Cleaning up trx with id 4EA90
InnoDB: Cleaning up trx with id 4EA8A
151121 4:23:33 InnoDB: Waiting for the background threads to start
151121 4:23:34 InnoDB: 5.5.44 started; log sequence number 183581774
151121 4:23:34 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
151121 4:23:34 [Note] - '0.0.0.0' resolves to '0.0.0.0';
151121 4:23:34 [Note] Server socket created on IP: '0.0.0.0'.
151121 4:23:34 InnoDB: Assertion failure in thread 2743122800 in file trx0purge.c line 840
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
00:23:34 UTC - 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.
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.
key_buffer_size=16777216
read_buffer_size=1048576
max_used_connections=0
max_threads=70
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 231941 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
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 = 0 thread_stack 0x30000
/usr/libexec/mysqld(my_print_stacktrace+0x34)[0x83effe4]
/usr/libexec/mysqld(handle_fatal_signal+0x48c)[0x82bdd0c]
[0xb778e500]
[0xb778e420]
/lib/libc.so.6(gsignal+0x51)[0xb7245871]
/lib/libc.so.6(abort+0x17a)[0xb724714a]
/usr/libexec/mysqld[0x84b22a7]
/usr/libexec/mysqld[0x84b2890]
/usr/libexec/mysqld[0x857da3a]
/usr/libexec/mysqld[0x85734fe]
/usr/libexec/mysqld[0x84b0f59]
/usr/libexec/mysqld[0x84a2f56]
/usr/libexec/mysqld[0x84a7599]
/lib/libpthread.so.0(+0x6b39)[0xb7771b39]
/lib/libc.so.6(clone+0x5e)[0xb72fdc2e]
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.
151121 04:23:34 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
151121 18:19:15 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
151121 18:19:15 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
151121 18:19:15 [Note] /usr/libexec/mysqld (mysqld 5.5.44) starting as process 28881 ...
151121 18:19:15 [Note] Plugin 'FEDERATED' is disabled.
151121 18:19:15 InnoDB: The InnoDB memory heap is disabled
151121 18:19:15 InnoDB: Mutexes and rw_locks use GCC atomic builtins
151121 18:19:15 InnoDB: Compressed tables use zlib 1.2.3
151121 18:19:15 InnoDB: Using Linux native AIO
151121 18:19:15 InnoDB: Initializing buffer pool, size = 128.0M
151121 18:19:15 InnoDB: Completed initialization of buffer pool
151121 18:19:15 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
151121 18:19:15 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: 2 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 2 row operations to undo
InnoDB: Trx id counter is 4EA00
InnoDB: Cleaning up trx with id 4EA90
InnoDB: Cleaning up trx with id 4EA8A
151121 18:19:15 InnoDB: Waiting for the background threads to start
151121 18:19:16 InnoDB: 5.5.44 started; log sequence number 183581774
151121 18:19:16 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
151121 18:19:16 [Note] - '0.0.0.0' resolves to '0.0.0.0';
151121 18:19:16 [Note] Server socket created on IP: '0.0.0.0'.
151121 18:19:16 InnoDB: Assertion failure in thread 2743122800 in file trx0purge.c line 840
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:19:16 UTC - 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.
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.
key_buffer_size=16777216
read_buffer_size=1048576
max_used_connections=0
max_threads=20
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 77971 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
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 = 0 thread_stack 0x30000
/usr/libexec/mysqld(my_print_stacktrace+0x34)[0x83effe4]
/usr/libexec/mysqld(handle_fatal_signal+0x48c)[0x82bdd0c]
[0xb77b4500]
[0xb77b4420]
/lib/libc.so.6(gsignal+0x51)[0xb726b871]
/lib/libc.so.6(abort+0x17a)[0xb726d14a]
/usr/libexec/mysqld[0x84b22a7]
/usr/libexec/mysqld[0x84b2890]
/usr/libexec/mysqld[0x857da3a]
/usr/libexec/mysqld[0x85734fe]
/usr/libexec/mysqld[0x84b0f59]
/usr/libexec/mysqld[0x84a2f56]
/usr/libexec/mysqld[0x84a7599]
/lib/libpthread.so.0(+0x6b39)[0xb7797b39]
/lib/libc.so.6(clone+0x5e)[0xb7323c2e]
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.
151121 18:19:16 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
151121 18:19:25 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
151121 18:19:25 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
151121 18:19:25 [Note] /usr/libexec/mysqld (mysqld 5.5.44) starting as process 29595 ...
151121 18:19:25 [Note] Plugin 'FEDERATED' is disabled.
151121 18:19:25 InnoDB: The InnoDB memory heap is disabled
151121 18:19:25 InnoDB: Mutexes and rw_locks use GCC atomic builtins
151121 18:19:25 InnoDB: Compressed tables use zlib 1.2.3
151121 18:19:25 InnoDB: Using Linux native AIO
151121 18:19:25 InnoDB: Initializing buffer pool, size = 128.0M
151121 18:19:25 InnoDB: Completed initialization of buffer pool
151121 18:19:25 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
151121 18:19:25 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: 2 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 2 row operations to undo
InnoDB: Trx id counter is 4EA00
InnoDB: Cleaning up trx with id 4EA90
InnoDB: Cleaning up trx with id 4EA8A
151121 18:19:25 InnoDB: Waiting for the background threads to start
151121 18:19:26 InnoDB: 5.5.44 started; log sequence number 183581774
151121 18:19:26 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
151121 18:19:26 [Note] - '0.0.0.0' resolves to '0.0.0.0';
151121 18:19:26 [Note] Server socket created on IP: '0.0.0.0'.
151121 18:19:26 InnoDB: Assertion failure in thread 2743065456 in file trx0purge.c line 840
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:19:26 UTC - 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.
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.
key_buffer_size=16777216
read_buffer_size=1048576
max_used_connections=0
max_threads=20
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 77971 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
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 = 0 thread_stack 0x30000
/usr/libexec/mysqld(my_print_stacktrace+0x34)[0x83effe4]
/usr/libexec/mysqld(handle_fatal_signal+0x48c)[0x82bdd0c]
[0xb771c500]
[0xb771c420]
/lib/libc.so.6(gsignal+0x51)[0xb71d3871]
/lib/libc.so.6(abort+0x17a)[0xb71d514a]
/usr/libexec/mysqld[0x84b22a7]
/usr/libexec/mysqld[0x84b2890]
/usr/libexec/mysqld[0x857da3a]
/usr/libexec/mysqld[0x85734fe]
/usr/libexec/mysqld[0x84b0f59]
/usr/libexec/mysqld[0x84a2f56]
/usr/libexec/mysqld[0x84a7599]
/lib/libpthread.so.0(+0x6b39)[0xb76ffb39]
/lib/libc.so.6(clone+0x5e)[0xb728bc2e]
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.
151121 18:19:26 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
151121 18:20:25 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
151121 18:20:25 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
151121 18:20:25 [Note] /usr/libexec/mysqld (mysqld 5.5.44) starting as process 30508 ...
151121 18:20:25 [Note] Plugin 'FEDERATED' is disabled.
151121 18:20:25 InnoDB: The InnoDB memory heap is disabled
151121 18:20:25 InnoDB: Mutexes and rw_locks use GCC atomic builtins
151121 18:20:25 InnoDB: Compressed tables use zlib 1.2.3
151121 18:20:25 InnoDB: Using Linux native AIO
151121 18:20:25 InnoDB: Initializing buffer pool, size = 128.0M
151121 18:20:25 InnoDB: Completed initialization of buffer pool
151121 18:20:25 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
151121 18:20:25 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: 2 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 2 row operations to undo
InnoDB: Trx id counter is 4EA00
InnoDB: Cleaning up trx with id 4EA90
InnoDB: Cleaning up trx with id 4EA8A
151121 18:20:25 InnoDB: Waiting for the background threads to start
151121 18:20:26 InnoDB: 5.5.44 started; log sequence number 183581774
151121 18:20:26 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
151121 18:20:26 [Note] - '0.0.0.0' resolves to '0.0.0.0';
151121 18:20:26 [Note] Server socket created on IP: '0.0.0.0'.
151121 18:20:26 InnoDB: Assertion failure in thread 2743122800 in file trx0purge.c line 840
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:20:26 UTC - 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.
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.
key_buffer_size=16777216
read_buffer_size=1048576
max_used_connections=0
max_threads=20
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 77971 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
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 = 0 thread_stack 0x30000
/usr/libexec/mysqld(my_print_stacktrace+0x34)[0x83effe4]
/usr/libexec/mysqld(handle_fatal_signal+0x48c)[0x82bdd0c]
[0xb7744500]
[0xb7744420]
/lib/libc.so.6(gsignal+0x51)[0xb71fb871]
/lib/libc.so.6(abort+0x17a)[0xb71fd14a]
/usr/libexec/mysqld[0x84b22a7]
/usr/libexec/mysqld[0x84b2890]
/usr/libexec/mysqld[0x857da3a]
/usr/libexec/mysqld[0x85734fe]
/usr/libexec/mysqld[0x84b0f59]
/usr/libexec/mysqld[0x84a2f56]
/usr/libexec/mysqld[0x84a7599]
/lib/libpthread.so.0(+0x6b39)[0xb7727b39]
/lib/libc.so.6(clone+0x5e)[0xb72b3c2e]
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.
151121 18:20:26 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
151121 18:22:35 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
151121 18:22:35 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
151121 18:22:35 [Note] /usr/libexec/mysqld (mysqld 5.5.44) starting as process 1030 ...
151121 18:22:35 [Note] Plugin 'FEDERATED' is disabled.
151121 18:22:35 InnoDB: The InnoDB memory heap is disabled
151121 18:22:35 InnoDB: Mutexes and rw_locks use GCC atomic builtins
151121 18:22:35 InnoDB: Compressed tables use zlib 1.2.3
151121 18:22:35 InnoDB: Using Linux native AIO
151121 18:22:35 InnoDB: Initializing buffer pool, size = 128.0M
151121 18:22:35 InnoDB: Completed initialization of buffer pool
151121 18:22:35 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
151121 18:22:35 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: 2 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 2 row operations to undo
InnoDB: Trx id counter is 4EA00
InnoDB: Cleaning up trx with id 4EA90
InnoDB: Cleaning up trx with id 4EA8A
151121 18:22:35 InnoDB: Waiting for the background threads to start
151121 18:22:36 InnoDB: 5.5.44 started; log sequence number 183581774
151121 18:22:36 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
151121 18:22:36 [Note] - '0.0.0.0' resolves to '0.0.0.0';
151121 18:22:36 [Note] Server socket created on IP: '0.0.0.0'.
151121 18:22:36 InnoDB: Assertion failure in thread 2757925744 in file trx0purge.c line 840
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:22:36 UTC - 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.
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.
key_buffer_size=1048576
read_buffer_size=1048576
max_used_connections=0
max_threads=20
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 62611 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
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 = 0 thread_stack 0x30000
/usr/libexec/mysqld(my_print_stacktrace+0x34)[0x83effe4]
/usr/libexec/mysqld(handle_fatal_signal+0x48c)[0x82bdd0c]
[0xb76ef500]
[0xb76ef420]
/lib/libc.so.6(gsignal+0x51)[0xb71a6871]
/lib/libc.so.6(abort+0x17a)[0xb71a814a]
/usr/libexec/mysqld[0x84b22a7]
/usr/libexec/mysqld[0x84b2890]
/usr/libexec/mysqld[0x857da3a]
/usr/libexec/mysqld[0x85734fe]
/usr/libexec/mysqld[0x84b0f59]
/usr/libexec/mysqld[0x84a2f56]
/usr/libexec/mysqld[0x84a7599]
/lib/libpthread.so.0(+0x6b39)[0xb76d2b39]
/lib/libc.so.6(clone+0x5e)[0xb725ec2e]
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.
151121 18:22:36 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
151121 18:29:24 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
151121 18:29:24 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
151121 18:29:24 [Note] /usr/libexec/mysqld (mysqld 5.5.44) starting as process 1765 ...
151121 18:29:24 [Note] Plugin 'FEDERATED' is disabled.
151121 18:29:24 InnoDB: The InnoDB memory heap is disabled
151121 18:29:24 InnoDB: Mutexes and rw_locks use GCC atomic builtins
151121 18:29:24 InnoDB: Compressed tables use zlib 1.2.3
151121 18:29:24 InnoDB: Using Linux native AIO
151121 18:29:24 InnoDB: Initializing buffer pool, size = 128.0M
151121 18:29:24 InnoDB: Completed initialization of buffer pool
151121 18:29:24 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
151121 18:29:24 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: 2 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 2 row operations to undo
InnoDB: Trx id counter is 4EA00
InnoDB: Cleaning up trx with id 4EA90
InnoDB: Cleaning up trx with id 4EA8A
151121 18:29:24 InnoDB: Waiting for the background threads to start
151121 18:29:25 InnoDB: 5.5.44 started; log sequence number 183581774
151121 18:29:25 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
151121 18:29:25 [Note] - '0.0.0.0' resolves to '0.0.0.0';
151121 18:29:25 [Note] Server socket created on IP: '0.0.0.0'.
151121 18:29:25 InnoDB: Assertion failure in thread 2758974320 in file trx0purge.c line 840
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:29:25 UTC - 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.
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.
key_buffer_size=1048576
read_buffer_size=1048576
max_used_connections=0
max_threads=20
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 62611 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
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 = 0 thread_stack 0x30000
/usr/libexec/mysqld(my_print_stacktrace+0x34)[0x83effe4]
/usr/libexec/mysqld(handle_fatal_signal+0x48c)[0x82bdd0c]
[0xb778c500]
[0xb778c420]
/lib/libc.so.6(gsignal+0x51)[0xb7243871]
/lib/libc.so.6(abort+0x17a)[0xb724514a]
/usr/libexec/mysqld[0x84b22a7]
/usr/libexec/mysqld[0x84b2890]
/usr/libexec/mysqld[0x857da3a]
/usr/libexec/mysqld[0x85734fe]
/usr/libexec/mysqld[0x84b0f59]
/usr/libexec/mysqld[0x84a2f56]
/usr/libexec/mysqld[0x84a7599]
/lib/libpthread.so.0(+0x6b39)[0xb776fb39]
/lib/libc.so.6(clone+0x5e)[0xb72fbc2e]
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.
151121 18:29:25 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
151121 18:59:08 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
151121 18:59:08 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
151121 18:59:08 [Note] /usr/libexec/mysqld (mysqld 5.5.44) starting as process 2552 ...
151121 18:59:08 [Note] Plugin 'FEDERATED' is disabled.
151121 18:59:08 InnoDB: The InnoDB memory heap is disabled
151121 18:59:08 InnoDB: Mutexes and rw_locks use GCC atomic builtins
151121 18:59:08 InnoDB: Compressed tables use zlib 1.2.3
151121 18:59:08 InnoDB: Using Linux native AIO
151121 18:59:08 InnoDB: Initializing buffer pool, size = 128.0M
151121 18:59:08 InnoDB: Completed initialization of buffer pool
151121 18:59:08 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
151121 18:59:08 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: 2 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 2 row operations to undo
InnoDB: Trx id counter is 4EA00
InnoDB: Cleaning up trx with id 4EA90
InnoDB: Cleaning up trx with id 4EA8A
151121 18:59:08 InnoDB: Waiting for the background threads to start
151121 18:59:09 InnoDB: 5.5.44 started; log sequence number 183581774
151121 18:59:09 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
151121 18:59:09 [Note] - '0.0.0.0' resolves to '0.0.0.0';
151121 18:59:09 [Note] Server socket created on IP: '0.0.0.0'.
151121 18:59:09 InnoDB: Assertion failure in thread 2758974320 in file trx0purge.c line 840
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:59:09 UTC - 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.
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.
key_buffer_size=1048576
read_buffer_size=1048576
max_used_connections=0
max_threads=20
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 62611 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
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 = 0 thread_stack 0x30000
/usr/libexec/mysqld(my_print_stacktrace+0x34)[0x83effe4]
/usr/libexec/mysqld(handle_fatal_signal+0x48c)[0x82bdd0c]
[0xb777b500]
[0xb777b420]
/lib/libc.so.6(gsignal+0x51)[0xb7232871]
/lib/libc.so.6(abort+0x17a)[0xb723414a]
/usr/libexec/mysqld[0x84b22a7]
/usr/libexec/mysqld[0x84b2890]
/usr/libexec/mysqld[0x857da3a]
/usr/libexec/mysqld[0x85734fe]
/usr/libexec/mysqld[0x84b0f59]
/usr/libexec/mysqld[0x84a2f56]
/usr/libexec/mysqld[0x84a7599]
/lib/libpthread.so.0(+0x6b39)[0xb775eb39]
/lib/libc.so.6(clone+0x5e)[0xb72eac2e]
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.
151121 18:59:09 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
151121 19:12:07 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
151121 19:12:07 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
151121 19:12:07 [Note] /usr/libexec/mysqld (mysqld 5.5.44) starting as process 4101 ...
151121 19:12:07 [Note] Plugin 'FEDERATED' is disabled.
151121 19:12:07 InnoDB: The InnoDB memory heap is disabled
151121 19:12:07 InnoDB: Mutexes and rw_locks use GCC atomic builtins
151121 19:12:07 InnoDB: Compressed tables use zlib 1.2.3
151121 19:12:07 InnoDB: Using Linux native AIO
151121 19:12:07 InnoDB: Initializing buffer pool, size = 128.0M
151121 19:12:07 InnoDB: Completed initialization of buffer pool
151121 19:12:07 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
151121 19:12:07 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: 2 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 2 row operations to undo
InnoDB: Trx id counter is 4EA00
InnoDB: Cleaning up trx with id 4EA90
InnoDB: Cleaning up trx with id 4EA8A
151121 19:12:07 InnoDB: Waiting for the background threads to start
151121 19:12:08 InnoDB: 5.5.44 started; log sequence number 183581774
151121 19:12:08 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
151121 19:12:08 [Note] - '0.0.0.0' resolves to '0.0.0.0';
151121 19:12:08 [Note] Server socket created on IP: '0.0.0.0'.
151121 19:12:08 InnoDB: Assertion failure in thread 2743122800 in file trx0purge.c line 840
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
15:12:08 UTC - 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.
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.
key_buffer_size=16777216
read_buffer_size=1048576
max_used_connections=0
max_threads=200
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 632262 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
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 = 0 thread_stack 0x30000
/usr/libexec/mysqld(my_print_stacktrace+0x34)[0x83effe4]
/usr/libexec/mysqld(handle_fatal_signal+0x48c)[0x82bdd0c]
[0xb7747500]
[0xb7747420]
/lib/libc.so.6(gsignal+0x51)[0xb71fe871]
/lib/libc.so.6(abort+0x17a)[0xb720014a]
/usr/libexec/mysqld[0x84b22a7]
/usr/libexec/mysqld[0x84b2890]
/usr/libexec/mysqld[0x857da3a]
/usr/libexec/mysqld[0x85734fe]
/usr/libexec/mysqld[0x84b0f59]
/usr/libexec/mysqld[0x84a2f56]
/usr/libexec/mysqld[0x84a7599]
/lib/libpthread.so.0(+0x6b39)[0xb772ab39]
/lib/libc.so.6(clone+0x5e)[0xb72b6c2e]
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.
151121 19:12:08 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
151121 19:12:39 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
151121 19:12:39 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
151121 19:12:39 [Note] /usr/libexec/mysqld (mysqld 5.5.44) starting as process 4810 ...
151121 19:12:39 [Note] Plugin 'FEDERATED' is disabled.
151121 19:12:39 InnoDB: The InnoDB memory heap is disabled
151121 19:12:39 InnoDB: Mutexes and rw_locks use GCC atomic builtins
151121 19:12:39 InnoDB: Compressed tables use zlib 1.2.3
151121 19:12:39 InnoDB: Using Linux native AIO
151121 19:12:39 InnoDB: Initializing buffer pool, size = 128.0M
151121 19:12:39 InnoDB: Completed initialization of buffer pool
151121 19:12:39 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
151121 19:12:39 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: 2 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 2 row operations to undo
InnoDB: Trx id counter is 4EA00
InnoDB: Cleaning up trx with id 4EA90
InnoDB: Cleaning up trx with id 4EA8A
151121 19:12:40 InnoDB: Waiting for the background threads to start
151121 19:12:41 InnoDB: 5.5.44 started; log sequence number 183581774
151121 19:12:41 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
151121 19:12:41 [Note] - '0.0.0.0' resolves to '0.0.0.0';
151121 19:12:41 [Note] Server socket created on IP: '0.0.0.0'.
151121 19:12:41 InnoDB: Assertion failure in thread 2743122800 in file trx0purge.c line 840
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
15:12:41 UTC - 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.
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.
key_buffer_size=16777216
read_buffer_size=1048576
max_used_connections=0
max_threads=200
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 632262 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
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 = 0 thread_stack 0x30000
/usr/libexec/mysqld(my_print_stacktrace+0x34)[0x83effe4]
/usr/libexec/mysqld(handle_fatal_signal+0x48c)[0x82bdd0c]
[0xb77e0500]
[0xb77e0420]
/lib/libc.so.6(gsignal+0x51)[0xb7297871]
/lib/libc.so.6(abort+0x17a)[0xb729914a]
/usr/libexec/mysqld[0x84b22a7]
/usr/libexec/mysqld[0x84b2890]
/usr/libexec/mysqld[0x857da3a]
/usr/libexec/mysqld[0x85734fe]
/usr/libexec/mysqld[0x84b0f59]
/usr/libexec/mysqld[0x84a2f56]
/usr/libexec/mysqld[0x84a7599]
/lib/libpthread.so.0(+0x6b39)[0xb77c3b39]
/lib/libc.so.6(clone+0x5e)[0xb734fc2e]
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.
151121 19:12:41 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
151121 19:12:56 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
151121 19:12:56 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
151121 19:12:56 [Note] /usr/libexec/mysqld (mysqld 5.5.44) starting as process 5344 ...
151121 19:12:56 [Note] Plugin 'FEDERATED' is disabled.
151121 19:12:56 InnoDB: The InnoDB memory heap is disabled
151121 19:12:56 InnoDB: Mutexes and rw_locks use GCC atomic builtins
151121 19:12:56 InnoDB: Compressed tables use zlib 1.2.3
151121 19:12:56 InnoDB: Using Linux native AIO
151121 19:12:56 InnoDB: Initializing buffer pool, size = 128.0M
151121 19:12:56 InnoDB: Completed initialization of buffer pool
151121 19:12:56 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
151121 19:12:56 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: 2 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 2 row operations to undo
InnoDB: Trx id counter is 4EA00
InnoDB: Cleaning up trx with id 4EA90
InnoDB: Cleaning up trx with id 4EA8A
151121 19:12:56 InnoDB: Waiting for the background threads to start
151121 19:12:57 InnoDB: 5.5.44 started; log sequence number 183581774
151121 19:12:57 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
151121 19:12:57 [Note] - '0.0.0.0' resolves to '0.0.0.0';
151121 19:12:57 [Note] Server socket created on IP: '0.0.0.0'.
151121 19:12:57 InnoDB: Assertion failure in thread 2742074224 in file trx0purge.c line 840
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
15:12:57 UTC - 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.
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.
key_buffer_size=16777216
read_buffer_size=1048576
max_used_connections=0
max_threads=200
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 632262 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
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 = 0 thread_stack 0x30000
/usr/libexec/mysqld(my_print_stacktrace+0x34)[0x83effe4]
/usr/libexec/mysqld(handle_fatal_signal+0x48c)[0x82bdd0c]
[0xb7707500]
[0xb7707420]
/lib/libc.so.6(gsignal+0x51)[0xb71be871]
/lib/libc.so.6(abort+0x17a)[0xb71c014a]
/usr/libexec/mysqld[0x84b22a7]
/usr/libexec/mysqld[0x84b2890]
/usr/libexec/mysqld[0x857da3a]
/usr/libexec/mysqld[0x85734fe]
/usr/libexec/mysqld[0x84b0f59]
/usr/libexec/mysqld[0x84a2f56]
/usr/libexec/mysqld[0x84a7599]
/lib/libpthread.so.0(+0x6b39)[0xb76eab39]
/lib/libc.so.6(clone+0x5e)[0xb7276c2e]
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.
151121 19:12:57 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
Re: Помогите восстановить сайты
думаю в этом отрезке случилось что то и вообще что за ип адреса
что легче восстановит старый сервер или базу перенести на новую(правда не знаю как) ?
SpoilerShow
Code: Select all
Version: '5.5.44' socket: '/var/lib/mysql/mysql.sock' port: 3306 MySQL Community Server (GPL) by Remi
151003 4:29:06 [Warning] IP address '122.224.6.150' could not be resolved: Name or service not known
151004 18:29:49 [Warning] IP address '5.39.222.253' could not be resolved: Name or service not known
151005 14:59:38 [Warning] IP address '222.186.34.224' could not be resolved: Name or service not known
151008 4:58:12 [Warning] IP address '118.193.218.125' could not be resolved: Name or service not known
151008 12:47:55 [Warning] IP address '223.4.12.160' could not be resolved: Name or service not known
151009 8:27:01 [Warning] IP address '223.100.67.157' could not be resolved: Temporary failure in name resolution
151009 8:27:03 [Warning] IP address '223.100.67.157' could not be resolved: Temporary failure in name resolution
151009 8:27:03 [Warning] IP address '223.100.67.157' could not be resolved: Temporary failure in name resolution
151009 8:27:05 [Warning] IP address '223.100.67.157' could not be resolved: Temporary failure in name resolution
151011 7:56:15 [Warning] IP address '211.149.147.164' could not be resolved: Name or service not known
151012 0:45:16 [Warning] IP address '61.142.253.210' could not be resolved: Name or service not known
151012 9:26:16 [Warning] IP address '219.151.9.44' could not be resolved: Name or service not known
151013 20:38:18 [Warning] IP address '222.186.30.203' could not be resolved: Name or service not known
151015 11:09:22 [Warning] IP address '125.64.94.200' could not be resolved: Name or service not known
151017 0:16:06 [Warning] IP address '218.93.202.21' could not be resolved: Name or service not known
151018 19:04:58 [Warning] IP address '103.245.209.42' could not be resolved: Name or service not known
151019 15:38:00 [Warning] IP address '117.34.87.75' could not be resolved: Name or service not known
151020 6:57:16 [Warning] IP address '60.191.129.138' could not be resolved: Name or service not known
151020 15:13:42 [Warning] IP address '211.149.222.208' could not be resolved: Name or service not known
151020 15:15:33 [Warning] IP address '122.114.119.6' could not be resolved: Temporary failure in name resolution
151020 15:15:35 [Warning] IP address '122.114.119.6' could not be resolved: Temporary failure in name resolution
151020 15:15:36 [Warning] IP address '122.114.119.6' could not be resolved: Temporary failure in name resolution
151020 15:15:41 [Warning] IP address '122.114.119.6' could not be resolved: Temporary failure in name resolution
151020 15:15:42 [Warning] IP address '122.114.119.6' could not be resolved: Temporary failure in name resolution
151021 3:37:20 [Warning] IP address '122.0.114.25' could not be resolved: Name or service not known
151023 3:22:35 [Warning] IP address '58.221.47.37' could not be resolved: Name or service not known
151024 8:30:20 [Warning] IP address '111.72.252.91' could not be resolved: Name or service not known
151027 19:01:09 [Warning] IP address '61.136.156.150' could not be resolved: Name or service not known
151029 16:01:36 [Warning] IP address '198.61.234.161' could not be resolved: Name or service not known
151029 21:33:55 [Warning] IP address '222.186.34.82' could not be resolved: Name or service not known
151030 23:12:23 [Warning] IP address '222.186.34.107' could not be resolved: Name or service not known
151101 11:02:19 [Warning] IP address '59.56.69.174' could not be resolved: Name or service not known
151102 7:36:28 [Warning] IP address '146.166.181.233' could not be resolved: Name or service not known
151103 11:01:45 [Warning] IP address '222.186.30.76' could not be resolved: Name or service not known
151103 18:47:39 [Warning] IP address '104.202.32.129' has been resolved to the host name '129.32-202-104.rdns.scalabledns.com', which resembles IPv4-address itself.
151104 22:36:20 [Warning] IP address '222.186.58.140' could not be resolved: Name or service not known
151107 13:09:15 [Warning] IP address '27.54.225.68' could not be resolved: Name or service not known
151109 5:50:58 [Warning] IP address '150.242.249.147' could not be resolved: Name or service not known
151110 11:54:34 [Warning] IP address '222.186.15.109' could not be resolved: Name or service not known
151112 14:35:58 [Warning] IP address '112.112.60.195' has been resolved to the host name '195.60.112.112.broad.km.yn.dynamic.163data.com.cn', which resembles IPv4-address itself.
151115 7:18:09 [Warning] IP address '116.252.178.53' could not be resolved: Temporary failure in name resolution
151115 7:18:15 [Warning] IP address '116.252.178.53' could not be resolved: Temporary failure in name resolution
151115 7:18:19 [Warning] IP address '116.252.178.53' could not be resolved: Temporary failure in name resolution
151115 7:18:21 [Warning] IP address '116.252.178.53' could not be resolved: Temporary failure in name resolution
151115 7:18:23 [Warning] IP address '116.252.178.53' could not be resolved: Temporary failure in name resolution
151115 13:17:50 [Warning] IP address '218.249.125.170' could not be resolved: Temporary failure in name resolution
151115 13:17:51 [Warning] IP address '218.249.125.170' could not be resolved: Temporary failure in name resolution
151115 15:34:59 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
151115 15:34:59 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
151115 15:34:59 [Note] /usr/libexec/mysqld (mysqld 5.5.44) starting as process 1153 ...
151115 15:34:59 [Note] Plugin 'FEDERATED' is disabled.
151115 15:34:59 InnoDB: The InnoDB memory heap is disabled
151115 15:34:59 InnoDB: Mutexes and rw_locks use GCC atomic builtins
151115 15:34:59 InnoDB: Compressed tables use zlib 1.2.3
151115 15:34:59 InnoDB: Using Linux native AIO
151115 15:34:59 InnoDB: Initializing buffer pool, size = 128.0M
151115 15:34:59 InnoDB: Completed initialization of buffer pool
151115 15:34:59 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
151115 15:34:59 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Warning: database page corruption or a failed
InnoDB: file read of space 829 page 4.
InnoDB: Trying to recover it from the doublewrite buffer.
InnoDB: Recovered the page from the doublewrite buffer.
151115 15:34:59 InnoDB: ERROR: We were only able to scan the log up to
InnoDB: 183572480, but a checkpoint was at 183572945.
InnoDB: It is possible that the database is now corrupt!
InnoDB: 2 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 2 row operations to undo
InnoDB: Trx id counter is 4E800
InnoDB: Cleaning up trx with id 4EA90
InnoDB: Cleaning up trx with id 4EA8A
151115 15:34:59 InnoDB: Waiting for the background threads to start
151115 15:35:00 InnoDB: 5.5.44 started; log sequence number 183572945
151115 15:35:00 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
151115 15:35:00 [Note] - '0.0.0.0' resolves to '0.0.0.0';
151115 15:35:00 [Note] Server socket created on IP: '0.0.0.0'.
151115 15:35:00 [Note] Event Scheduler: Loaded 0 events
151115 15:35:00 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.5.44' socket: '/var/lib/mysql/mysql.sock' port: 3306 MySQL Community Server (GPL) by Remi
InnoDB: error in sec index entry update in
InnoDB: index `userid` of table `my_dbase`.`uners_session`
InnoDB: tuple DATA TUPLE: 2 fields;
0: len 4; hex 80000000; asc ;;
1: len 26; hex 356236333436657631726f6d63636a663576716b657030643233; asc 5b6346ev1romccjf5vqkep0d23;;
InnoDB: record PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 696e66696d756d00; asc infimum ;;
TRANSACTION 4E801, ACTIVE 0 sec updating or deleting
mysql tables in use 1, locked 1
2 lock struct(s), heap size 320, 1 row lock(s), undo log entries 1
MySQL thread id 3, OS thread handle 0xa65adb70, query id 55 localhost my_dbase updating
DELETE
FROM `uners_session`
WHERE `time` < '1447618845'
InnoDB: Submit a detailed bug report to http://bugs.mysql.com
InnoDB: error in sec index entry update in
InnoDB: index `time` of table `my_dbase`.`uners_session`
InnoDB: tuple DATA TUPLE: 2 fields;
0: len 10; hex 31343437353434333431; asc 1447544341;;
1: len 26; hex 356236333436657631726f6d63636a663576716b657030643233; asc 5b6346ev1romccjf5vqkep0d23;;
InnoDB: record PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 696e66696d756d00; asc infimum ;;
TRANSACTION 4E801, ACTIVE 0 sec updating or deleting
mysql tables in use 1, locked 1
2 lock struct(s), heap size 320, 1 row lock(s), undo log entries 1
MySQL thread id 3, OS thread handle 0xa65adb70, query id 55 localhost my_dbase updating
DELETE
FROM `uners_session`
WHERE `time` < '1447618845'
InnoDB: Submit a detailed bug report to http://bugs.mysql.com
InnoDB: error in sec index entry update in
InnoDB: index `userid` of table `my_dbase`.`uners_session`
InnoDB: tuple DATA TUPLE: 2 fields;
0: len 4; hex 80000000; asc ;;
1: len 26; hex 626337726e766f71736d316b69736f6c3431666f673032626831; asc bc7rnvoqsm1kisol41fog02bh1;;
InnoDB: record PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 696e66696d756d00; asc infimum ;;
TRANSACTION 4E801, ACTIVE 0 sec updating or deleting
mysql tables in use 1, locked 1
2 lock struct(s), heap size 320, 2 row lock(s), undo log entries 2
MySQL thread id 3, OS thread handle 0xa65adb70, query id 55 localhost my_dbase updating
DELETE
FROM `uners_session`
WHERE `time` < '1447618845'
InnoDB: Submit a detailed bug report to http://bugs.mysql.com
InnoDB: error in sec index entry update in
InnoDB: index `time` of table `my_dbase`.`uners_session`
InnoDB: tuple DATA TUPLE: 2 fields;
0: len 10; hex 31343437353434303438; asc 1447544048;;
1: len 26; hex 626337726e766f71736d316b69736f6c3431666f673032626831; asc bc7rnvoqsm1kisol41fog02bh1;;
InnoDB: record PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 696e66696d756d00; asc infimum ;;
TRANSACTION 4E801, ACTIVE 0 sec updating or deleting
mysql tables in use 1, locked 1
2 lock struct(s), heap size 320, 2 row lock(s), undo log entries 2
MySQL thread id 3, OS thread handle 0xa65adb70, query id 55 localhost my_dbase updating
DELETE
FROM `uners_session`
WHERE `time` < '1447618845'
InnoDB: Submit a detailed bug report to http://bugs.mysql.com
InnoDB: error in sec index entry update in
InnoDB: index `userid` of table `my_dbase`.`uners_session`
InnoDB: tuple DATA TUPLE: 2 fields;
0: len 4; hex 80000000; asc ;;
1: len 26; hex 6c637138396f3562656175746b756264753839626f6974383735; asc lcq89o5beautkubdu89boit875;;
InnoDB: record PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 696e66696d756d00; asc infimum ;;
TRANSACTION 4E801, ACTIVE 0 sec updating or deleting
mysql tables in use 1, locked 1
2 lock struct(s), heap size 320, 3 row lock(s), undo log entries 3
MySQL thread id 3, OS thread handle 0xa65adb70, query id 55 localhost my_dbase updating
DELETE
FROM `uners_session`
WHERE `time` < '1447618845'
InnoDB: Submit a detailed bug report to http://bugs.mysql.com
InnoDB: error in sec index entry update in
InnoDB: index `time` of table `my_dbase`.`uners_session`
InnoDB: tuple DATA TUPLE: 2 fields;
0: len 10; hex 31343437353433383231; asc 1447543821;;
1: len 26; hex 6c637138396f3562656175746b756264753839626f6974383735; asc lcq89o5beautkubdu89boit875;;
InnoDB: record PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 696e66696d756d00; asc infimum ;;
TRANSACTION 4E801, ACTIVE 0 sec updating or deleting
mysql tables in use 1, locked 1
2 lock struct(s), heap size 320, 3 row lock(s), undo log entries 3
MySQL thread id 3, OS thread handle 0xa65adb70, query id 55 localhost my_dbase updating
DELETE
FROM `uners_session`
WHERE `time` < '1447618845'
InnoDB: Submit a detailed bug report to http://bugs.mysql.com
InnoDB: error in sec index entry update in
InnoDB: index `userid` of table `my_dbase`.`uners_session`
InnoDB: tuple DATA TUPLE: 2 fields;
0: len 4; hex 80000000; asc ;;
1: len 26; hex 6e6f3874396b7667747471676b70693564706d71717235766236; asc no8t9kvgttqgkpi5dpmqqr5vb6;;
InnoDB: record PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 696e66696d756d00; asc infimum ;;
TRANSACTION 4E801, ACTIVE 0 sec updating or deleting
mysql tables in use 1, locked 1
2 lock struct(s), heap size 320, 4 row lock(s), undo log entries 4
MySQL thread id 3, OS thread handle 0xa65adb70, query id 55 localhost my_dbase updating
DELETE
FROM `uners_session`
WHERE `time` < '1447618845'
InnoDB: Submit a detailed bug report to http://bugs.mysql.com
InnoDB: error in sec index entry update in
InnoDB: index `time` of table `my_dbase`.`uners_session`
InnoDB: tuple DATA TUPLE: 2 fields;
0: len 10; hex 31343437353433383534; asc 1447543854;;
1: len 26; hex 6e6f3874396b7667747471676b70693564706d71717235766236; asc no8t9kvgttqgkpi5dpmqqr5vb6;;
InnoDB: record PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 696e66696d756d00; asc infimum ;;
TRANSACTION 4E801, ACTIVE 0 sec updating or deleting
mysql tables in use 1, locked 1
2 lock struct(s), heap size 320, 4 row lock(s), undo log entries 4
MySQL thread id 3, OS thread handle 0xa65adb70, query id 55 localhost my_dbase updating
DELETE
FROM `uners_session`
WHERE `time` < '1447618845'
InnoDB: Submit a detailed bug report to http://bugs.mysql.com
InnoDB: error in sec index entry update in
InnoDB: index `userid` of table `my_dbase`.`uners_session`
InnoDB: tuple DATA TUPLE: 2 fields;
0: len 4; hex 80000000; asc ;;
1: len 26; hex 7168753630306d756163706e3231717333676a70697538327231; asc qhu600muacpn21qs3gjpiu82r1;;
InnoDB: record PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 696e66696d756d00; asc infimum ;;
TRANSACTION 4E801, ACTIVE 0 sec updating or deleting
mysql tables in use 1, locked 1
2 lock struct(s), heap size 320, 5 row lock(s), undo log entries 5
MySQL thread id 3, OS thread handle 0xa65adb70, query id 55 localhost my_dbase updating
DELETE
FROM `uners_session`
WHERE `time` < '1447618845'
InnoDB: Submit a detailed bug report to http://bugs.mysql.com
InnoDB: error in sec index entry update in
InnoDB: index `time` of table `my_dbase`.`uners_session`
InnoDB: tuple DATA TUPLE: 2 fields;
0: len 10; hex 31343437353434353032; asc 1447544502;;
1: len 26; hex 7168753630306d756163706e3231717333676a70697538327231; asc qhu600muacpn21qs3gjpiu82r1;;
InnoDB: record PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 696e66696d756d00; asc infimum ;;
TRANSACTION 4E801, ACTIVE 0 sec updating or deleting
mysql tables in use 1, locked 1
2 lock struct(s), heap size 320, 5 row lock(s), undo log entries 5
MySQL thread id 3, OS thread handle 0xa65adb70, query id 55 localhost my_dbase updating
DELETE
FROM `uners_session`
WHERE `time` < '1447618845'
InnoDB: Submit a detailed bug report to http://bugs.mysql.com
151115 15:35:47 [ERROR] /usr/libexec/mysqld: Incorrect key file for table './futpan_fut/jos_session.MYI'; try to repair it
151115 15:35:47 [ERROR] Got an error from thread_id=5, /builddir/build/BUILD/mysql-5.5.44/storage/myisam/mi_write.c:226
151115 15:35:47 [ERROR] MySQL thread id 5, OS thread handle 0xa65adb70, query id 114 localhost futpan_fut update
INSERT INTO `jos_session` ( `session_id`,`time`,`username`,`gid`,`guest`,`client_id` ) VALUES ( 'mf2eco6ncg3dvabg7c6b6qr1c0','1447619747','','0','1','0' )
151115 15:35:55 InnoDB: Assertion failure in thread 2743122800 in file trx0purge.c line 840
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
20:35:55 UTC - 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.
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.
key_buffer_size=16777216
read_buffer_size=1048576
max_used_connections=1
max_threads=70
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 231941 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
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 = 0 thread_stack 0x30000
/usr/libexec/mysqld(my_print_stacktrace+0x34)[0x83effe4]
/usr/libexec/mysqld(handle_fatal_signal+0x48c)[0x82bdd0c]
[0xb7766500]
[0xb7766420]
/lib/libc.so.6(gsignal+0x51)[0xb721d871]
/lib/libc.so.6(abort+0x17a)[0xb721f14a]
/usr/libexec/mysqld[0x84b22a7]
/usr/libexec/mysqld[0x84b27c9]
/usr/libexec/mysqld[0x857da3a]
/usr/libexec/mysqld[0x85734fe]
/usr/libexec/mysqld[0x84b0f59]
/usr/libexec/mysqld[0x84a2f56]
/usr/libexec/mysqld[0x84a6987]
/lib/libpthread.so.0(+0x6b39)[0xb7749b39]
/lib/libc.so.6(clone+0x5e)[0xb72d5c2e]
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.
151115 15:35:55 mysqld_safe Number of processes running now: 0
151115 15:35:55 mysqld_safe mysqld restarted
151115 15:35:55 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
151115 15:35:55 [Note] /usr/libexec/mysqld (mysqld 5.5.44) starting as process 1395 ...
151115 15:35:55 [Note] Plugin 'FEDERATED' is disabled.
151115 15:35:55 InnoDB: The InnoDB memory heap is disabled
151115 15:35:55 InnoDB: Mutexes and rw_locks use GCC atomic builtins
151115 15:35:55 InnoDB: Compressed tables use zlib 1.2.3
151115 15:35:55 InnoDB: Using Linux native AIO
151115 15:35:55 InnoDB: Initializing buffer pool, size = 128.0M
151115 15:35:55 InnoDB: Completed initialization of buffer pool
151115 15:35:55 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 183575633
151115 15:35:55 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 183581774
InnoDB: 2 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 2 row operations to undo
InnoDB: Trx id counter is 4EA00
151115 15:35:55 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Cleaning up trx with id 4EA90
InnoDB: Cleaning up trx with id 4EA8A
151115 15:35:55 InnoDB: Waiting for the background threads to start
151115 15:35:56 InnoDB: 5.5.44 started; log sequence number 183581774
151115 15:35:56 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
151115 15:35:56 [Note] - '0.0.0.0' resolves to '0.0.0.0';
151115 15:35:56 [Note] Server socket created on IP: '0.0.0.0'.
151115 15:35:56 InnoDB: Assertion failure in thread 2743122800 in file trx0purge.c line 840
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
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: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
20:35:56 UTC - 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.
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.
что легче восстановит старый сервер или базу перенести на новую(правда не знаю как) ?
Re: Помогите восстановить сайты
Больше 100 человек посмотрел тему и ни кто не может помочь?
Re: Помогите восстановить сайты
Вы уважаемый точно не по адресу обратились.geokart wrote:Больше 100 человек посмотрел тему и ни кто не может помочь?
Тут тема vestacp содержит сервисы в вспомогательные который подстроены для управления , администрирования.
mysql и все остальные сервисы пакеты , устанавливаются с репозиториев.
Зайдите на сайт и спросите там. Вам не кто не мешал создать бекап но по вашим объективностью он не был создан.
Это под-держка панели.
Да же трудно выполнить запрос: http://qps.ru/1EmhU (Больше 1000000 просмотра страниц, и есть ответ на многие вопросы.) что мешает. Незнание или не умение
Re: Помогите восстановить сайты
Восстановить базу из дампа можно. А /var/lib/mysql - это не дампы. Это непосредственно рабочая база.
Нужно читать:
http://habrahabr.ru/post/122424/
http://www.opennet.ru/openforum/vsluhforumID8/7364.html
http://www.msav.ru/blog/276-restore-a-m ... ib_logfile
В случае повреждения файлов базы все весьма непросто иногда бывает и далеко не всегда можно восстановить все в полном объеме или восстановить вообще. Бэкапьте текущее и пробуйте.
Нужно читать:
http://habrahabr.ru/post/122424/
http://www.opennet.ru/openforum/vsluhforumID8/7364.html
http://www.msav.ru/blog/276-restore-a-m ... ib_logfile
В случае повреждения файлов базы все весьма непросто иногда бывает и далеко не всегда можно восстановить все в полном объеме или восстановить вообще. Бэкапьте текущее и пробуйте.