MySQL · 社區見聞 · OOW 2015 總結 MySQL 篇 · 數據庫內核月報

## 前言 && 感想本年度Oralce Open World會議從十月25號到29號，在美國舊金山舉行。數萬來自全球各地的從業人員涌入Moscone Center，見證一年一度的Oracle生態系統盛事。本次OOW2015的主題都是圍繞在Oracle Cloud，云服務應該是Oracle之后的發力點。幾場Oracle CTO（前Oracle CEO）Larry的主題演講也圍繞cloud，詳細闡述了Oracle Cloud的設計原則，及相關的云產品，其目標直指Amazon和Microsoft的云服務。我在OOW的關注點主要是幾場KeyNote以及MySQL相關的Topic。先總結下參會的感受吧： 1. Oracle的主場還是集中在Oracle database, Oracle Cloud以及Java。而“不太會賺錢”的MySQL主題則安排的比較少，會場也都是最小的； 2. 關于MySQL，前幾天MySQL5.7版本在前幾天剛剛宣布GA，因此本次會議的官方主題都是關于新版本的特性介紹，新的版本帶來了大量新特性（例如GIS、Build-in JSON、新的Fulltext Parser、Generated Column）以及性能優化（復制性能、InnDB讀寫性能），大量內部鎖競爭的移除，使得新版本MySQL能夠在多核環境下更好的Scale Up，發揮硬件的性能； 3. 大部分內容都是已有的技術，并沒有什么新的黑科技； 4. 也有幾家美國公司來介紹他們如何使用MySQL，但類似Facebook、Twitter這樣的MySQL重度用戶且對社區有很大貢獻的公司卻集體缺席，不得不說是個很大的遺憾； 5. 從這幾家公司使用MySQL的情況來看，我感覺阿里在MySQL領域的工作絕對是首屈一指的，沒有多少公司像我們這樣把MySQL玩的這么深入，這么深度的修改源碼來適應我們的環境。明年如果有機會，不管誰去參加，我覺得都可以考慮去做幾個主題演講，宣傳公司在MySQL社區的影響力； 6. 從交流了解到，美國很多互聯網公司都選擇把服務器托管在AWS上。未來阿里云的國際化，需要把我們的技術影響力擴展到國外，才能爭取到這樣的用戶。以下是這五天期間我關注的幾個Topic，主要從Oracle 、MySQL官方演講、業界使用三個方面劃分。 ## Oracle主題 ### Oracle OpenWorld Welcome Keynote [KEY10818] Larry Ellison, Executive Chairman of the Board and Chief Technology Officer, Oracle Brian Krzanich, CEO, Intel Corporation [視頻鏈接](https://www.oracle.com/openworld/on-demand/index.html) 當天第一場重磅keynote，由intel的CEO主持，這次會議著重強調Intel和Oracle的深度合作帶來的價值，順便開刷了下IBM在云計算領域的落伍。最后壓軸的是Larry的演講，主題是Oracle Cloud服務，他明確指出了其在SAAS領域的對手是Salesforce，PaaS領域的對手是微軟而不是IBM，IaaS領域的對手是Amazon（Aliyun在美國還是籍籍無名啊…）。相對于這些競爭對手，Oracle要做全平臺的云服務提供商：在SaaS提供全部種類的商業應用，例如CX、HCM、ERP、EPM等；在PaaS領域提供完全符合工業標準的平臺服務；在IaaS領域突出安全性、可靠性、低開銷，標準化的基礎設施服務。為了達成上述目標，Larry從以下幾個角度闡述了Oracle云服務的設計目標：第一是低成本（cost），包括價格上具備競爭優勢，通過自動化降低人力成本和人為誤差，更輕易的創建和使用應用來減少成本。第二是高可用性(reliability)，實現零宕機時間。兩個方面： 1. fault tolerant，通過冗余設計，hot patching及備份，即時恢復來實現； 2. 自動化(automation)，消除在部署、補丁、備份及恢復期間的人為錯誤。第三是高性能，從三個方面闡述： 1. 數據庫，in-memory in-flush的列式數據庫，部署在云中的Exadata； 2. 中間件，In-memory speed-of-thought Analytics; 3.Sale-out架構，彈性能力，和按需獲的性能。第四是標準化，支持工業標準的SQL、Hadoop、NoSQL等等，讓用戶能夠無鎖定的自由遷移到其他云服務平臺。第五是兼容性，能夠自動遷移負載和數據。例如從公有云和私有云之間自由遷移。第六是安全性，能夠持續的抵御黑客攻擊。最新發布的SPARC M7處理器在硬件層支持實時的安全監測；另一方面也提供數據加密。在闡述上述觀點后，隨后發布了一大堆的云產品，Oracle強勢宣布了其正式進入了云計算領域。 ### Exploring Oracle Database 12c New Features Best Practices for DBAs and Developers [UGF7904] Ami Aharonovich, CEO, DBAces-ilOUG [PPT鏈接](https://published-rs.lanyonevents.com/published/oracleus2015/sessionsFiles/2316/UGF7904_Aharonovich-Oracle%2012c%20New%20Features%20for%20Developers%20and%20DBAs%20-%20October%202015.pdf) 介紹了Oracle 12c的一些新特性，以及如何使用這些特性，作為一名MySQL開發，最讓我感興趣的是MySQL中沒有的功能，以及是否能將Oracle的這些功能也實現到MySQL中去。以下是幾個筆記的點。隱藏列屬性：定義為“column_name TYPE INVISIABLE”。當設置該屬性后，這個列的內容對客戶端而言就是不可見的，但如果顯式的指定列名的話，則可以對該列進行操作，主要用于類似應用遷移之類的場景，例如增加新的列，不影響老的應用，同時新的應用也可以通過指定列的方式進行操作。MySQL可以考慮把這個特性Port過來。[這個文檔](https://oracle-base.com/articles/12c/invisible-columns-12cr1)?有對該特性的描述。默認的sequence值：可以默認獲取一個新的sequence值（定義為column_name TYPE DEFAULT seq_name.nextval），另外一種方式是在列上定義一個[IDENTIFY](https://oracle-base.com/articles/12c/identity-columns-in-oracle-12cr1)屬性（id NUMBER GENERATED ALWAYS AS IDENTITY）仔細想想，這貨不就是MySQL的Auto-Increment屬性么。 Data Redaction：顧名思義，就是數據修訂的意思，對返回給客戶端的值進行修訂，例如將敏感信息用”*“代替返回。有FULL Redaction、Partial Redaction、Regular expression、Random Redaction、No Redaction幾種。如下圖所示： ![](https://box.kancloud.cn/2015-11-17_564aa53aac099.png) reduant 具體介紹參閱[這篇文章](https://docs.oracle.com/cloud/latest/db121/ASOAG/redaction.htm#ASOAG594)。下圖描述了這個特性的一個典型應用。感覺是個比較有意思的特性，后面看看怎么做的，可以考慮實現到MySQL里 ![](https://box.kancloud.cn/2015-11-17_564aa53ac943e.png) red use 更好的加列操作：如果列的值允許為NULL，加列操作不會產生表上所有記錄更新，而是修改元數據。當查詢到這個列時，如果尚未有數據，則從元數據中獲得其default值，并返回給客戶端。同樣的思路可以應用于MySQL。 Adaptive Execution PLan：運行過程中自動調整執行計劃，最終的計劃取決于執行過程中看到的行數。在該演講slide的最后貼了大量關于Oracle 12c相關的鏈接，感興趣的可以點開了解下。 ### General Session: Software in Silicon and SPARC Outlook—Secure, Smarter Database/Applications [GEN6421] Masood Heydari, SVP, Hardware Development, Oracle [PPT鏈接](https://published-rs.lanyonevents.com/published/oracleus2015/sessionsFiles/2257/GEN6421_Heydari-GEN6421-Heydari-OOW2015.pdf) 介紹新發布的SPARC M7 處理器，其性能強悍，號稱有32個core，256線程，4.13GHZ，64MB的L3 Cache, 支持最大2TB的物理內存，支持4路DDR4 內存控制器；并且相比前一代有3倍IO帶寬提升；該處理器還支持Silicon Secured Memory， DB query Acceleration，Inline Decompression，將軟件功能集合到硬件中，從而最大化發揮效率。其號稱世界上最快的微處理器，其基于硬件的內存安全防護，能夠防止黑客非法訪問內存內容 ## MySQL官方演講 ### How to Analyze and Tune SQL Queries for Better Performance [TUT3411] Oystein Grovlen, Senior Principal Software Engineer, Oracle [PPT鏈接](https://published-rs.lanyonevents.com/published/oracleus2015/sessionsFiles/2293/TUT3411_Grovlen-How%20to%20Analyze%20and%20Tune%20SQL%20Queries%20for%20Better%20Performance-OOW2015.pdf) 演講者為MySQL團隊優化器模塊的開發人員，重點介紹了優化器的相關知識，包括優化器的執行過程， MySQL 5.7引入的cost model ，5.6版本之后引入的物化統計信息。其中比較有意思的點是cost model，介紹了用戶如何通過設置cost model來影響優化器的行為。通過實例介紹了索引選擇的類型，介紹了join和子查詢是如何進行優化器選擇的，以及排序和聚合操作。該演講的slide干貨滿滿，對優化器感興趣的同學非常值得一看。 ### MySQL Replication Tips and Tricks [TUT5467] Joao Gramacho, Software Developer, Oracle [PPT鏈接](https://published-rs.lanyonevents.com/published/oracleus2015/sessionsFiles/1651/TUT5467_Gramacho-2015-TUT5467-MySQLReplicationTipsAndTricks-v11.pdf) 詳細介紹了MySQL的復制模塊，以及大量的使用技巧及5.7的新特性，從淺顯的知識到更深入的討論都有涉及，適合對復制模塊感興趣的各個層次人群閱讀。 ### InnoDB: What’s New in MySQL 5.7 [CON3716] Sunny Brain, InnoDB Developer Manager 暫無PPT InnoDB的開發主管Sunny Brain介紹了MySQL5.7對InnoDB模塊的改進，總的來說，主要包括以下幾點： General tablespace：一種用戶定義的表空間，在磁盤上會生成一個ibd文件，可以指定表空間名來創建表，這些表的數據都存儲到一個ibd文件中。 Virtual column：支持虛擬列，即用戶通過預設的表達式定義的列，這樣的列不存儲數據，但支持基于其上建立索引。一種典型的應用是基于Json類型數據之上，使用json相關函數創建虛擬列。隔天Jimmy Yang有個演講專門介紹這一塊。 native partition：將分區表的引擎接口從Server層轉移到InnoDB層，這意味著之前每個分區都需要一個存儲引擎接口，現在則只需要一個引擎接口，對于包含大量分區的分區表而言，可以減少不少內存消耗。另外這種改變，也使得未來基于分區表做并行查詢更加簡單。全文索引：改進了全文索引，可以更好的支持中文全文索引分詞，這極大的彌補了5.6版本InnoDB全文索引的不足之處，從5.7版本開始，MySQL用戶可以完全拋棄MyISAM引擎的全文索引 R-Tree Index(GIS Support)：開始支持GIS空間數據類型，彌補了MySQL和其他數據庫（如PostgreSQL）相比的一大缺憾，GIS對當前基于地理空間的應用是非常重要的功能。性能優化：在5.7版本對讀寫性能做了大量的優化，例如優化了讀寫事務鏈表的管理，Read View緩存(兩個只讀查詢之間沒有新的讀寫事務，則認為read view是可重用的)，消除了大量的事務鎖瓶頸。基于這些改進，新版本的性能（尤其是讀性能）能夠在多核場景下獲得更好的性能。在討論到Read view緩存時，我發現在RC隔離級別下，這一優化策略并沒有生效，和Sunny討論了下這個問題，他表示認同。索引鎖優化：引入SX Lock，在對btree做分裂或合并操作時，不再鎖住整棵btree，從而降低對讀負載的影響。事務生命周期特性：（主要用于支持5.7另外一個新特性：Group Replication），包括高優先級事務，高優先級獲取記錄鎖（可以從記錄鎖隊列中往前跳），kill其他低優先級事務。目前這幾個特性還對終端用戶不直接可見。 DDL優化：對于索引創建，在之前的版本中使用先排序數據，再執行插入到新btree中的方式，而新版本則使用自低向上的索引構建方式，即先構建葉子節點，再從葉子節點開始構建非葉子節點，這樣具有極高的索引創建效率。 Intrinsic table：主要被優化器使用，在之前版本中使用的是MyISAM引擎來作為查詢過程中產生的臨時表引擎；在5.7版本中，InnoDB對臨時表(intrinsic table)做了大量優化，包括獨立的臨時表表空間，獨立的undo回滾端，減少redo log的記錄。下圖是他們的性能比較圖，可以看到InnoDB在高并發下能獲得更好的性能。 ![](https://box.kancloud.cn/2015-11-17_564aa53ae088b.png) intrinsic table Memcached：由于消除了大量的性能瓶頸，MySQL5.7的Memcached Plugin相比5.6有了數倍的提升，而在穩定性上，也修復了大量的bug，相信5.7版本能夠改變5.6版本Memcached plugin無人問津的窘境。 ![](https://box.kancloud.cn/2015-11-17_564aa53b07463.png) memcached 其他還包括諸如大Page Size支持，CRC32的Redo log校驗，多個Page cleaner線程及buffer pool刷臟邏輯優化。總的來說，MySQL5.7是個非常值得期待的版本。 ### Building Scalable, High-Availability Systems Using MySQL Fabric [CON4975] Mats Kindahl, Senior Principal Software Developer, Oracle 暫無PPT 介紹了MySQL新組件Fabric，主要用于構建高可用，可擴展的系統。Fabric本質上是一組腳本，算是官方出品的HA和Sharding工具。由于阿里在這一塊已經非常的成熟，我對Fabric本身并不感興趣，感興趣的可以參閱[官方文檔](http://dev.mysql.com/tech-resources/articles/mysql-fabric-ga.html)。而對為了支持fabric對服務器端代碼做的改動比較感興趣。總的來說，為了支持Fabric，MySQL本身做了幾點改動：實現一種新的方法來清理session的狀態，可以reset 已有的會話，例如清理其內容并釋放資源（WL#6797），這在我們RDS里也有類似的實現。允許MySQL服務器進入一種離線狀態，讓已有的連接優雅的斷開（SUPER賬戶除外），這主要用于升級或者維護服務器。該特性也用于fabric來輔助管理MySQL集群。(WL#3836) 增加一個服務器層的flag來判斷是否有一個新的事務開啟了，主要用于連接池的負載均衡，如果一個session未開啟事務，就可以把它的請求調度給別的連接。 (WL#6631) 另外在29號也有另外一個關于Fabric的主題演講，[參閱PPT](https://published-rs.lanyonevents.com/published/oracleus2015/sessionsFiles/3373/CON5209_Correia-CON5209%20-%20MySQL%20Fabric%20Tips%20and%20Tricks%20-%20OOW%202015.pdf)。 ### MySQL 5.7: What Is New in the Optimizer? [CON3379] Manyi Lu, Senior engineering manager, Oracle [PPT鏈接](https://published-rs.lanyonevents.com/published/oracleus2015/sessionsFiles/2093/CON3379_Lu-OptimizerOOW2015.pdf) 負責MySQL服務器層的開發主管介紹了MySQL5.7版本對Optimizer模塊的優化，主要包括如下幾個方面的改進。 Generated Column：用戶可以在建表或ALTER時創建的一種新的列類型，列的數據可以通過一個預設的表達式來進行計算，如下建表語句： ~~~ CREATE TABLE order_lines (orderno integer, lineno integer, price decimal(10,2), qty integer, sum_price decimal(10,2) GENERATED ALWAYS AS (qty * price) STORED ); ~~~ 最后一個列的值為qty列和price列相乘得到。STORED屬性表示在插入或更新時計算該列的值并存儲到物理文件中。你也可以選擇VIRTUAL屬性，這樣就只在查詢時計算。這可以滿足一些特殊的需求：例如實現基于方法的索引，物化緩存復雜的條件，簡化查詢SQL表達式。 JSON Support：支持內建的JSON類型的數據存儲，并提供一組JSON函數。使用也比較簡單，直接將列類型定義為JSON。對于JSON類型的數據，在插入或更改時，會進行格式檢查，通過新的語法和函數，也可以更方便的操作JSON數據。和Generated Column相結合，我們還可以對json中的數據進行索引創建，從而索引json中的某個數據段。 PS：當天有另外一個演講專門對JSON[做了介紹](https://published-rs.lanyonevents.com/published/oracleus2015/sessionsFiles/2644/HOL8467_Kojima-HOL8467.pdf) Cost Model：用戶可以根據自己的硬件場景來配置cost model，進而影響優化器的選擇。基于5.7的cost model，解決了如下幾個問題： 1. 對于JOIN操作的記錄數估計不準確； 2. hard-code的代價常量； 3. 不準確的record-per-key，使用浮點數代替； 4. 使用json輸出explain的結果。Manyi Lu強調在下一個版本中，他們會著重解決優化的cost model自動調整功能，而不是依賴人來配置。新的HINT表達式：在插敘中使用 /+ …/ 來開啟一些優化器或者其他選項，例如BKA, BNL, MRR, ICP, SEMIJOIN, SUBQUERY，MAX_EXECUTION_TIME等等常用HINT。 Query Rewrite Plugin：一種新的插件類型，主要解決的問題是在不修改應用的情況下，更改其SQL的行為，例如如果優化器總是為這個SQL選擇錯誤的執行計劃，就可以為其加上hint做強制索引選擇。 UNION ALL問題：在5.7版本終于解決了臭名昭著的UNION ALL總是創建臨時表的問題，多個表做UNIALL ALL時，數據先存儲到臨時表，然后再發送，但UNION ALL并不需要結果集的順序性和唯一性，沒有必要構建臨時表來作去重。 IN表達式優化：在之前的版本中，對于這樣的表達式WHERE (a, b) IN ((0, 0), (1, 1))，即時(a,b)上存在索引，也無法使用IN表達式中的值去查詢索引，在5.7解決了這個問題，可以使用索引做range scan。 EXPLAIN：可以去查看一個正在運行的SQL的執行計劃，這個特性對我們診斷問題非常有用。最后Manyi Lu罕見的給出了下一個版本優化器模塊的RoadMap（Oracle的開發人員通常不會對下一階段的開發發表評論），包括： 1. 改進對存儲過程的支持； 2. 增加類似oracle的直方圖； 3. 支持并行查詢； 4. 公用表表達式(Common table expression) 。在后面的討論中，Manyi Lu也透露了“查詢計劃緩存”也在開發的計劃中（盡管這里沒有列出來）。從優化器的進化可以看出來，MySQL的優化器模塊開始變的越來越像Oracle了。希望新版本的MySQL5.7能夠改變人們一向的“MySQL優化器很弱”的印象。 ### Update Everywhere with the MySQL Group Replication Plugin [CON5349] Nuno Carvalho, Principal Software Engineer, Oracle 暫無PPT 介紹了MySQL的一種新的插件類型：Group Replication plugin，主要用于類似active-active復制拓撲結構的集群管理，支持多個節點更新，自動沖突檢測，自動增刪節點等功能，類似MariaDB的Galera。Group Replication目前已經到了0.6.0版本，但還沒有正式GA。使用Group Replication，需要保證使用的表都是InnoDB表，并且定義了主鍵。Binlog需要使用Row模式。 Group Replication的分布式一致性協議基于XCom，一種PaxOS協議的變種。關于沖突檢測，開發了一組[Group Communication 工具集](http://mysqlhighavailability.com/group-communication-behind-the-scenes/)，提供了完全有序的廣播，也就是說，消息在所有的節點都按照同樣的順序進行應用。當產生一個新的更新消息時（以類似binlog row格式存儲）： 1. 在當前實例上完成，但block在commit階段； 2. group communcattion組件會負責將消息發送到所有依然活躍的節點。 3. 最關鍵的是決定本地事務是該提交還是回滾。這就涉及到如何進行沖突檢測，每個行記錄都有一個版本信息，在行被更新時，版本也會遞增。主要通過節點間行記錄的版本信息來進行沖突檢測； 4. 如果不存在沖突，則全部提交；否則全部回滾。版本信息是通過GTID維護的，所有實例的UUID是全局統一的，并保證了所有節點產生的GTID不會重復。有兩個版本信息，一個是database version，也就是本地的version（dbv），另外一個是確認模塊的version（cv），下圖是一個典型的沖突解決場景： ![](https://box.kancloud.cn/2015-11-17_564aa53b23ba1.png) group replication 關于一個事務在Group Replication集群中的生命周期，參閱[這篇博客](http://mysqlhighavailability.com/mysql-group-replication-transaction-life-cycle-explained/) 關于節點踢出和重新加入的邏輯，參閱[這篇文章](http://mysqlhighavailability.com/distributed-recovery-behind-the-scenes/) 如何[使用Group Replication](http://mysqlhighavailability.com/getting-started-with-mysql-group-replication/) 在[官方博客](http://mysqlhighavailability.com/)上還有不少文章介紹Group Replication，感興趣的可以深入研究下。 ### What’s New in MySQL 5.7 Security [CON1559] Georgi Kodinov, Senior Software Development Manager, Oracle [PPT鏈接](https://published-rs.lanyonevents.com/published/oracleus2015/sessionsFiles/2512/CON1559_Kodinov-OOW15%20CON1559%20What%27s%20new%20in%20MySQL%20Security.pdf) 主要介紹了MySQL 5.7 包含的一些安全特性。包括：企業版特性： 1. SQL防火墻用于包含實例免受預期外的SQL注入侵害; 2. 企業版數據加密。賬戶管理： 1. 增加ALTER USER語法來修改用戶權限。 2. 臨時權限禁止功能； 3. 基于時間的權限失效策略； 4. 服務器提供offline模式。重構及新功能： 1\. 新的權限表格式； 2\. 提供基于AES的加解密函數； 3\. mysql_secure_install/mysql_install_db使用c語言進行了重構；mysql_upgrade不再調用外部程序。 ## 業界使用 ### MyRocks： MySQL on RockDB Yoshinori Matsunobu, database developer at facebook 由于26號沒有什么比較值得關注的主題，我們應facebook的邀請，26號下午去拜訪了Facebook的MySQL開發團隊，了解了下之前我們一直關注的MyRock開發情況，他們的開發Yosh專門為我們做了介紹。說到MyRock，需要先介紹下RockDB。RockDB是facebook基于LevelDB的一個分支，他們在其上做了大量的優化，目前已經集成到Mogodb 作為一個plugin，Percona公司也開始針對RockDB提供技術支持。RockDB基于LSM存儲結構，能夠有效的減少磁盤擦寫的次數，這對Facebook非常重要，因為在他們那里flash設備已被廣泛使用，通過rockdb能夠有效的控制磁盤成本。另外更大的SST 文件塊大小相比InnoDB獲得更好的壓縮效果，減少磁盤的存儲空間。但是RockDB僅僅支持key-value，并沒有SQL接口，如果想用rockdb取代已被廣泛使用的InnoDB，應用修改的成本巨大，因此他們啟動了MyRock項目，將RockDB包裝成MySQL的一個存儲引擎。Yosh透露預計明年會出一個GA版本，目前還處于開發狀態，他們也在該項目上和MariaDB進行緊密合作。為了進一步減少磁盤空間，他們實現了“prefix key encoding”，即對于具有相同前綴的行記錄，這些相同的列值只存儲一次。不過這樣也帶來了一些負面作用，即需要在建表時設定是正序存儲還是逆序存儲，因此需要和應用方商量好。由于LSM具有分層結構，對查詢并不友好，最差情況下每個level可能都需要查詢一遍。一次帶order by的range scan需要將多個level的結果進行merge，這不像基于Btree結構的InnoDB，直接做一次順序掃描即可。為了優化該場景，他們在MyRock中引入了bloom filter來加速查詢，快速確認某個level是否有需要的記錄，減少不必要的IO。目前MyRock還有一些限制，包括：不支持Online DDL、Foreign Key、Spatial Index、以及Fulltext；所有表必須有primary key；不支持next-key lock，并且必須使用row格式復制；不支持binlog和myrock的XA；ORDER BY DESC/ASC 由于prefix key encoding，總有一個會比較慢點；大量刪除操作會影響到整體性能。總的來說，他們并不期望myrock能完全取代InnoDB，只是期望在某些場景下能利用LSM的優點。目前該項目公布在github上，代碼的開發進度、提交日志一目了然，不得不讓人敬佩facebook的開源和社區合作精神。 ### A Global Transaction Identifier Rollout at Dropbox [CON4766] Rene Cannao, MySQL DBA, Dropbox David Turner, Database Administrator, Dropbox [PPT鏈接](https://published-rs.lanyonevents.com/published/oracleus2015/sessionsFiles/2348/CON4766_Turner-Rolling%20out%20gtids%20at%20Dropbox%20%282%29.pdf) Dropbox公司分享了他們如何使用GTID。沒啥新東西，主要的問題還是GTID無法動態調整，導致整個MySQL集群無法升級到5.6及之后版本的問題，這個問題在社區（例如Facebook和booking）都做了些簡單的patch來繞過這個問題，咱們的RDS MySQL也有相應的改動。這個問題在5.7版本得到了徹底的解決。Gtid的開啟和關閉被劃分成了多個階段，來保證整個復制拓撲的GTID一致性 ### Making MySQL More Efficient at Pinterest [CON3654] Ernie Souhrada, Database Engineer, Pinterest Robert Wultsch, Database Engineer, Pinterest 暫無PPT Pinterest公司的兩位數據庫工程師（實際上他們整個team就兩個人），一個是前Percona員工，一個是前Facebook員工。他們分享了Pinterest如何讓MySQL更高效。由于只有兩名員工，他們選擇更多的依靠已有的技術，例如備份使用MySQL Enterprice Backup。他們提到一個比較有意思的問題是，在數據庫中他們存儲了大量的JSON數據，這些數據列的大小平均為1.2kb。正好他們看到了我們以前分享的關于單列壓縮的改進，在他們的場景下測試得出的結論是，列壓縮在保證性能的基礎上，依然能提供不錯的壓縮比。他們在列壓縮的基礎上，對這個功能進行了擴展，方案交給Percona進行開發。也就是所謂的Predefined Compression dictionary。會后和他們交流了具體的方案，了解了這個改進的具體內容：其本質是將需要壓縮的數據預先定義好，然后在全局使用這個預先定義的數據詞典進行壓縮。定義兩張系統表，一張系統表存儲數據詞典信息，另外一張表存儲列與數據詞典的映射。由于預先定義好了壓縮前綴詞典，即時一個字符串在某個列中只出現了一次，也是可以被壓縮的。壓縮前綴詞典可以通過訓練已有的數據集得到。這確實是一個非常有趣的思路，對他們的這種場景，減少了72%的磁盤占用。 ### Binlog Servers at Booking.com [CON4098] Jean-Franc?ois Gagne?, Senior System Engineer, Booking.com [PPT鏈接](https://published-rs.lanyonevents.com/published/oracleus2015/sessionsFiles/2705/CON4098_Gagne%CC%81-binlog_servers%40booking.com_oow2015.pdf) 來自booking的開發人員介紹了他們的binlog server工具，根據其描述，其工作原理就是一個獨立的server，從master上讀取binlog，存儲到本地；然后將自己當做一個“假”的master，將binlog分發到各個slave節點。在阿里，我們早幾年就有了類似的工具，例如DRC， Transfer，精衛等。不過booking結合binlog server實現了其生產環境的高可用，讀擴展以及時間點恢復功能。 ### YouTube Vitess: Cloud-Native MySQL [CON11339] Anthony Yeh, Software Engineer, Google [PPT鏈接](https://published-rs.lanyonevents.com/published/oracleus2015/sessionsFiles/2266/CON11339_Yeh-Vitess.pdf) 來自谷歌的工程師介紹了Youtube的開源項目Vitess。對分布式中間件不太了解。沒啥感覺 ### Feed Your Streams: Zendesk’s Maxwell Generates Kafka Event Stream from MySQL Binlogs [CON3340] Ben Osheroff, Principle Engineer, zendesk.com [PPT鏈接](https://published-rs.lanyonevents.com/published/oracleus2015/sessionsFiles/1969/CON3340_Osheroff-Maxwell%20Talk.pdf) zendisk的工程師分享了另外一款開源的工具，同樣也是用于解析Binlog的，不同的是，把binlog的內容解析成了json的格式并復制到Kafka，算是玩出了新意。例如解析出來的數據如下圖所示： ![](https://box.kancloud.cn/2015-11-17_564aa53b37e06.png) zendisk ### Yahoo Case Study: MySQL GTIDs and Parallel or Multithreaded Replication [CON5409] Yashada Jadhav, MySQL DBA, Yahoo Stacy Yuan, Sr. MySQL DBA, Yahoo [PPT鏈接](https://published-rs.lanyonevents.com/published/oracleus2015/sessionsFiles/685/CON5409_Jadhav-Yahoo%20Case%20Study-%20MySQL%20GTIDs%20and%20Parallel%20or%20Multithreaded%20Replication.pdf) 主要講了Yahoo關于GTID的使用，介紹了下復制的相關知識以及如何使用Percona版本的MySQL實現online GTID開啟。沒啥新意，看在難得是妹子的份上聽了一會就閃了。但對這塊不了解的同學可以看看。 ### Database Defense in Depth [CON3554] Geoffrey Anderson, Senior Database Operations Engineer, Box [PPT鏈接](https://published-rs.lanyonevents.com/published/oracleus2015/sessionsFiles/2311/CON3554_Anderson-databaseDefenseInDepth-oow2015_print.pdf) Box公司的DBA闡述了他們如何使用各種工具來解決MySQL遇到的問題，以保證MySQL的正常運行。沒啥新東西。