国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

MySQL維護之--表損壞如何挽回

IT那活兒 / 2316人閱讀
MySQL維護之--表損壞如何挽回
點擊上方“IT那活兒”公眾號,關注后了解更多內容,不管IT什么活兒,干就完了!!!

  

在我們MySQL數據庫維護工作中極力要避免的突發狀況里面,表數據損壞無疑是一種非常糟糕的情況

然而在實際情況中,有時候這些突發狀況可能因為各種各樣的因素還是殘酷地需要我們直面處理。當這些突發狀況發生時,也不要太過沮喪,如果我們能夠冷靜專業的面對,也許轉機就在前方。

下面來針對兩種有代表性的情況做一個模擬。


狀況一:系統表損壞

如果發生了數據庫系統表損壞,首先登錄備庫查看系統表是否正常(如果有備庫的話),大多數情況下,備庫是正常的,這個時候我們可以進行VIP切換,然后再使用備庫備份重建原主庫。
當然,情況也可能更糟糕,也就是主備庫系統表同時損壞,也不要慌,我們可以嘗試使用/usr/local/mysql/share下.sql腳本文件進行重建步驟如下
1. 模擬系統表損壞,進入…data/mysql/下打開文件編輯,清空文件
#/dev/null > innodb_index_stats.frm
#ll innodb_index_stats.frm
-rw-r----- 1 mysql mysql 0 Mar 24 08:41 innodb_index_stats.frm

2. 重啟動數據庫,無法正常啟動

# sh shutdown.sh
Enter password:
# sh startup.sh
#sh login.sh
Enter password:
ERROR 2002 (HY000): Cant connect to local MySQL server through socket /data/mysql/db_order/mysql.sock (2)

3. 出現錯誤日志

2021-03-24T08:43:05.378517-05:00 0 [ERROR] InnoDB: The size of tablespace file ./mysql/innodb_index_stats.ibd is only 49674, should be at least 65536!
2021-03-24 08:43:05 0x7fc7430a4740 InnoDB: Assertion failure in thread 140493799966528 in file fil0fil.cc line 793
InnoDB: We intentionally generate a memory trap.

4. 修改參數文件,添加innodb_force_recovery = 6,強制啟動數據庫,存在丟失少量數據風險

# sh startup.sh
#sh login.sh #此時,正常啟動
Enter password:
Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 3
Server version: 5.7.25-log Source distribution
Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type help; or h for help. Type c to clear the current
input statement.

5. 修改參數文件,還原innodb_force_recovery = 0,再重新啟動

#sh shutdown.sh
#sh startup.sh
mysql> use mysql;

6. 刪除損壞表

mysql> drop table innodb_index_stats;
ERROR 1051 (42S02): Unknown table mysql.innodb_index_stats
mysql> drop table if exists innodb_index_stats;
Query OK, 0 rows affected, 1 warning (1.07 sec)
# rm innodb_index_stats.frm
# rm innodb_index_stats.ibd

7. 進入系統目錄,查看創建系統表腳本mysql_system_tables.sql

# cd /usr/local/mysql/share/
# ls *.sql
fill_help_tables.sql install_rewriter.sql mysql_sys_schema.sql mysql_system_tables.sql uninstall_rewriter.sql
innodb_memcached_config.sql mysql_security_commands.sql mysql_system_tables_data.sql mysql_test_data_timezone.sql
# cat *.sql|grep innodb_index_stats
SET @create_innodb_index_stats="CREATE TABLE IF NOT EXISTS innodb_index_stats (
SET @str=IF(@have_innodb <> 0, @create_innodb_index_stats, "SET @dummy = 0");


8. 登錄數據庫,進行表結構創建
mysql> use mysql;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with –A


9. 再次進行重啟動數據庫,加載數據
mysql> select count(*) from innodb_index_stats;
+----------+
| count(*) |
+----------+
| 13 |
+----------+
1 row in set (0.00 sec)
至此,系統表恢復成功。

狀況二:數據表損壞(InnoDB)

如果數據表損壞,同樣首先要登錄備庫查看是否正常,如果備庫正常,進行VIP切換,然后自然可以通過備庫的備份來重建原主庫。
然而,如果主備庫數據表同時損壞,那么想完全找回全部的數據已經很難了,只能盡量降低損失,最大限度的恢復數據。
可以通過設定參數innodb_force_recovery級別,選擇盡可能低的丟失數據風險,啟動數據庫后,進行數據表的恢復。
模擬過程如下:
1. InnoDB表文件損壞恢復方法
2. 模擬表數據文件.ibd損壞,打開tt.idb文件,刪除任一個字符后保存,關閉數據庫后,啟動
mysql> select count(*) from tt;
+----------+
| count(*) |
+----------+
| 407 | #損壞前數據筆數407
+----------+
1 row in set (0.00 sec)
#cd ./data/htest
#vi tt.ibd #打開刪除任一字符
#sh shutdown.sh
#sh startup.sh

