1. 程式人生 > >mysql-mariadb啟動報錯恢復資料([ERROR] mysqld got signal 6)

mysql-mariadb啟動報錯恢復資料([ERROR] mysqld got signal 6)

160226 11:00:21  InnoDB: Page checksum 913642282 (32bit_calc: 472052024), prior-to-4.0.14-form checksum 2048873750 InnoDB: stored checksum 913642282, prior-to-4.0.14-form stored checksum 1622372148 InnoDB: Page lsn 0 142354744, low 4 bytes of lsn at page end 142348560 InnoDB: Page number (if stored to page already) 589, InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0 InnoDB: Page may be an update undo log page InnoDB: Database page corruption on disk or a failed InnoDB: file read of page 589. InnoDB: You may have to recover from a backup. InnoDB: It is also possible that your operating InnoDB: system has corrupted its own file cache InnoDB: and rebooting your computer removes the InnoDB: error. InnoDB: If the corrupt page is an index page InnoDB: you can also try to fix the corruption InnoDB: by dumping, dropping, and reimporting InnoDB: the corrupt table. You can use CHECK InnoDB: TABLE to scan your table for corruption. InnoDB: about forcing recovery. InnoDB: Ending processing because of a corrupt database page. 160226 11:00:21  InnoDB: Assertion failure in thread 139871429470272 in file buf0buf.c line 4032 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: about forcing recovery. 160226 11:00:21 [ERROR] mysqld got signal 6 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. Server version: 5.5.44-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=0 max_threads=153 thread_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466713 K  bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x0 Attempting backtrace. You can use the following information to find out InnoDB: End of page dump 160226 11:00:30  InnoDB: Page checksum 913642282 (32bit_calc: 472052024), prior-to-4.0.14-form checksum 2048873750 InnoDB: stored checksum 913642282, prior-to-4.0.14-form stored checksum 1622372148 InnoDB: Page lsn 0 142354744, low 4 bytes of lsn at page end 142348560 InnoDB: Page number (if stored to page already) 589, InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0 InnoDB: Page may be an update undo log page InnoDB: Database page corruption on disk or a failed InnoDB: file read of page 589. InnoDB: You may have to recover from a backup. InnoDB: It is also possible that your operating InnoDB: system has corrupted its own file cache InnoDB: and rebooting your computer removes the InnoDB: error. InnoDB: End of page dump 160226 11:00:30  InnoDB: Page checksum 913642282 (32bit_calc: 472052024), prior-to-4.0.14-form checksum 2048873750 InnoDB: stored checksum 913642282, prior-to-4.0.14-form stored checksum 1622372148 InnoDB: Page lsn 0 142354744, low 4 bytes of lsn at page end 142348560 InnoDB: Page number (if stored to page already) 589, InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0 InnoDB: Page may be an update undo log page InnoDB: Database page corruption on disk or a failed InnoDB: file read of page 589. InnoDB: You may have to recover from a backup. InnoDB: It is also possible that your operating InnoDB: system has corrupted its own file cache InnoDB: and rebooting your computer removes the InnoDB: error. InnoDB: If the corrupt page is an index page InnoDB: you can also try to fix the corruption InnoDB: by dumping, dropping, and reimporting InnoDB: the corrupt table. You can use CHECK InnoDB: TABLE to scan your table for corruption. InnoDB: about forcing recovery. InnoDB: Ending processing because of a corrupt database page. 160226 11:00:30  InnoDB: Assertion failure in thread 140329989404736 in file buf0buf.c line 4032 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: about forcing recovery. 160226 11:00:30 [ERROR] mysqld got signal 6 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, 160226 11:00:28  InnoDB: Page dump in ascii and hex (16384 bytes): max_threads=153 thread_count=0  It is possible that mysqld could use up to  key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466713 K  bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x0  Attempting backtrace. You can use the following information to find out 160226 11:00:19  InnoDB: Page dump in ascii and hex (16384 bytes): InnoDB: End of page dump 160226 11:00:21  InnoDB: Page checksum 913642282 (32bit_calc: 472052024), prior-to-4.0.14-form checksum 2048873750 InnoDB: stored checksum 913642282, prior-to-4.0.14-form stored checksum 1622372148 InnoDB: Page lsn 0 142354744, low 4 bytes of lsn at page end 142348560 InnoDB: Page number (if stored to page already) 589, InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0 InnoDB: Page may be an update undo log page InnoDB: Database page corruption on disk or a failed InnoDB: file read of page 589. InnoDB: You may have to recover from a backup. InnoDB: It is also possible that your operating InnoDB: system has corrupted its own file cache InnoDB: and rebooting your computer removes the InnoDB: error. InnoDB: If the corrupt page is an index page InnoDB: you can also try to fix the corruption InnoDB: by dumping, dropping, and reimporting InnoDB: the corrupt table. You can use CHECK InnoDB: TABLE to scan your table for corruption. InnoDB: about forcing recovery. InnoDB: Ending processing because of a corrupt database page. 160226 11:00:21  InnoDB: Assertion failure in thread 139871429470272 in file buf0buf.c line 4032 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: about forcing recovery. 160226 11:00:21 [ERROR] mysqld got signal 6 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. Server version: 5.5.44-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=0 max_threads=153 thread_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466713 K  bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x0 Attempting backtrace. You can use the following information to find out InnoDB: End of page dump 160226 11:00:30  InnoDB: Page checksum 913642282 (32bit_calc: 472052024), prior-to-4.0.14-form checksum 2048873750 InnoDB: stored checksum 913642282, prior-to-4.0.14-form stored checksum 1622372148 InnoDB: Page lsn 0 142354744, low 4 bytes of lsn at page end 142348560 InnoDB: Page number (if stored to page already) 589, InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0 InnoDB: Page may be an update undo log page InnoDB: Database page corruption on disk or a failed InnoDB: file read of page 589. InnoDB: You may have to recover from a backup. InnoDB: It is also possible that your operating InnoDB: system has corrupted its own file cache InnoDB: and rebooting your computer removes the InnoDB: error. InnoDB: If the corrupt page is an index page InnoDB: you can also try to fix the corruption InnoDB: by dumping, dropping, and reimporting 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. Server version: 5.5.44-MariaDB key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=0 max_threads=153 thread_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466713 K  bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 0x0 thread_stack 0x48000 /usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7fa11fb574ed] /usr/libexec/mysqld(handle_fatal_signal+0x515)[0x7fa11f76d385] /lib64/libpthread.so.0(+0xf100)[0x7fa11ee9d100] /lib64/libc.so.6(gsignal+0x37)[0x7fa11d6515f7] /lib64/libc.so.6(abort+0x148)[0x7fa11d652ce8] /usr/libexec/mysqld(+0x6971a2)[0x7fa11f9651a2] /usr/libexec/mysqld(+0x6a8b17)[0x7fa11f976b17] /usr/libexec/mysqld(+0x6919ee)[0x7fa11f95f9ee] /usr/libexec/mysqld(+0x66313a)[0x7fa11f93113a] /usr/libexec/mysqld(+0x655f93)[0x7fa11f923f93] /usr/libexec/mysqld(+0x656dfc)[0x7fa11f924dfc] /usr/libexec/mysqld(+0x65954e)[0x7fa11f92754e] /usr/libexec/mysqld(+0x64290e)[0x7fa11f91090e] /usr/libexec/mysqld(+0x5fbb9c)[0x7fa11f8c9b9c] /usr/libexec/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x48)[0x7fa11f76f408] /usr/libexec/mysqld(+0x37bff5)[0x7fa11f649ff5] /usr/libexec/mysqld(_Z11plugin_initPiPPci+0x551)[0x7fa11f64fa61] /usr/libexec/mysqld(+0x2ee4ba)[0x7fa11f5bc4ba] /usr/libexec/mysqld(_Z11mysqld_mainiPPc+0x546)[0x7fa11f5bf5d6] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7fa11d63db15] /usr/libexec/mysqld(+0x2e869d)[0x7fa11f5b669d] information that should help you find out what is causing the crash. 160226 11:00:30 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended

