Vesta Control Panel - Forum

Community Forum

Skip to content

Advanced search
  • Quick links
    • Main site
    • Github repo
    • Google Search
  • FAQ
  • Login
  • Register
  • Board index Language specific forums Russian (Русский) Общие вопросы
  • Search

Помогите восстановить сайты

Общие вопросы о панели управления Vesta
Post Reply
  • Print view
Advanced search
8 posts • Page 1 of 1
geokart
Posts: 16
Joined: Mon Nov 16, 2015 9:57 pm

Помогите восстановить сайты
  • Quote

Post by geokart » Sat Nov 21, 2015 1:10 pm

После непонятной причини лег 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 или как перенести базу данных на новом сервере
Top

geokart
Posts: 16
Joined: Mon Nov 16, 2015 9:57 pm

Re: Помогите восстановить сайты
  • Quote

Post by geokart » Sun Nov 22, 2015 10:05 am

неужели ни кто не может помочь???
Top

linux81
Posts: 78
Joined: Wed Mar 18, 2015 10:11 pm
Contact:
Contact linux81
Website

Os: CentOS 6x
Web: apache + nginx
Re: Помогите восстановить сайты
  • Quote

Post by linux81 » Sun Nov 22, 2015 11:44 am

привет, что в логе ошибок mysql на старом сервере?
Top

geokart
Posts: 16
Joined: Mon Nov 16, 2015 9:57 pm

Re: Помогите восстановить сайты
  • Quote

Post by geokart » Sun Nov 22, 2015 1:53 pm

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
Top

geokart
Posts: 16
Joined: Mon Nov 16, 2015 9:57 pm

Re: Помогите восстановить сайты
  • Quote

Post by geokart » Sun Nov 22, 2015 2:07 pm

думаю в этом отрезке случилось что то и вообще что за ип адреса
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.

что легче восстановит старый сервер или базу перенести на новую(правда не знаю как) ?
Top

geokart
Posts: 16
Joined: Mon Nov 16, 2015 9:57 pm

Re: Помогите восстановить сайты
  • Quote

Post by geokart » Thu Nov 26, 2015 3:03 pm

Больше 100 человек посмотрел тему и ни кто не может помочь?
Top

Mr.Erbutw
Posts: 1040
Joined: Tue Apr 29, 2014 10:05 pm

Os: CentOS 6x
Web: apache + nginx
Re: Помогите восстановить сайты
  • Quote

Post by Mr.Erbutw » Thu Nov 26, 2015 4:41 pm

geokart wrote:Больше 100 человек посмотрел тему и ни кто не может помочь?
Вы уважаемый точно не по адресу обратились.
Тут тема vestacp содержит сервисы в вспомогательные который подстроены для управления , администрирования.
mysql и все остальные сервисы пакеты , устанавливаются с репозиториев.
Зайдите на сайт и спросите там. Вам не кто не мешал создать бекап но по вашим объективностью он не был создан.
Это под-держка панели.
Да же трудно выполнить запрос: http://qps.ru/1EmhU (Больше 1000000 просмотра страниц, и есть ответ на многие вопросы.) что мешает. Незнание или не умение
Top

skurudo
VestaCP Team
Posts: 8099
Joined: Fri Dec 26, 2014 2:23 pm
Contact:
Contact skurudo
Website Facebook Google+ Skype
Twitter

Re: Помогите восстановить сайты
  • Quote

Post by skurudo » Fri Nov 27, 2015 11:54 am

Восстановить базу из дампа можно. А /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

В случае повреждения файлов базы все весьма непросто иногда бывает и далеко не всегда можно восстановить все в полном объеме или восстановить вообще. Бэкапьте текущее и пробуйте.
Top


Post Reply
  • Print view

8 posts • Page 1 of 1

Return to “Общие вопросы”



  • Board index
  • All times are UTC
  • Delete all board cookies
  • The team
Powered by phpBB® Forum Software © phpBB Limited
*Original Author: Brad Veryard
*Updated to 3.2 by MannixMD
 

 

Login  •  Register

I forgot my password