場景：
遠程拷貝的/var/lib/mysql/*的所有文件打包后拖到本地后無法啟動。（導表因為數據庫太大導表相當漫長，偷懶了....啟動時一同報錯....），

創新互聯公司服務項目包括長治網站建設、長治網站制作、長治網頁制作以及長治網絡營銷策劃等。多年來，我們專注于互聯網行業，利用自身積累的技術優勢、行業經驗、深度合作伙伴關系等，向廣大中小型企業、政府機構等提供互聯網行業的解決方案，長治網站推廣取得了明顯的社會效益與經濟效益。目前，我們服務的客戶以成都為中心已經輻射到長治省份的部分城市，未來相信會繼續擴大服務區域并繼續獲得客戶的支持與信任！

版本：
sys:
Linux console 3.10.0-862.el7.x86_64 #1 SMP Fri Apr 20 16:44:24 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
DB:
Server version: 5.5.60-MariaDB MariaDB Server

報錯信息：
數據庫日志：

#tailf /var/log/mariadb/mariadb.log
Server version: 5.5.60-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 = 466718 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 = 0x0 thread_stack 0x48000
190119 12:54:23 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
190119 12:55:54 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
190119 12:55:54 [Note] /usr/libexec/mysqld (mysqld 5.5.60-MariaDB) starting as process 10885 ...
190119 12:55:54 InnoDB: The InnoDB memory heap is disabled
190119 12:55:54 InnoDB: Mutexes and rw_locks use GCC atomic builtins
190119 12:55:54 InnoDB: Compressed tables use zlib 1.2.7
190119 12:55:54 InnoDB: Using Linux native AIO
190119 12:55:54 InnoDB: Initializing buffer pool, size = 128.0M
190119 12:55:54 InnoDB: Completed initialization of buffer pool
190119 12:55:54 InnoDB: highest supported file format is Barracuda.
190119 12:55:54  InnoDB: Starting crash recovery from checkpoint LSN=25825591529
InnoDB: Restoring possible half-written data pages from the doublewrite buffer...
190119 12:55:54  InnoDB: Starting final batch to recover 15 pages from redo log
190119 12:55:54 [ERROR] mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see http://kb.askmonty.org/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed, 
something is definitely wrong and this may fail.

Server version: 5.5.60-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 = 466718 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

服務狀態：

#systemctl status mariadb
● mariadb.service - MariaDB database server
   Loaded: loaded (/usr/lib/systemd/system/mariadb.service; disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Sat 2019-01-19 12:49:08 CST; 3s ago
  Process: 9550 ExecStartPost=/usr/libexec/mariadb-wait-ready $MAINPID (code=exited, status=1/FAILURE)
  Process: 9549 ExecStart=/usr/bin/mysqld_safe --basedir=/usr (code=exited, status=0/SUCCESS)
  Process: 9517 ExecStartPre=/usr/libexec/mariadb-prepare-db-dir %n (code=exited, status=0/SUCCESS)
 Main PID: 9549 (code=exited, status=0/SUCCESS)

Jan 19 12:49:06 console systemd[1]: Starting MariaDB database server...
Jan 19 12:49:06 console mariadb-prepare-db-dir[9517]: Database MariaDB is probably initialized in /var/lib/mysql alre
Jan 19 12:49:06 console mariadb-prepare-db-dir[9517]: If this is not the case, make sure the /var/lib/mysql is empty 
Jan 19 12:49:06 console mysqld_safe[9549]: 190119 12:49:06 mysqld_safe Logging to '/var/log/mariadb/mariadb.log'.
Jan 19 12:49:06 console mysqld_safe[9549]: 190119 12:49:06 mysqld_safe Starting mysqld daemon with databases from /va
Jan 19 12:49:08 console systemd[1]: mariadb.service: control process exited, code=exited status=1
Jan 19 12:49:08 console systemd[1]: Failed to start MariaDB database server.
Jan 19 12:49:08 console systemd[1]: Unit mariadb.service entered failed state.
Jan 19 12:49:08 console systemd[1]: mariadb.service failed.

解決方式：

（1）修改配置文件：
添加參數：
innodb_force_recovery = 6 （此項由1---6個級別一次往上修改參數在失敗的情況下）
innodb_purge_threads = 0

（2）修改剛才解壓的文件屬主屬組為mysql用戶。

我的數據庫配置文件：

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock

lower_case_table_name=1
character_set_server=utf8
skip_name_resolve
bind-address = 0.0.0.0

innodb_force_recovery = 6  
innodb_purge_threads = 0

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# Settings user and group are ignored when systemd is used.
# If you need to run mysqld under a different user or group,
# customize your systemd unit file for mariadb according to the
# instructions in http://fedoraproject.org/wiki/Systemd

[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid

#
# include all files from the config directory
#
!includedir /etc/my.cnf.d

另外有需要云服務器可以了解下創新互聯cdcxhl.cn，海內外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業上云的綜合解決方案，具有“安全穩定、簡單易用、服務可用性高、性價比高”等特點與優勢，專為企業上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。

當前名稱：記一次數據崩潰無法啟動-創新互聯
網站鏈接：http://www.yijiale78.com/article34/cegope.html

成都網站建設公司_創新互聯，為您提供微信公眾號、軟件開發、網站改版、電子商務、品牌網站制作、網站營銷

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