幹壞事是進步最大的原動力
Oracle 推出的 InnoDB Cluster 進入 GA 了，不過先觀望看看就好：「MySQL InnoDB Cluster GA is Available Now!」。
The GA release of InnoDB Cluster builds upon the great work that the MySQL Development Team has done on Group Replication, filling out the rest of the stack for setup, management, orchestration, and client routing.
算是 Galara Cluster 的競爭對手 (被 Percona 與 MariaDB 採用)，產品成熟度還得再看如何...
在「How eBay’s Shopping Cart used compression techniques to solve network I/O bottlenecks」這邊 eBay 描述了他們怎麼解決在 MongoDB 上遇到的問題，不過我看的是他們怎麼用 MongoDB，而不是這次解決的問題：
It’s easier to think of the MongoDB layer as a “cache” and the Oracle store as the persistent copy. If there’s a cache miss (that is, missing data in MongoDB), the services fall back to recover the data from Oracle and make further downstream calls to recompute the cart.
把 MongoDB 當作 cache layer，當 cache miss 的時候還是會回去底層的 Oracle 撈資料計算，這用法頗有趣的...
不拿 memcached 出來用的原因不知道是為什麼，是要找個有 HA 方案的 cache layer 嗎？還是有針對 JSON document 做判斷操作？
不愧是 Oracle 的 MySQL Community Manager，把對手的 Galera Cluster 講的一無是處 XDDD：「Group Replication is GA with MySQL 5.7.17 – comparison with Galera」。
然後下面 comment 的地方 Mark Callaghan (@Facebook) 出來提 Galera Cluster 架構中 arbitrator 的好處，另外 Sergei Petrunia (@MariaDB) 也出來糾正抹黑對手的 FUD (講 Galera Cluster 的 protocol 是 "proprietary")，不知道還會不會其他人跳進來...
另外文章裡面看起來也怪怪的，像是 Group Replication 在 InnoDB 上的作法真的能解決他說的問題嗎... conflict 把有問題的 transaction 砍掉不是很合理嗎？設計個 high priority transaction 是怎樣...
來繼續觀望看看就好，Galera Cluster 的成熟度還是很高的... 也許等到其他幾家也決定把 Group Replication 放進支援再說吧。
Mark Callaghan 這篇倒是沒提到什麼技術的東西，主要是講最近 MySQL 的兩大 conference，一個是 Oracle 的 Oracle Open World，另外一個是 Percona 的 Percona Live Amsterdam 2016，然後用了 benchmarketing 這個酸酸的詞 XDDD：「Peak benchmarketing season for MySQL」。
裡面有些也很有趣的東西：
My joke is that each of these makes a different group happy: performance -> marketing, usability -> developers, manageability -> operations, availability -> end users, efficiency -> management.
另外提到了 RocksDB 建出來的 MyRocks 在 memory fit 時可能會比 InnoDB 還要好：
One last disclaimer. If you care about read-mostly/in-memory workloads then InnoDB is probably an excellent choice. MyRocks can still be faster than InnoDB for in-memory workloads. That is more likely when the bottleneck for InnoDB is page write-back performance. So write-heavy/in-memory can still be a winner for MyRocks.
這就有趣了，找個時間來測試看看...
MySQL 8.0 是 MySQL 5.7 的後續版本，中間的 6.0 與 7.0 都有一些故事，就被跳過去了，跟 PHP 的情況有點像。
在 8.0 版將會把 performance_schamea 加上 index，讓查詢的速度變快：「MySQL 8.0: Performance Schema, now with indexes!」：
In MySQL 8.0, performance_schema tables are now indexed to speed up data retrieval.
A total of 115 indexes have been added in the performance schema in MySQL 8.0.0, to support better data access patterns in general.
有用過 performance_schema 的人都會有種「這好慢啊」的感覺，總算要改善了... 而且這幾乎是沒什麼成本的改善：
Question: How much overhead was just added by this new feature?
Answer: Absolutely zero
並不是用 index 加快速度，而是加了一些資訊，修正 optimizer 的行為：
It does — not — maintain a physical index internally, be it on file or memory.
It does, however, — pretend — to the optimizer that it has indexes, so that the optimizer is coerced into using the most efficient access pattern.
在有些情況下可以看到會快非常的多：
The performance improvements from indexes can be very easily seen in many of the sys schema queries. With 1000 idle threads, the query
SELECT * FROM sys.sessiondrops from 34.70 seconds down to 1.01 seconds (a 30x improvement!):
不知道 Percona 會不會 backport 回來，這看起來對於爆炸中的 server 找問題會很有幫助，可以在短時間翻出是哪個部份爆炸...
在 Hacker News Daily 上看到 Yandex.Mail 從 Oracle 搬到 PostgreSQL 的故事：「Yandex.Mail success story」。
首先是在 Oracle-based 的系統上遇到的問題：
除了技術類的問題外，這個「Not very responsive support」可以看到對 Oracle 的服務很不滿意。
另外下一張投影片只講 shop.oracle.com 是主要原因... 我猜是 Oracle 在開始提供 cloud service 後把售價都拉高。在最後的 Summary 看起來也有點像：
雖然沒有講明換 PostgreSQL 的理由，但注意到「3x more hardware」這點，這表示是原來的四倍。在這樣的情況下還是要換，可以猜測 Oracle 的授權費用在 web-scale 服務上的問題。
另外如果仔細品投影片，可以發現其實 migration 成功的原因是 DBA team 的能力夠強大，以及充足的時間修正問題 (可以看到作者在 mailing list 上一直提問也一直修正問題)。如果當初評估後決定要換到 MySQL，我相信也是會順利完成...
包含 MySQL 本家與所有從 MySQL 改出去的分支都中了，引用 Percona 的通報：「Percona Server Critical Update CVE-2016-6662」。
This is a CRITICAL update, and the fix mitigates the potential for remote root code execution.
原始的 security advisory 在「CVE-2016-6662 - MySQL Remote Root Code Execution / Privilege Escalation ( 0day )」這邊，雖然是標 0day，但發現的人在七月時就有先通報給 vendor 們讓他們有時間修正：
The vulnerability was reported to Oracle on 29th of July 2016 and triaged by the security team. It was also reported to the other affected vendors including PerconaDB and MariaDB.
Oracle 還沒修正，也就是 upstream 目前仍然是有問題的，目前得靠其他 vendor 修正：
Official patches for the vulnerability are not available at this time for Oracle MySQL server.
其中 Percona 與 MariaDB 都已經先推出修正版本了：
The vulnerabilities were patched by PerconaDB and MariaDB vendors by the end of 30th of August.
然後看了一下這個漏洞，從 SQL 指令可以做檔案操作一路打出來... 可以看到範例：
mysql> set global general_log_file = '/etc/my.cnf';
mysql> set global general_log = on;
mysql> select '
'>
'> ; injected config entry
'>
'> [mysqld]
'> malloc_lib=/tmp/mysql_exploit_lib.so
'>
'> [separator]
'>
'> ';
1 row in set (0.00 sec)
mysql> set global general_log = off;
這下苦了...
這次要提的是「Netflix Billing Migration to AWS」、「Netflix Billing Migration to AWS - Part II」與「Netflix Billing Migration to AWS - Part III」這三篇。
Netflix 先前的金流相關系統跑的是 Oracle 的資料庫：
然後換成 MySQL：
系統上是採用 DRBD，然後底層是 5 個 4TB 的 EBS 組成的 RAID 0，跑 LVM：
High performance with respect to reads and writes was achieved by using RAID0 with EBS provisioned IOPS volumes. To get more throughput per volume, 5 volumes of 4TB each were used, instead of 1 big volume. This was to facilitate faster snapshots and restores.
LVM to manage two Logical Volume’s (DB and DRBD Metadata) within single Volume Group.
可以看到裡面用的都是很經過時間考驗的技術，像是 DRBD、標準的 Replication 架構...
AWS 正式向所有使用者開放「AWS Database Migration Service」了：「AWS Database Migration Service」。
AWS 把前置作業 (setup & initial backup) 與 replication 的部份都包好，讓使用者可以很輕鬆的轉移。
支援的來源資料庫種類包括了這五種：
Supported database sources include: (1) Oracle, (2) SQL Server, (3) MySQL, (4) Amazon Aurora and (5) PostgreSQL. All sources are supported on-premises, in EC2, and RDS except Amazon Aurora which is available only in RDS.
支援的目的資料庫種類也包括了這五種：
Supported database targets include: (1) Amazon Aurora, (2) Oracle, (3) SQL Server, (4) MySQL, and (5) PostgreSQL. All Oracle, SQL Server, MySQL and Postgres targets are supported on-premises, in EC2 and RDS.
所以不只可以搬進 AWS，也透過在 EC2 instance 上架 Proxy 的方式搬出 AWS。比較特別的是可以不同 database 互轉？這好像可以玩玩看...
轉移的機器包括 t2.* 與 c4.* 兩種，一般來說 t2 系列的機器應該夠用，但如果要拼轉移速度的話可以拿 c4 出來撐場面。
在「What to do with optimizer hints after an upgrade?」這邊介紹了 MySQL 5.7 引入的 Rewrite Query Plugin，看起來有很多可以拿來變化的？
作者提到的用法是當 minor version 升級後 (譬如 5.6 升到 5.7)，由於 optimizer 愈來愈聰明，hint 應該都要重新確認是否還需要指定 (像是 USING INDEX)，避免效能反而變差。
但這個前提是你能夠改到程式碼，如果你改不到程式碼就只能祈禱效能不會變差。
而 MySQL 5.7 提供的 Rewrite Query Plugin 則可以改寫 SQL query，像是 Oracle 官方文件裡給的範例：
mysql> SELECT * FROM query_rewrite.rewrite_rules\G
*************************** 1. row ***************************
id: 1
pattern: SELECT ?
pattern_database: NULL
replacement: SELECT ? + 1
enabled: YES
message: NULL
pattern_digest: 46b876e64cd5c41009d91c754921f1d4
normalized_pattern: select ?
就會把 SELECT 1 變成 SELECT 1 + 1。實際測試會發現檢查的很嚴格，用 PI() 不會變：
mysql> SELECT PI(); +----------+ | PI() | +----------+ | 3.141593 | +----------+ 1 row in set (0.01 sec) mysql> SELECT 10; +--------+ | 10 + 1 | +--------+ | 11 | +--------+ 1 row in set, 1 warning (0.00 sec)
目前好像只想的到 hint 可以這樣做，反正還一堆都跑 5.6 (這兩天 Percona 才出 5.7 的 GA)，可以邊規劃升級，邊想看看有什麼情境可以用的...