3. 無法登錄數據庫,log出現錯誤

#sh login.sh

Enter password:
ERROR 2002 (HY000): Cant connect to local MySQL server
through socket /data/mysql/db_order/mysql.sock (2)

#
cat mysql.err|more

2021-03-25T08:34:42.683624-05:00 0 [ERROR] InnoDB: Database
page corruption on disk or a failed file read of page [page
id: space=124, page number=5]. You may have to recover from
a backup.


4. 嘗試備份損壞表,無法連接
# mysqldump -uroot -psystem -S 
/data/mysql/db_order/mysql.sock --single-transaction --
default-character-set=utf8 --set-gtid-purged=off --add-drop-
table --triggers --events --routines htest tt>tt.sql

mysqldump: [Warning] Using a password on the command line
interface can be insecure.

mysqldump: Got error: 2002: Cant connect to local MySQL
server through socket
/data/mysql/db_order/mysql.sock (2)
when trying to connect
5. 參數文件添加innodb_force_recovery = 4,強制啟動數據庫
#sh login.sh
Enter password:
Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 3
Server version: 5.7.25-log Source distribution
Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type help; or h for help. Type c to clear the current input statement.
mysql> use htest;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> desc tt;
+--------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------------+-------------+------+-----+---------+-------+
|
 TABLE_SCHEMA | varchar(64) | YES | | NULL | |
| TABLE_NAME | varchar(64) | YES |     | NULL |       |
|
 CREATE_TIME | datetime | YES | | NULL | |
+--------------+-------------+------+-----+---------+-------+
3 rows in set (0.00 sec)
6. 進行損壞表的備份,只能備份出正常數據
#mysqldump -uroot -psystem -S /data/mysql/db_order/mysql.sock --single-transaction --default-character-set=utf8 --set-gtid-purged=off --add-drop-table --triggers --events --routines htest tt>tt.sql
mysqldump: [Warning] Using a password on the command line interface can be insecure.
mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table `tt` at row: 339
[mysql@mysqltest1 bin]$ ll
total 32
-rw-r--r-- 1 mysql mysql 19304 Mar 25 08:51 tt.sql

7. 刪除損壞表

mysql> drop table tt;
Query OK, 0 rows affected (1.39 sec)
8. 將參數innodb_force_recovery = 4清除,重啟動數據庫后,進行數據導入
mysql> show tables;
Empty set (0.00 sec)
mysql> source tt.sql;
Query OK, 0 rows affected (0.00 sec)
...
Query OK, 339 rows affected (0.08 sec)
Records: 339 Duplicates: 0 Warnings: 0
mysql> select count(*) from tt;
+----------+
| count(*) |
+----------+
| 339 | #相較407筆減少68筆數據,存在少量數據丟失風險
+----------+
1 row in set (0.00 sec)

需要說明的是:

innodb_force_recovery = 4代表相對比較安全,只有一些在損壞的多帶帶頁面上的數據會丟失。

如果是innodb_force_recovery =6 ,數據庫頁將被留在一個陳舊的狀態,這個狀態反過來可以引發對B 樹和其它數據庫結構的更多破壞。


本文作者:沈亞威(上海新炬王翦團隊)

本文來源:“IT那活兒”公眾號

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/129369.html

相關文章

  • MySQL 復制 - 性能與擴展性的基石 3:常見問題及解決方案

    摘要:問題原因非正常關機導致沒有把數據及時的寫入硬盤。丟失的臨時表臨時表和基于語句的復制方式不相容。如果備庫崩潰或者正常關閉,任何復制線程擁有的臨時表都會丟失。臨時表的特性只對創建臨時表的連接可見。 主備復制過程中有很大可能會出現各種問題,接下來我們就討論一些比較普遍的問題,以及當遇到這些問題時,如何解決或者預防問題發生。 1 數據損壞或丟失 問題描述:服務器崩潰、斷電、磁盤損壞、內存或網絡...

    canopus4u 評論0 收藏0
  • MySQL 復制 - 性能與擴展性的基石 3:常見問題及解決方案

    摘要:問題原因非正常關機導致沒有把數據及時的寫入硬盤。丟失的臨時表臨時表和基于語句的復制方式不相容。如果備庫崩潰或者正常關閉,任何復制線程擁有的臨時表都會丟失。臨時表的特性只對創建臨時表的連接可見。 主備復制過程中有很大可能會出現各種問題,接下來我們就討論一些比較普遍的問題,以及當遇到這些問題時,如何解決或者預防問題發生。 1 數據損壞或丟失 問題描述:服務器崩潰、斷電、磁盤損壞、內存或網絡...

    haobowd 評論0 收藏0

發表評論

0條評論

IT那活兒

|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<