相關推薦

mysql-mariadb啟動恢復資料([ERROR] mysqld got signal 6)

160226 11:00:21  InnoDB: Page checksum 913642282 (32bit_calc: 472052024), prior-to-4.0.14-form checksum 2048873750 InnoDB: stored checksum 913642282, prio

hive 資料來源 使用mysql; hive 啟動; 載入資料 建表等基本命令

-bash: se: command not found [[email protected] local]# service mysqld status mysqld is stopped [[email protected] local]# serv

[ERROR] mysqld got signal 6 錯誤

mariadb 資料庫的問題情景:是在系統盤不夠用的時候,將mariadb 的datadir=/var/lib/mysql 改為了 /alidata/mysql 將/var/lib/mysql 裡邊的東西複製到了 /alidata/mysql 下邊。但是複製的時候沒有關閉資料庫,將/var/lib/mysql

[ERROR] mysqld got signal 6 錯誤

pre 之前 新的 article ida innodb ... 配置 有關 mariadb 數據庫的問題情景:是在系統盤不夠用的時候,將mariadb 的datadir=/var/lib/mysql 改為了 /alidata/mysql 將/var/lib/mysql

Myeclipse啟動:An error has occurred.See the log file

entry classpath ret 出現 restore div nap cati security 出現這個問題是因為斷電前myeclipse還在運行,日誌報錯如下: !ENTRY org.eclipse.osgi 4 0 2017-07-24 08:29:48.4

