1. 如何構建資料庫環境

1.1. 托管MySQL

1.2. VM上構建

1.3. 天下沒有免費的午餐，每一個選擇都伴隨著一系列的權衡

2. 托管MySQL

2.1. 服務商提供了一個可訪問的資料庫設置程式，而不需要用戶深入瞭解MySQL的具體細節

2.2. 使用托管MySQL將缺乏很多的可見性和控制能力

2.3. Aurora MySQL

2.4. 谷歌雲平臺（GCP）提供了CloudSQL

3. Aurora MySQL

3.1. Aurora MySQL是一個相容MySQL的托管資料庫

3.2. 將計算和存儲分開，這使二者可以更靈活地單獨擴展

3.3. Aurora中的所有托管解決方案都不相容MySQL 8.0，而一些較舊的解決方案只相容MySQL   5.6

3.4. 標準的Aurora產品是長期運行的計算實例，在其中選擇一個實例類型

3.5. Aurora集群內的複製完全是Amazon專有的，而不是我們在Oracle MySQL中所知道和使用的複製

3.6. Aurora無伺服器（Serverless）

3.6.1. Aurora MySQL的無伺服器服務移除了長期運行的計算程式，並利用亞馬遜的無伺服器平臺為資料庫的計算層提供服務

3.7. Aurora全局資料庫（Global Database）

3.8. Aurora多主節點（Multi-Master）

3.8.1. 多主節點是Aurora集群的一種特殊風格，可以同時在多個計算節點上接受寫操作

4. GCP Cloud SQL

4.1. Cloud SQL是GCP的托管MySQL的產品

4.2. 它運行的是社區版MySQL，但特別禁用了某些功能，以實現產品的多租戶和可管理

4.3. SUPER許可權被禁用

4.4. 插件載入功能被禁用

4.5. 一些客戶端也被禁用了，如mysqldump和mysqlimport

4.6. 原生的高可用性支持

4.7. 靜止數據的原生加密

4.8. 使用多種方法實現靈活管理的升級

5. 虛擬機上的MySQL

5.1. 在虛擬機上運行MySQL就像在裸金屬伺服器上運行一樣，你可以完整和徹底地控制所有的操作面

5.2. CPU

5.2.1. 虛擬CPU，而不是物理CPU

5.2.2. vCPU數量的計數公式

5.2.2.1. （CPU核的數量×95%CPU總使用量）×2

5.2.2.2. 建議將50%作為常規的使用率目標，最高可達到65%～70%

5.2.2.3. 如果維持在70%或更高的CPU使用率，將可能會看到延遲增加，此時應該考慮添加更多的CPU

5.2.3. 運行的是一個高流量的Web應用程式，則可能需要確保使用更新一代的晶元

5.3. 記憶體

5.3.1. RAM可以極大地影響MySQL的性能

5.3.2. 應為工作數據集選擇最適合需求的機器規格，但錯誤的做法是RAM太多而不是不夠

5.4. 網路性能

5.4.1. 如果有一個將讀取大量數據的批處理進程，則你可能會發現在較小的機型上帶寬已耗盡

5.5. 選擇正確的磁碟類型

5.5.1. 高讀密集型的工作負載將受益於更多的記憶體而不是磁碟性能，因為記憶體訪問要快幾個數量級

5.5.2. 如果工作集大於InnoDB緩衝池，那麼將總是需要到磁碟上讀取一些數據

5.5.3. 寫密集型的工作負載總是會轉移到磁碟上，這也是大多數人第一次看到磁碟瓶頸的地方

5.6. 磁碟的連接類型

5.6.1. 本地連接磁碟的好處是，其提供了令人難以置信的高性能和一致的吞吐量，但也很容易導致數據丟失

5.6.1.1. 被視為僅用於短暫數據的磁碟

5.6.2. 網路連接的磁碟可提供冗餘和可靠性

5.6.2.1. 網路連接的磁碟可能會遇到本地連接的磁碟不會出現的停頓

5.6.3. 還可以使用磁碟快照技術讓副本複製變得非常快，即使在許多TB級大小的磁碟上

5.6.3.1. 可以讓需要在副本可用之前趕上來的複製的延遲降到最低

5.7. SSD與HDD

5.7.1. SSD的啟動速度比HDD快兩到三倍

5.7.2. 如果啟動時間很重要，特別是在停機或重新啟動的情況下，那麼請始終使用SSD

5.8. IOPS和吞吐量

5.8.1. Percona Toolkit包中的pt-diskstats

5.9. 只允許伺服器恢覆在線和複製，以讓它自己自然地重新連接

5.9.1. 使用SSD引導磁碟來允許儘可能快地重新啟動。通常系統會在5分鐘內恢覆在線

