幹壞事是進步最大的原動力
在「Migrating from Oracle to PostgreSQL: Tips and Tricks」這邊看到在討論怎麼從 Oracle 資料庫轉移到 PostgreSQL 上。
開頭介紹了 Orafce，實做了一些 Oracle 上的 function，可以使得轉移時不用改寫太多 SQL：
The "orafce" project implements of some functions from the Oracle database. The functionality was verified on Oracle 10g, and the module is useful for production work.
先記錄起來，之後如果有機會的話比較好找...
看到 Ubuntu 在安裝時支援 ZFS 的消息：「A detailed look at Ubuntu’s new experimental ZFS installer」。另外 Twitter 上也有截圖了：
Thanks to the work from @didrocks and Jean Baptiste ? a number of the #ubuntu flavours now have the experimental ZFS ? install option available in 19.10 ? pic.twitter.com/Aux8iCri4p
— Martin Wimpress (@m_wimpress) October 8, 2019
看了一下授權問題，看起來是 Ubuntu 認定這樣做不會有問題，但目前還沒被 Oracle 出手，所以也不曉得真的出手後會發生什麼事情...
算是 AWS 的 PR 稿，在老闆對雲的宣示與政治正確下本來就會陸陸續續轉過去...
這次是 Amazon 的 Consumer Business 從 Oracle 的系統換到 AWS 自己的系統：「Migration Complete – Amazon’s Consumer Business Just Turned off its Final Oracle Database」。
原先有 75 PB 的資料與 7500 個 database：
We migrated 75 petabytes of internal data stored in nearly 7,500 Oracle databases to multiple AWS database services including Amazon DynamoDB, Amazon Aurora, Amazon Relational Database Service (RDS), and Amazon Redshift.
其中一個優點是省成本，但是也投入了超過一百個團隊一起參與轉移，會需要攤多久才會打平，這點在沒有看到內部財務資料其實沒辦法判斷，而且工程資源的稀缺性也是個沒有被看到的資訊：
Cost Reduction – We reduced our database costs by over 60% on top of the heavily discounted rate we negotiated based on our scale. Customers regularly report cost savings of 90% by switching from Oracle to AWS.
More than 100 teams in Amazon’s Consumer business participated in the migration effort.
然後 latency 的下降其實也只能參考，因為轉移系統的時候也會順便改寫，有多少是因為 AWS 服務本身帶出來，在沒有內部資料看不出來：
Performance Improvements – Latency of our consumer-facing applications was reduced by 40%.
管理成本算是裡面唯一可以參考的，畢竟是搬到可延展擴充的服務：
Administrative Overhead – The switch to managed services reduced database admin overhead by 70%.
另外，沒寫的東西比較有趣，像是他們沒有選擇 Athena 而是用 Redshift，看起來像是先轉上去，其他找機會再說...
看到這則 tweet，提到 Java 的支援度：
We've released version 2.0.0 of Java Is Still Free (https://t.co/VvAPtBYE1C) - giving you a full and balanced view of the #java and #openjdk choices you have going forwards, including commercial support, $free and free to use - read it today!
— Java Champions (@Java_Champions) March 3, 2019
主要是裡面有張圖列出了目前市場上有的選擇，可以當關鍵字來查：
目前看起來如果要 Java 8 只有三個方案，其中有過 TCK 的只有兩個，看起來用 Amazon Corretto 算是個還不錯的選擇？
Percona 在過節前推出 Percona Server for MySQL 8.0 了：「Announcing General Availability of Percona Server for MySQL 8.0」。
在 Oracle 版的 MySQL 8.0 多了不少功能，像是往 NoSQL 靠的功能與 GIS 相關的功能，但讓我注意到的是 Percona 自己的事情... TokuDB 因為 MyRocks 而要被放生了：
Features Being Deprecated in Percona Server for MySQL 8.0
TokuDB Storage Engine: TokuDB will be supported throughout the Percona Server for MySQL 8.0 release series, but will not be available in the next major release. Percona encourages TokuDB users to explore the MyRocks Storage Engine which provides similar benefits for the majority of workloads and has better optimized support for modern hardware.
在 Hacker News Daily 上看到「VirtualBox E1000 Guest-to-Host Escape」這篇，講 VirtualBox 5.2 的機器上 E1000 + NAT 模式的爆破... 另外在 Hacker News 上的討論也提到了很多這樣做的背景：「VirtualBox E1000 Guest-to-Host Escape | Hacker News」。
Oracle 對社群的態度 (無論是 open source community 或是 security community) 都一直是社群很不爽的事情。
這次爆破的發現人之前找到一個 VirtualBox 的 security bug (參考「SSD Advisory – VirtualBox VRDP Guest-to-Host Escape」)，回報後先是回應他們在處理中，然後被發現 VirtualBox 在 5.2.18 修掉了，但是完全沒有提到安全性問題的事情。所以這次作者也懶得囉唆了，找到就 full disclosure 出來。
作者給的 workaround 有兩個，優先建議暫時先用 PCnet 系列的界面，如果不行的話，至少不要用 NAT。
作者發表後沒多久馬上就有 5.2.22 推出，不過看 changelog 應該是沒有修正這個問題？(或是修掉又沒提...)
Percona 的 CTO Vadim Tkachenko 在比較 InnoDB 與 MyRocks 時意外發現了 binlog 會影響不少效能穩定性，再加上 MySQL 8.0 有改變 binlog 相關的預設值，所以他後續花了不少時間測試，寫了兩篇關於 binlog 對於 MySQL 效能的影響：「How Binary Logs (and Filesystems) Affect MySQL Performance」與「How Binary Logs Affect MySQL 8.0 Performance」。
第一篇是想要知道在 Percona Server 5.7 上開 binlog 的影響，做出來後可以看到明顯的效能波動 (因為 binlog 導致 flush 時效能暴跌)：
而其中的 workaround 就是調整 flush 參數，讓他比較頻繁的小量寫入，而不是突然要寫很多資料。這樣一來對平均效能也許比較差，但對前端應用衝擊會比較小：
在測試可以看到 sync_binlog=1000 是個妥協點。各單位要自己去找出適合的數字：
The strict setting also comes with noted performance penalties. I will also test sync_binlog=1000 and sync_binlog=10000, which means perform synchronous writes of binary logs every 1000 and 10000 transactions, respectively.
另外有測試 ext4 與 XFS 是否有影響，就測試的結果看起來 ext4 比 XFS 好一些，但差距有限：
第二篇則是拿 MySQL 8.0 與 Percona Server 5.7 比較，可以發現在 MySQL 8.0 開啟 binlog 時有時會有不少的效能損失：
It seems that binary logs have quite an effect MySQL 8.0, and we see up to a 30% performance penalty as opposed to the 13% for Percona Server for MySQL 5.7.
雖是推銷一下自家產品在這塊還不錯 XD
Twitter 上看到 Oracle 計畫在 MySQL 內包入 GraalVM：
Wooooow ! Stored programs in @MySQL in different languages thanks to @graalvm #perconalive pic.twitter.com/NTDa3vHLyn
— lefred (@lefred) April 25, 2018
#MySQL MLE [ˈɛmɪlɪ] @graalvm in @MySQL 8.0 #perconalive pic.twitter.com/PVNrcbJL8q
— lefred (@lefred) April 25, 2018
這能不能解決 MySQL 的 stored procedure 一直以來都很殘的問題就要多花些時間看看了... 另外 GraalVM 用 GPLv2，但沒有明確的專利授權條款也是大家很在意的問題 (參考 Hacker News 上「GraalVM: Run Programs Faster Anywhere | Hacker News」這邊的討論)，因為大家都很清楚，這家公司只要是沒有授權的東西就不要碰...
話說 Percona 都把 PostgreSQL 包進來吃了，來考慮多用用 PostgreSQL 好了... (把 blog 換掉？)
Oracle 推出了 MySQL 8.0 (GA，General Availability)：「MySQL 8.0 – Announcing GA of the MySQL Document Store」。在「What’s New in MySQL 8.0? (Generally Available)」這邊也花了一些篇幅介紹 MySQL 8.0 的新功能。
比較感興趣的是：
不過就實用性來說，效能的提昇還是最直接的... 接下來等 Percona 的人 porting 了。
Percona 介紹了 MySQL 8.0 將會推出的 innodb_dedicated_server 參數：「New MySQL 8.0 innodb_dedicated_server Variable Optimizes InnoDB from the Get-Go」，Oracle 官方的文件在「15.6.13 Enabling Automatic Configuration for a Dedicated MySQL Server」這邊可以翻到。
這是針對整台機器完全給 MySQL 用的情況所設計的參數。在這種情況下，可以透過 RAM 的大小以及一些簡單的公式，得到還算堪用的系統參數...
依照說明，可以看到系統會依照記憶體的大小自動計算出 innodb_buffer_pool_size、innodb_log_file_size 這兩個參數，並且把 innodb_flush_method 設為 O_DIRECT_NO_FSYNC (如果所在平台有支援這個值)。
不過看了一下公式，依照經驗可以設的更積極一點... 像是 Percona 文章裡提到的，當記憶體夠大時，其實可以考慮從 80% 開始調整大小 (innodb_buffer_pool_size)：
For InnoDB buffer pool size (based on this article), consider allocating 80% of physical RAM for starters. You can increase it to as large as needed and possible, as long as the system doesn’t swap on the production workload.
而 innodb_log_file_size 則應該要分析寫入的 pattern 而不是直接看 RAM 大小。有些機器雖然很大台但幾乎沒有寫入的量，照著公式的值就偏大很多：
For InnoDB log file size, it should be able to handle one hour of writes to allow InnoDB to optimize writing the redo log to disk. You can calculate an estimate by following the steps here, which samples one minute worth of writes to the redo log. You could also get a better estimate from hourly log file usage with Percona Monitoring and Management (PMM) graphs.
不過基本上 tune 出來的值還算堪用，對於剛入手的人頗有幫助。