本文節選自清華大學出版社出版的圖書《數據資產管理核心技術與應用》,作者為張永清等著。 從Spark 執行計劃中獲取數據血緣 因為數據處理任務會涉及到數據的轉換和處理,所以從數據任務中解析血緣也是獲取數據血緣的渠道之一,Spark 是大數據中數據處理最常用的一個技術組件,既可以做實時任務的處理,也可以 ...
目錄
- 三.MySQL
- 3.1 關係型和非關係型資料庫的區別
- 3.2 登錄資料庫的方式,如何遠程登錄
- 3.3 MySQL的服務結構,當客戶端發起請求後,處理過程
- 3.4 如何設置或者重置MySQL密碼
- 3.5 DDL,DML,DQL,DCL等SQL語句的寫法
- 3.6 什麼是索引,索引的作用
- 3.7 索引的種類
- 3.8 b樹和b+樹的區別
- 3.9 什麼情況下會導致索引失效
- 3.10 MySQL的explain
- 3.11 什麼是事務,事務的作用
- 3.12 事務的ACID分別怎麼體現
- 3.13 事務的隔離級別
- 3.14 什麼是臟讀,幻讀,不可重覆讀
- 3.15 事務的鎖有哪些,怎麼用
- 3.16 悲觀鎖和樂觀鎖的區別
- 3.17 事務發生redo和undo的區別和過程
- 3.18 在事務未提交的情況下,資料庫伺服器重啟,會發生什麼
- 3.19 什麼是MySQL的存儲引擎,常見的存儲引擎有哪些,innodb和myisam存儲引擎的區別
- 3.20 客戶的資料庫是myisam如何切換到innodb(大致步驟)
- 3.21 MySQL的日誌都有哪些
- 3.22 什麼是二進位日誌binlog,它的作用是什麼
- 3.23 二進位日誌中row模式和statement模式的優缺點
- 3.24 慢查詢日誌分析(mysqldumpslow)
- 3.25 MySQL的備份和恢復相關知識
- 3.26 MySQL服務損壞,且沒有備份的情況下,資料庫服務如何恢復
- 3.27 MySQL主從架構原理
- 3.28 MySQL主主架構原理
- 3.29 MySQL雙主架構一致性的問題
- 3.30 主從架構存在的問題,解決思路
- 3.31 主從複製,從庫誤操作寫入數據怎麼辦(主從不同步,會導致SQL線程停止)
- 3.32 主從複製,從庫IO線程故障排查思路
- 3.33 主從複製中的延時從庫,半同步複製,過濾複製使用場景
- 3.34 MySQL的MHA高可用架構的原理
- 3.35 如何部署MHA高可用架構
三.MySQL
3.1 關係型和非關係型資料庫的區別
關係型資料庫
- 使用表結構,格式一致;
- SQL語言通用,可用於複雜查詢;
- 讀寫性能比較差,尤其是海量數據的高效率讀寫;
- 固定的表結構,靈活度稍欠;
- 高併發讀寫需求,傳統關係型資料庫來說,硬碟I/O是一個很大的瓶頸。
非關係型資料庫
格式靈活:存儲數據的格式可以是key,value形式、文檔形式、圖片形式等等,文檔形式、圖片形式等等,使用靈活,應用場景廣泛,而關係型資料庫則只支持基礎類型。
2、速度快:nosql可以使用硬碟或者隨機存儲器作為載體,而關係型資料庫只能使用硬碟;
3、高擴展性;
4、成本低:nosql資料庫部署簡單,基本都是開源軟體。
缺點:
1、不提供sql支持,學習和使用成本較高;
2、無事務處理;
3、數據結構相對複雜,複雜查詢方面稍欠。
3.2 登錄資料庫的方式,如何遠程登錄
- 編輯 MySQL
config
文件 - 配置防火牆允許遠程連接
- 允許
root
遠程登錄 - 連接到遠程 MySQL 伺服器
mysql> GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost';
mysql> UPDATE mysql.user SET host='%' WHERE user='root';
3.3 MySQL的服務結構,當客戶端發起請求後,處理過程
3.4 如何設置或者重置MySQL密碼
use mysql;
UPDATE user SET authentication_string=PASSWORD("root") WHERE User="root";
flush privileges;
3.5 DDL,DML,DQL,DCL等SQL語句的寫法
DDL數據定義語句
#庫部分
create database db02 charset utf8;
# 創建資料庫的時候添加屬性
show create database db01;
# 查看建庫語句
drop database db02;
# 刪除資料庫db02
alter database db01 charset utf8;
#修改定義庫
#表部分
create table student(
sid int '學號',
sname varchar(20) not null comment '學生姓名',
sage tinyint unsigned not null comment '年齡',
sgender enum('m','f') not null default 'm' comment '學生性別',
cometime datetime not null comment '入學時間'
)charset utf8 engine innodb;
#建表語句實例
desc student;
# 查看表中列的定義信息
drop table student;
#刪表
alter table student rename stu;
# 修改表名
alter table stu add age int;
# 添加列和列數據類型的定義
alter table stu add test varchar(20),add qq int;
# 添加多個列
alter table stu add classid varchar(20) first;
# 指定位置進行添加列(表首)
alter table stu add phone2 int after sid;
# 指定位置進行添加列(指定列)
alter table stu drop qq;
# 刪除指定的列及定義
alter table stu modify sid varchar(20);
# 修改列及定義(列屬性)
alter table stu change phone telphone int();
# 修改列及定義(列名及屬性)
DCL數據控制語言(用戶許可權)
grant all on *.* to root@'192.168.175.%' identified by '123456';
# 授予root@'192.168.175.%'用戶所有許可權(非超級管理員)
revoke select on *.* from root@'192.168.175.%';
# 收回select許可權
show grants for root@'192.168.175.%';
# 查看許可權
DML數據操作語言
insert into stu valus('linux01',1,NOW(),'zhangsan',20,'m',NOW(),110,123456);
insert into stu(classid,birth.sname,sage,sgender,comtime,telnum,qq) values('linux01',1,NOW(),'zhangsan',20,'m',NOW(),110,123456),
('linux02',2,NOW(),'zhangsi',21,'f',NOW(),111,1234567);
# 插入多條數據
update student set sgender='f' where sid=1;
update mysql.user set password=PASSWORD('123456') where user='root' and host='localhost';
delete from student where sid=3;
truncate table student;
# DDL清空表中的內容
alter table student add status enum('1','0') default 1;
# 額外添加一個狀態列
update student set status='0' where sid=1;
# 使用update
select * from student where status=1;
# 應用查詢存在的數據
DQL數據查詢
瞭解select的高級用法(不多簡述)
3.6 什麼是索引,索引的作用
特殊的資料庫結構
加快資料庫表中數據的檢索速度,用於確保數據的唯一性。
3.7 索引的種類
- 主鍵索引
- 普通索引
- 唯一索引
- 全文索引
- 首碼索引
- 組合索引
3.8 b樹和b+樹的區別
B樹的每個節點都存儲關鍵字和數據,而B+樹只有葉子節點存儲數據,內部節點僅存儲關鍵字和指向子節點的指針。
B+樹因其優越的範圍查詢性能和索引空間利用率而被廣泛用作預設的索引結構。
3.9 什麼情況下會導致索引失效
- 沒有查詢條件,或者查詢條件沒有建立索引。
- 在查詢條件上沒有使用引導列。
- 查詢的數量是大表的大部分,應該是30%以上。
- 索引本身失效。
3.10 MySQL的explain
2024 年 8月 隨筆檔案 - guixiang - 博客園 (cnblogs.com)
3.11 什麼是事務,事務的作用
事務 是一組操作,把所有的操作 作為一個整體一起向系統提交 或 撤銷操作請求,即這些操作要麼同時成功,要麼同時失敗。
3.12 事務的ACID分別怎麼體現
Atomic(原子性)
- 所有語句作為一個單元全部成功執行或全部取消。
Consistent(一致性)
-
如果資料庫在事務開始時處於一致狀態,則在執行該事務期間將保留一致狀態。
-
在事務內看到的數據狀態都是一樣的。
Isolated(隔離性)
- 事務之間不相互影響。
Durable(持久性)
- 事務成功完成後,所做的所有更改都會準確地記錄在資料庫中。所做的更改不會丟失。
- 軟、硬體崩潰後,InnoDB數據表驅動會利用日誌文件重構修改。
3.13 事務的隔離級別
未提交讀(read uncommited)
A事務已執行,但未提交;B事務查詢到A事務的更新後數據;A事務回滾;
已提交讀(read commited)
A事務執行更新;B事務查詢;A事務又執行更新;B事務再次查詢時,前後兩次數據不一致;---不可重覆讀
可重覆讀(repeated read)
A事務無論執行多少次,只要不提交,B事務查詢值都不變;B事務僅查詢B事務開始時那一瞬間的數據快照;
mysql預設模式
3.14 什麼是臟讀,幻讀,不可重覆讀
臟讀
指一個線程中的事務讀取到了另外一個線程中未提交的數據。
不可重覆讀
指一個線程中的事務讀取到了另外一個線程中提交的update的數據。
幻讀
指一個線程中的事務讀取到了另外一個線程中提交的insert的數據。莫名情況下數據增加或減少(出現於可重覆讀)
3.15 事務的鎖有哪些,怎麼用
共用鎖(S):允許一個事務去讀一行,阻止其他事務獲得相同數據集的排他鎖。
排他鎖(X):允許獲得排他鎖的事務更新數據,阻止其他事務取得相同數據集的共用讀鎖和排他寫鎖。
通過查詢條件對某一行進行加鎖,commit後解鎖
//讀鎖(共用鎖)
SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE;
//寫鎖(排他鎖)
SELECT * FROM table_name WHERE ... FOR UPDATE;
當我們進行增刪改的時候Innodb是預設給對應行自動加上了寫鎖的,select查詢不會加鎖。
在行鎖中,寫鎖和讀鎖都是其他會話只能查看無法修改該行數據,自己可以修改,但是我們給某一行加了讀鎖後,其他會話可以給這一行加讀鎖,不能加寫鎖。當我們給某一行加了寫鎖後,其他會話不能給該行加鎖
3.16 悲觀鎖和樂觀鎖的區別
悲觀鎖:認為在修改資料庫數據的這段時間里存在著也想修改此數據的事務;
樂觀鎖:認為在短暫的時間里不會有事務來修改此資料庫的數據;
3.17 事務發生redo和undo的區別和過程
區別
Redo(重做) | Undo(撤銷) |
---|---|
用來記錄數據頁的物理修改,確保事務提交後數據的一致性,併在系統崩潰時能夠恢複數據到提交狀態。 | 用來記錄事務中數據修改前的狀態,以便在事務失敗或需要回滾時,能夠撤銷事務所做的修改,恢複數據到修改前的狀態。 |
Redo過程
- 數據修改前:在事務對資料庫進行修改之前,InnoDB存儲引擎會將修改操作記錄到redo log buffer(記憶體中的日誌緩衝)中。
- 數據修改:隨後,對資料庫中的數據進行實際的修改操作。
- 日誌寫入:當事務提交時,InnoDB會將redo log buffer中的日誌寫入到磁碟上的redo log file中,確保即使在系統崩潰的情況下,也能通過redo log恢複數據。
- 恢複數據:在系統崩潰或需要恢複數據時,可以通過redo log中的記錄,將資料庫恢復到事務提交時的狀態。
Undo過程
- 數據修改前:在事務對資料庫進行修改之前,InnoDB存儲引擎會生成undo log,記錄數據修改前的狀態。
- 數據修改:對資料庫中的數據進行修改。
- 事務提交或回滾:
- 如果事務成功提交,undo log可能會被清理(根據具體的undo日誌保留策略)。
- 如果事務失敗或執行ROLLBACK命令,InnoDB會根據undo log中的記錄,將資料庫中的數據恢復到修改前的狀態。
- 讀一致性:在併發事務中,undo log還用於實現讀一致性,即確保讀操作能夠讀取到事務開始前的數據狀態。
3.18 在事務未提交的情況下,資料庫伺服器重啟,會發生什麼
當系統提交了資料庫DML指令,但未執行commit,系統宕機了。此時,資料庫的數據不會改變,資料庫連接會被清除,資料庫事務也會被清除,也不會鎖定數據
3.19 什麼是MySQL的存儲引擎,常見的存儲引擎有哪些,innodb和myisam存儲引擎的區別
MySQL資料庫管理系統中負責存儲和檢索數據的組件,它們可以影響數據的存儲方式、事務支持、併發性能等方面1。MySQL中常見的存儲引擎有MyISAM、InnoDB、Memory、Archive等23。其中,InnoDB是MySQL的預設存儲引擎,它提供了強大的事務處理、行級鎖定和外鍵約束功能4。MyISAM則不支持事務、行級鎖和外鍵約束的功能
3.20 客戶的資料庫是myisam如何切換到innodb(大致步驟)
如使用wp_comments
表格。只需運行ALTER命令即可將其轉換為InnoDB存儲引擎。註意:我們始終建議在對MySQL資料庫運行任何操作之前對其進行備份。
ALTER TABLE wp_comments ENGINE=InnoDB;
3.21 MySQL的日誌都有哪些
- 重做日誌(redo log)
- 回滾日誌(undo log)
- 二進位日誌(binlog)
- 錯誤日誌(errorlog)
- 慢查詢日誌(slow query log)
- 一般查詢日誌(general log)
比較重要的還要屬二進位日誌 binlog(歸檔日誌)和事務日誌 redo log(重做日誌)和 undo log(回滾日誌)。
3.22 什麼是二進位日誌binlog,它的作用是什麼
是一種記錄資料庫中發生的更改的日誌文件。 它記錄了數據以及資料庫結構的更改
它可以
- 有資料庫搭建開始所有的二進位日誌,可以把數據恢復到任意時刻
- 數據的備份恢復
- 數據的複製
3.23 二進位日誌中row模式和statement模式的優缺點
- statement語句模式
- 優點:簡單明瞭,容易被看懂,就是sql語句,記錄時不需要太多的磁碟空間
- 缺點:記錄不夠嚴謹
- row行模式
- 優點:記錄更加嚴謹
- 缺點:有可能會需要更多的磁碟空間,不太容易被讀懂
3.24 慢查詢日誌分析(mysqldumpslow)
將mysql伺服器中影響資料庫性能的相關SQL語句記錄到日誌文件,通過對這些特殊的SQL語句分析,改進以達到提高資料庫性能的目的
$PATH/mysqldumpslow -s c -t 10 /application/mysql/data/slow.log
#輸出記錄次數最多的10條SQL語句
[!TIP]
/application/mysql/data/slow.log 是慢查詢日誌路徑
3.25 MySQL的備份和恢復相關知識
#資料庫備份
mysqldump -u root -p wordpress > wordpress_database.sql
#資料庫還原
mysql > source /backup/mysqldump/wordpress_database.sql
3.26 MySQL服務損壞,且沒有備份的情況下,資料庫服務如何恢復
在MySQL服務損壞且沒有備份的情況下,資料庫服務的恢復是一項具有挑戰性的任務。儘管無法完全保證恢復所有丟失的數據,但以下是一些可能的恢復步驟和策略:
1. 評估損壞程度
- 檢查日誌文件:首先,檢查MySQL的錯誤日誌和其他相關日誌文件,以瞭解服務損壞的具體原因和可能的錯誤信息。
- 檢查數據文件:檢查MySQL的數據文件(通常位於
/var/lib/mysql
目錄下),查看是否有明顯的損壞跡象,如文件缺失、損壞或大小異常。
2. 嘗試自動恢復
- InnoDB崩潰恢復:如果MySQL使用的是InnoDB存儲引擎,並且服務是因為崩潰而停止的,InnoDB會在MySQL服務重啟時自動嘗試恢複數據庫到最近的一致性狀態。這通常涉及回滾未提交的事務並應用重做日誌中的更改。
3. 使用二進位日誌恢復
- 查找二進位日誌:MySQL的二進位日誌(Binary Log)記錄了資料庫的所有更新操作,包括插入、更新和刪除等。檢查
/var/lib/mysql
目錄下是否存在二進位日誌文件(通常以mysql-bin.
開頭)。 - 分析日誌:使用
mysqlbinlog
工具分析二進位日誌文件,找出在損壞發生前執行的最後一個完整事務。 - 恢複數據:根據分析的結果,可以嘗試將二進位日誌中的SQL語句導出到一個文件中,並使用
mysql
命令將這些語句應用到新的或修複後的資料庫中。
4. 使用第三方數據恢復工具
5. 尋求專業人士幫助
6. 預防措施
- 定期備份
- 加強資料庫的監控和日誌記錄
註意事項
- 在進行任何恢復操作之前,請確保已經停止了MySQL服務,以避免在恢復過程中對數據造成進一步的損壞。
- 恢復後的數據可能需要進行驗證和測試,以確保數據的完整性和準確性。
3.27 MySQL主從架構原理
該過程的第一部分就是master記錄二進位日誌。在每個事務更新數據完成之前,master在二日誌記錄這些改變。即使事務中的語句都是交叉執行的,在事件寫入二進位日誌完成後,master通知存儲引擎提交事務。
下一步就是slave將master的binary log拷貝到它自己的中繼日誌。首先,slave開始一個工作線程——I/O線程。I/O線程在master上打開一個普通的連接,然後開始binlog dump process。Binlog dump process從master的二進位日誌中讀取事件,如果已經跟上master,它會睡眠並等待master產生新的事件。I/O線程將這些事件寫入中繼日誌。
SQL slave thread處理該過程的最後一步。SQL線程從中繼日誌讀取事件,更新slave的數據,使其與master中的數據一致。只要該線程與I/O線程保持一致,中繼日誌通常會位於OS的緩存中,所以中繼日誌的開銷很小。
3.28 MySQL主主架構原理
它包含兩個主資料庫(Master),每個主資料庫都可以處理讀寫請求,並且互為主備。
基本原理:
- 雙向複製:在兩個主伺服器(Master1和Master2)之間實現雙向的數據複製。每個主伺服器都將其更改記錄到二進位日誌(binary log)中,並且每個主伺服器都配置為另一個主伺服器的從伺服器,從而從對方的二進位日誌中讀取更改並應用到自己的資料庫中。
- 數據一致性:通過持續的雙向複製,兩個主伺服器的數據保持高度一致。這種一致性是非同步的,但可以通過配置半同步複製來減少數據延遲和提高數據安全性。
- 故障轉移:在主主架構中,如果其中一個主伺服器發生故障,另一個主伺服器可以立即接管服務,無需進行複雜的故障轉移操作。這有助於實現高可用性和業務連續性。
3.29 MySQL雙主架構一致性的問題
一、數據同步的時間差
- 非同步複製
- 同步延遲
二、併發寫操作的數據衝突
- 主鍵衝突:在雙主架構中,如果兩個主伺服器同時嘗試插入具有相同主鍵的記錄,那麼由於複製的時間差,這些插入操作可能會在各自的伺服器上成功,但在同步到對方伺服器時發生衝突。
- 數據覆蓋:如果兩個主伺服器同時更新同一條記錄的不同欄位,那麼由於複製的順序和時機問題,後一個更新可能會覆蓋前一個更新的結果,導致數據不一致。
3.30 主從架構存在的問題,解決思路
- 數據延遲
- 數據一致性問題
- 故障轉移和恢復不及時,影響業務的連續性和可用性
- 複製衝突
- 配置和維護複雜
3.31 主從複製,從庫誤操作寫入數據怎麼辦(主從不同步,會導致SQL線程停止)
這種情況常發生於從庫沒有配置super_read_only=1,然後管理員錯誤地在從庫增刪了數據,導致從庫與主庫數據不一致。要解決這類問題,通常需要在從庫執行反向操作,比如刪掉這些錯誤新增的數據,通過手動的方式讓主從數據恢復到之前一致狀態。
第零步,停止主從複製
mysql > stop slave
第一步,查看出錯的準確位置
執行show slave status命令查看從庫狀態,獲取當前已應用到的binlog信息,主要關註Last_Error中所提示的信息
第二步,確認位置
根據Last_Error中的報錯信息獲取具體出錯的SQL
show binlog events in 'mysql-bin.032102' from 730019106 limit 10; #找到對應行,該行中Info信息就是1973位置所做操作
第三步,回滾數據
定位出錯誤語句後只需要在從庫執行反向操作處理這些數據即可,然後重新啟動slave進程
第四步,開啟從庫
mysql > start slave
或者1~3步直接在從庫中修改成原來的樣子
3.32 主從複製,從庫IO線程故障排查思路
一、檢查基本連接信息
- 確認主庫地址和埠
- 檢查複製用戶許可權,密碼
- 檢查網路連通性
二、查看從庫狀態
-
執行
SHOW SLAVE STATUS\G
命令-
關註
Slave_IO_Running
欄位,如果為No
,則表示IO線程未運行。 -
檢查
Last_IO_Error
和Last_IO_Errno
欄位- 這些欄位提供了IO線程停止運行的最後錯誤信息和錯誤代碼。
根據錯誤信息和代碼,可以初步判斷故障原因。
-
3.33 主從複製中的延時從庫,半同步複製,過濾複製使用場景
延時從庫是指故意配置從庫延遲一定時間複製主庫的數據。
- 適用於數據恢復;
半同步複製要求主庫在事務提交前,至少有一個從庫已經接收到並記錄了該事務的binlog日誌。
- 適用於數據一致性要求高、高可用性和容災等場景;
過濾複製允許用戶靈活指定哪些資料庫或表需要被覆制,哪些則不需要。
-
適用於業務隔離、性能優化和數據遷移等場景。
(逐步遷移特定的資料庫或表,減少遷移過程中的風險和複雜性。)
3.34 MySQL的MHA高可用架構的原理
- 主節點監控
- MHA Manager會不斷監控主節點的狀態,包括連接是否正常、主節點是否正常運行等。
- 自動故障檢測
- 當MHA Manager檢測到主節點出現故障(如主節點宕機)時,會自動檢測並確認主節點是否真的不可用。
- 故障切換
- 一旦確認主節點不可用,MHA Manager會自動執行故障切換操作:
- 從宕機的主節點保存二進位日誌事件(binlog events),以確保數據不丟失。
- 識別含有最新更新的從節點。
- 應用差異的中繼日誌(relay log)到其他從節點,以確保所有從節點的數據一致性。
- 將最新的二進位日誌事件應用到其他從節點上。
- 提升一個從節點為新的主節點。
- 使其他從節點連接到新的主節點,並繼續複製操作。
- 一旦確認主節點不可用,MHA Manager會自動執行故障切換操作:
- 數據一致性保證
- 在故障切換過程中,MHA會確保數據的一致性,避免數據丟失或衝突。
- 故障恢復
- 當原始的主節點恢復正常後,MHA Manager會將其重新加入到主從複製架構中,並將其作為從節點與新的主節點同步數據。
3.35 如何部署MHA高可用架構
-
搭建三台mysql資料庫
-
修改配置文件/etc/my.cnf
-
server-id
-
開啟binlog日誌
-
創建主從複製用戶
-
配置主從複製主機信息
-
重啟mysql
-
開啟GTID
-
正式部署MHA
-
工具包下載
-
安裝依賴包
-
命令軟連接(所有節點)
-
部署管理節點(mha-manager:mysql-db03)
-
編輯配置文件(manage節點)
-
配置ssh信任(所有節點)
-
啟動測試(manage節點)
-
啟動MHA