産品特色
編輯推薦
適讀人群 :本書適用於MySQL數據庫管理員及MySQL應用開發者。對於相關專業的師生,本書也有很高的參考價值。 服務器瓶頸和故障是任何數據庫部署中的常見問題,但並不一定會導緻全麵故障。這本講實踐的書解釋瞭復製、集群和監控功能,無論MySQL係統運行在硬件、虛擬機還是雲上,都能幫助你保護MySQL係統不會中斷運行。
這本書由這些工具的設計者編寫,揭示瞭關於MySQL可靠性和高可用性的一些不成文的或難以發現的問題,這些知識對於任何使用這個數據庫係統的組織來說都非常重要。第2版描述瞭很多MySQL工具的變化。本書涵蓋瞭5.5版本的知識,以及若乾5.6版本的功能。
* 學習復製的基礎知識,包括二進製日誌和MySQL Replicant庫的使用
* 通過冗餘處理失效組件
* 橫嚮擴展以管理讀負載的增加,使用數據分片處理大型數據庫和寫負載的增加
* 使用MySQL集群在單個節點上存儲並復製數據
* 監控數據庫活動和性能,以及重要的操作係統參數
* 跟蹤master和slave,處理它們的故障、重啓、崩潰及其他事故
* 檢查工具,包括MySQL企業監控器、MySQL實用工具、GTID等
內容簡介
《高可用MySQL(第2版)》主要講解真實環境下如何使用MySQL的復製、集群和監控特性,揭示MySQL可靠性和高可用性的方方麵麵。《高可用MySQL(第2版)》定位於解決MySQL數據庫的常見應用瓶頸,在保持MySQL持續可用性的前提下,挖潛各種提高性能的解決方案。《高可用MySQL(第2版)》描述瞭很多MySQL工具的變化,涵蓋瞭5.5
版本的知識,以及若乾5.6版本的功能。《高可用MySQL(第2版)》的作者正是書中介紹的很多工具的設計師,《高可用MySQL(第2版)》揭示瞭MySQL可靠性和高可用性的許多不為人知的方麵。
《高可用MySQL(第2版)》適用於MySQL數據庫管理員及MySQL應用開發者。對於相關專業的師生,也有很高的參考價值。
目錄
前言 xxi
第 1章 引言 2
第 2章 MySQLReplicant庫 8
第 3章 MySQL復製原理 18
第 4章 二進製日誌 45
第 5章 麵嚮高可用性的復製 112
第 6章 麵嚮橫嚮擴展的 MySQL復製 138
第 7章 數據分片 171
第 8章 深入復製 204
第 9章 MySQL集群 263
第 10章 監控入門 300
第 11章 監控 MySQL 339
第 12章 監控存儲引擎 403
第 13章 監控復製 432
第 14章 復製的故障排除 454
第 15章 保護你的資産 481
第 16章 MySQL企業版監控 530
第 17章 使用 MySQL實用工具管理 MySQL復製 553
附錄A 復製的提示和技巧617
附錄B 一個 GTID的實現 634
索引 645
精彩書摘
創建新服務器 無論用於橫嚮擴展的slave,還是備用的新master,創建新服務器都需要對已有服務器做備份,並在新服務器上恢復這個備份映像。這需要有一個快速高效的備份方法來最小化宕機時間,並保持係統負載維持在一個可接受的水平。 法律原因 除瞭純粹業務原因需要保護數據外,法律規定也可能要求保證數據安全,即使在災難發生時。不遵守這些規定會給業務運作帶來重大問題。 簡而言之,不管有沒有其他的預防措施來保證數據的安全,備份策略對於業務運作都是必需的。 什麼是監控 即便已經正確搭建瞭復製,還有必要理解你的係統負載,並密切監控可能發生的任何問題。客戶使用模式的改變將導緻業務需求變化,需要平衡係統以盡可能高效地使用資源,降低由於資源利用的突然變更導緻係統不可用性的風險。 為瞭應對這些變更,有很多監控、度量和計劃的方法,比如: 為頻繁讀取的錶添加索引。 重寫查詢或者改變數據庫的結構,以縮短執行時間。 如果鎖被長時間占用,錶示多個連接正在使用同一個錶,可能要切換存儲引擎。 在橫嚮擴展的數據庫復製架構下,如果某些slave處理瞭大量的查詢,處於過熱狀態,係統可能需要重新均衡,以保證所有slave都被平均地訪問。 在處理資源使用的突然變更時,首先確定每個服務器的正常負載,然後瞭解在負載突然增加時,係統響應什麼時候開始變慢。 ……
前言/序言
譯者序
MySQL 是世界上最受歡迎的開源數據庫,她擁有相當大的裝機量。而且DB-Engines 的排名一直處於數據庫總榜第二名的位置,僅次於Oracle。MySQL 在開源領域排名第一,而第二大開源數據庫PostgreSQL的分數僅僅是MySQL 的零頭。
MySQL 擁有龐大的用戶群,國外的有Facebook、Flickr、eBay 等,國內的有阿裏、騰訊、新浪、百度等。而這些互聯網和大部分傳統公司的服務需要7×24 小時連續工作。當此類型網站的部分數據庫服務器宕機時,就需要高可用技術將流量牽引至備份主機,從而對在綫業務産生盡可能少的影響甚至沒有影響。
此時這些公司需要通過備份和恢復手段來産生備機,並通過復製來同步主備機間的狀態,同時部署各種監控軟件來監控服務器狀態。當異常數據庫服務器宕機時,通過手工或自動化手段將主機流量切換至備機,這個動作叫作failover。而一些大型公司在麵對成韆上萬颱MySQL 服務器時,通常使用自動化運維腳本或程序完成上述種種動作。本書解決的是MySQL 高可用問題,並圍繞著高可用問題從復製、備份恢復、監控和自動化運維4 個方麵的知識點入手。無論你的應用是迷你型的博客型應用,還是BAT 這種超大型互聯網應用,本書所涵蓋的知識點均適用。
接觸上一版的時候還是2010 年,轉眼5 年過去瞭,MySQL 也從5.1 升級到5.6,運維工具和運維方式都有較大的變化。第二版也與時具進地增加瞭一些實用性章節,本書是瞭解和學習MySQL 高可用技術相對來說較為經典的一本好書。在翻譯過程中,我們努力體現原作者想錶達的意思,但由於水平有限,有些遣詞造句還是無法達到“信達雅”,且疏漏在所難免,懇請讀者批評指正。我的微博:,可隨時與我聯係。這本書還是由唐李洋和我共同翻譯,翻譯過程由於工作原因拖延不少時間,感謝張春雨和劉舫幾位老師的辛苦工作和耐心等待。還要感謝我在平安的同事,汪洋、王鵬衝、張建龍、黃建蟬、王強、張陽,啥都不說瞭。最後感謝我的愛人王新,女兒寜悅晗,還有3 個月後見麵的傢庭新成員。
寜青
2015 年8 月27 日於深圳觀瀾
第2 版序
2011 年,Pinterest開始發展起來。有人說我們比目前其他任何創業公司的發展都要快。剛開始,我們每天都要麵臨一個新的擴展性瓶頸,它會拖慢整個網站甚至搞垮一切。還記得我們無論去哪裏都要帶上筆記本電腦,那時我們的腦子裏深深刻印著那些停機警告的短信聲音。
當基礎設施不斷地被逼到極限的時候,你就不得不尋求另一種簡單的齣路。在成長的過程中,我們嘗試瞭至少5 種廣為人知的數據庫技術,它們都聲稱能夠解決我們所有的問題,可每一次都災難性地失敗瞭,除瞭MySQL。那是2011 年9 月,我們決定從頭再來。我們用MySQL、Memcache和Redis對一切進行瞭重新設計,隻有三個工程師而已。
MySQL ?為什麼是MySQL ?對每一種技術,我們都考慮瞭其最大關注點,並提齣同樣的問題。下麵是我們對MySQL 的考慮:
它解決瞭我們的存儲需求嗎?沒錯,我們需要映射、索引、排序和blob 存儲,這些MySQL 都有。
它常用嗎?你可以招聘到相關員工嗎?MySQL 是目前生産綫上最常使用的數據庫之一。很容易招到使用過MySQL 的人,我們可以到帕羅奧多市外走走,大喊我們需要MySQL 工程師,就會冒齣來好幾個。這可不是開玩笑的。
它的社區活躍嗎?非常活躍。有好多非常棒的書籍,和一個強大的在綫社區。
麵對故障,它健壯嗎?即使在最惡劣的情況下,我們也從來沒有丟失過數據。
它的擴展性如何?就它本身來說,隻是一個很小的組件。我們需要一種上層的分片方案(這完全是另一個問題)。
你會是最大的用戶嗎?不,目前不是。最大的用戶包括Facebook、Twitter 和Google。除非你能夠改進一種技術,否則你不會想要成為它最大的用戶。如果你是最大的用戶,你會碰到一些新的擴展性問題,而其他人根本沒機會遇到。
y 它的成熟度如何?真正的區彆在於成熟度。根據復雜度的不同,成熟度就好比衡量完成一個程序所需的血、汗和淚。MySQL 的確復雜,但可比不上那些神奇的自動集群NoSQL方案。而且,MySQL 擁有28 年最好和最聰明的貢獻,來自於諸如Facebook 和Google 那樣大規模使用它的公司。根據我們的成熟度定義,在我們審查的所有技術中,MySQL 是一個明智的選擇。
有好的調試工具嗎?作為一個成熟的産品,你當然需要強大的調試和分析工具,因為人們很容易遇到一些類似的棘手情況。比如你可能在淩晨三點遇到問題(不止一次)。相比用另一種技術重寫一遍熬到淩晨六點,發現問題的根源然後迴去睡覺舒服多瞭。
我們調查瞭差不多10 種數據庫技術後發現選擇MySQL是一個明智的選擇。MySQL很棒,但它好比不給你任何行李就把你丟到目的地,讓你不得不自食其力。它運行順利的時候你可以連接到它,但一旦你開始使用它進行擴展,問題便開始滿天飛:
我的查詢執行很慢,怎麼辦?
我是不是應該啓用壓縮?怎麼做呢?
擴展有哪些方法?
怎樣復製?主- 主復製(master-master replication)怎樣?
復製停止瞭!怎麼辦?
持久性(durability,即fsync速度)有哪些選項?
我的緩衝區應該設為多大?
mysql.ini 文件裏有那麼多選項,它們是什麼意思?應該怎麼設置?
我剛剛不小心寫到slave 裏麵去瞭!怎麼防止下次發生同樣的事情?
如何防止不帶where子句的update命令執行?
應該用什麼調試和分析工具?
要使用InnoDB、MyISAM或者其他存儲引擎嗎?
雖然可以通過在綫社區查到問題答案、找到範例、修復漏洞,以及提供解決方法,但通常缺乏強大的凝聚力,而關於架構的深層討論更是寥寥無幾。我們已經知道如何小規模地使用MySQL,但這種規模和步調簡直是在開玩笑。本書可幫助我們更深刻地瞭解MySQL。
MySQL 5.6 有一個新特性,即全局事務處理(Global Transaction Handlers),為復製樹(replication tree)中的每個事務添加一個唯一標識。這個新特性使故障轉移和slave 提升變得容易很多。為此我們等瞭太久,終於在新版本中很好地實現瞭。當我們采用分片方案進行重大的重構時,關於架構決策問題我們參考瞭本書,比如復製技術和拓撲、數據分享方案、監測、調整以及雲相關的問題等。它讓我們更深刻地理解瞭MySQL 的底層運作,使我們更加瞭解瞭高級查詢、訪問模式、使用什麼結構,以及之後的重復設計。時至今日,MySQL 架構仍然為Pinterest的核心數據服務。——YashwanthNelapati和Marty Weiner
Pinterest
2014 年2 月
第1 版序
關於復製(Replication)的研究很多,但其中的大多數研究成果都沒有得到應用。相反,MySQL 復製已經被廣泛部署,但其原理並不為大多數人所知,本書將改變這種狀況。本書中介紹的內容比較適閤以下人群:願意閱讀大量的源代碼,而且在生産環境中花很多時間進行調試,能夠在深夜會議中探討這些內容的人。
復製允許在齣現不可避免的故障的情況下提供高可用的數據服務。故障的原因很多,包括磁盤、服務器或數據中心的故障。即使所有硬件都是完美無缺且完全冗餘的,還有人為因素的影響。例如,數據庫錶可能被誤刪,應用程序可能寫入瞭不正確的數據等,總會有偶然故障發生。但通過閤理的準備工作,可以保證從故障中恢復,關鍵是冗餘和備份。MySQL 復製支持冗餘和備份。
但MySQL 的復製並不僅限於支持故障恢復,它還頻繁用於讀操作的橫嚮擴展(scaleout)。MySQL 可以實現大量服務器的高效復製。對於那些讀頻繁的應用,在商用硬件上支持大量查詢是一個低成本且有效的策略。MySQL 復製還有其他有用的應用。在綫數據定義語言(DDL)是關係型數據庫管理係統中非常復雜的一個特性。MySQL 不支持在綫DDL(5.6 版本已經支持),但通過使用復製,往往可以足夠好地部分實現它。如果有創意,還可以使用復製做更多的事情。復製是使得MySQL 如此廣泛流行的特性之一,它允許將流行的MySQL 原型轉換為成功的商業關鍵部署。復製主張簡單和便於使用,這一點和MySQL 十分相似。然而,在生産環境中運行得往往不夠完美。本書解釋瞭成功使用MySQL 復製所必須知道的內容,幫助讀者理解復製是怎樣實現的,哪些地方可能齣錯,怎樣防止問題的齣現,以及怎樣在問題齣現的時候解決它們——盡管你已經很努力地避免這些問題。
MySQL 復製還在繼續完善中。與故障一樣,變化總是存在的。MySQL 需要不斷應對這些變化,使得復製更高效、更健壯、更有趣。例如,基於行的復製(row-basedreplication)是MySQL 5.1 中的新特性。盡管MySQL 部署形態各異,規模各不相同,我最關心的還是互聯網應用的數據服務。MySQL 到分布式存儲係統(如HBase和Hadoop)復製的可能性也使我興奮不已。這樣MySQL 就可以更好地共享數據中心。我曾經在Facebook 和Google 的團隊支持重要的MySQL 部署,有機會和時間學習這本書中所覆蓋的很多東西。本書的作者們同樣是MySQL 復製的專傢,通過閱讀這本書,讀者可以分享他們的專業知識。——Mark Callaghan
作者簡介
Charles A. Bell博士是Oracle的高級軟件工程師。目前是備份首席開發員,並且是MySQL備份和復製小組的成員。
Mats Kindahl博士是Oracle MySQL小組的首席高級軟件開發員。他是MySQL基於行的復製及其他幾個復製功能的主要架構師和實現者,目前是MySQL高可用性小組的架構師和項目主管,正在開發MySQL Fabric。
Lars Thalmann博士是MySQL復製和備份的開發經理。他創建並發展瞭MySQL的備份功能,引導瞭MySQL復製的變革,已經成為MySQL集群復製發展的重要角色。
譯者介紹
OCP,阿裏第一代MySQL DBA(花名玉泉),擅長自動化運維、監控,MySQL與Hadoop專傢,並熱衷於機器學習研究
高可用MySQL(第2版) 下載 mobi epub pdf txt 電子書