memcache啟動:memcached: error while loading shared libraries: libevent-XXXXX5: cannot 。。。。

share mem dev 鏈接 debug 修改文件 memcache null 鏈接地址 創建連接 ln -s /usr/lib/libevent-2.1.so.6 /usr/lib/libevent-2.1.so.6 如果還不行就下面解決 執行下面語句查看鏈接

Eclipse啟動:An internal error occurred during: "Updating indexes".org/eclipse/core/runtime/internal/adaptor/BasicLocation解決方法

update download 4.0 oca and load 異常 for ror Eclipse一直用的好好的,突然這兩天每次啟動都會出現如下的錯誤:An internal error occurred during: "Updating indexes".org/e

nginx啟動:nginx: [error] open() "/var/run/nginx/nginx.pid" failed (2: No such file or directory) 的解決辦法

問題:   重啟虛擬機器後,再次重啟nginx會報錯: nginx: [error] open() "/var/run/nginx/nginx.pid" failed (2: No such file or directory)  問題原因:   提示資訊說明在 /var/

mysql服務啟動1607

安裝mysql成功後,會有my.ini配置檔案,如下 當我把datadir路徑修改為其他時(配置檔案中時預設有的),啟動服務就會出現如下錯誤,使用它預設配置的就可以正常啟動服務 我也不知道為什麼不能修改datadir的路徑

關於Mariadb啟動Job for mariadb.service failed because the control process exited...

MariaDB重啟後,執行 systemctl start mariadb 啟動報錯 Job for mariadb.service failed because the control process exited with error code. See "systemctl sta

mariadb啟動的一個案例

今天安裝了mariadb,在啟動時報錯如下: [[email protected] bin]# mysqld_safe 160608 09:18:25 mysqld_safe Logging

[Mysql啟動]/etc/init.d/mysqld: line 256: my_print_defaults: command not found

啟動Mysql時報錯: [[email protected]]# service mysqld status /etc/init.d/mysqld: line 256: my_print_defaults: command not found MySQL is n

springboot啟動:whitelabel error page

錯誤描述: Whitelabel Error PageThis application has no explicit mapping for /error, so you are seeing

linux下openoffice doc文件轉換成pdf 或亂碼。Fatal exception: Signal 6

doc報錯不能轉換是字型缺少原因。doc裡面用到了什麼字型,linux裡面沒有,但是window系統有。 1. 將Windows下的字型C:\Windows\Fonts\simsun.ttf字型拷貝到 /usr/share/fonts/zh_CN/TrueType/ 下 2. 重建Linux字型

MySQL配置文件指定了 log-error配置項,啟動的問題

mysql mysql bug log-error 啟動報錯 找不到文件 mysqld 的配置文件 my.cnf 在 [mysqld_safe] 配置區塊內指定了 log-error 項後,導致mysqld 服務啟動因找不到日誌文件,而報錯退出的問題。 service mysql res

mysql啟動... ERROR! The server quit without updating PID file (/usr/local/mysql/data/test.pid

公司的伺服器突然斷電了,恢復後重啟mysql報錯如下 Starting MySQL... ERROR! The server quit without updating PID file (/usr/local/mysql/data/test.pid)      &

MySQL啟動問題排查:InnoDB: Unable to lock ./ibdata1 error

在OS X環境下MySQL啟動時報錯: 016-03-03T00:02:30.483037Z 0 [ERROR] InnoDB: Unable to lock ./ibdata1 error: 35 2016-03-03T00:02:30.483100Z 0 [Note] InnoDB:

mysql啟動:Starting MySQL... ERROR! The server quit without updating PID file

mysql啟動時報錯:Starting MySQL... ERROR! The server quit without updating PID file (/opt/mysql/data/mysql.pid) 的解決方法:1、可能是/opt/mysql/data/資料目錄m

MySql啟動,無法更新PID文件

mysql error pidMySql啟動報錯Starting MySQL.. ERROR! The server quit without updating PID file (/var/lib/mysql..)1,查看錯誤日誌 2017-08-10 19:38:14 31865 [Note] In

關於mysql登錄出現信息:ERROR 1045 (28000)的解決方法

myql 登錄 error 1045 登錄mysql數據庫出現報錯信息ERROR 1045(28000)如下:[[email protected] ~]# mysql -uroot -p fanshine Enter password: ERROR 1045 (28000): Acce