5.9.2. 禁止長達5分鐘時間內的任何伺服器宕機的告警通知，以使系統完全重啟並恢復正常

5.9.3. 如果源伺服器重新啟動，你可以編寫一個選項來動態關閉read_only標誌，從而讓寫入在沒有人工干預的情況下繼續進行

5.9.4. 通過自動地向可能需要瞭解中斷的團隊或渠道發送郵件或消息，來讓溝通最大化

5.10. 建議將操作系統和MySQL數據分開

5.10.1. 磁碟快照將僅限於MySQL數據，並且不包含任何操作系統信息

5.10.2. 在使用網路連接的磁碟的情況下，可以輕鬆地斷開磁碟的連接並重新連接到另一臺機器

5.10.3. 對於網路連接的磁碟，還可以升級或替換操作系統，而不必將數據重新複製到文件系統中

5.11. 備份二進位日誌

5.11.1. 將二進位日誌發送到一個存儲桶中

5.11.2. 在桶上設置生命周期控制，以便在一段確定的時間後自動清除舊文件

5.11.3. 阻止在特定時間之前刪除文件，或完全不允許刪除

5.11.4. 控制誰可以讀取或刪除這些數據對於維護安全的備份策略至關重要

5.11.5. 建議允許所有資料庫機器寫入，但沒有機器能夠讀取或刪除。分別或同時控制受限賬戶、機器的讀取和刪除

5.12. 自動擴展磁碟

5.12.1. 對於網路連接的磁碟，需要為預分配的而不是已使用的空間付費

5.12.2. 一種優化方法是將磁碟空間使用率目標提到更高的百分比

6. 合規性

6.1. DBA的工作並不局限於在業務運行時管理這些數據，還需要幫助企業保護數據，並使數據符合法律要求，或獲得對企業至關重要的監管認證

6.2. 合規是一個涉及政策和控制的廣泛領域，對每種政策和控制的解釋也很多

6.3. GRC

6.3.1. 治理（Governance）

6.3.2. 風險管理（Risk management）

6.3.3. 合規性（Compliance）

6.4. 控制是公司內部定義的流程和規則，用於減少意外風險結果發生的概率

6.5. 合規性的構建是一個持續的過程，在需要的時候不容易“添加”

6.6. 法規法案

6.6.1. 服務組織控制類型2（SOC 2）

6.6.2. 2002年發佈的薩班斯-奧克斯利法案（SOX）

6.6.3. 支付卡行業數據安全標準（PCI-DSS）

6.6.4. 1996年發佈的《健康保險可攜帶性和責任法案》（HIPAA）

6.6.5. 聯邦風險和授權管理計劃（FedRAMP）

6.6.6. 通用數據保護條例（GDPR）是歐盟於2016年推出的

6.6.7. 2020年，歐盟司法法院裁決了歐盟和Facebook愛爾蘭分部之間的一樁案件。這項通常被稱為Schrems II

6.7. 不要共用用戶

6.7.1. 不要跨服務共用資料庫憑據

6.8. 不要在代碼倉庫中提交生產資料庫憑據

6.8.1. 一種常見的做法是在合併一個pull請求之前，掃描代碼庫尋找潛在的機密字元串（GitHub等代碼倉庫托管服務可以實現

6.9. 確保密碼始終以加密方式而不是以明文形式存儲

6.9.1. 機密信息的長度做了限制，如果想存儲比資料庫的用戶和密碼對更長的內容，可能會導致意外

6.10. 區域的可用性

6.11. 角色與數據分離

6.11.1. 基於數據泄露將給企業或客戶帶來的風險等級對數據進行分離

6.12. 出於合規性原因進行分片

6.13. 獨立的資料庫用戶

6.14. 跟蹤變更

6.14.1. 很多合規性法規都附帶了跟蹤變更的控制措施

6.15. 很多合規性法規都附帶了跟蹤變更的控制措施

6.16. ⑩數據訪問日誌

6.16.1. 要求維護特定數據集的變更日誌或訪問日誌

6.16.2. Percona審計日誌插件是Percona發行的MySQL分支的一部分，但是預設情況下沒有安裝或啟用

6.17. ⑾schema變更的版本控制

6.18. 建議設置這樣一個策略：“刪除六個月內未連接過資料庫的用戶”。這一做法將有助於防止使用不需要的、現在已成為負擔的訪問

7. 不建議使用觸發器

7.1. 觸發器會導致寫性能下降，這會在最糟糕的時候對性能造成影響

7.2. 觸發器相當於在資料庫中存儲業務邏輯，這是不推薦的

7.3. 在資料庫中存儲代碼可能會繞過測試、轉移和部署代碼的任何過程。觸發器可能意外地導致故障

7.4. 觸發器只能支持跟蹤寫入操作。無法擴展成可以跟蹤讀取訪問的解決方案