MySQL 8.0 正式推出 (GA,General Availability)

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 的新功能。

比較感興趣的是:

  • Descending Indexes
  • Information Schema (speed up)
  • Performance Schema (speed up)
  • INVISIBLE Indexes
  • Scaling Read/Write Workloads
  • Utilizing IO Capacity (Fast Storage)
  • Better Performance upon High Contention Loads (“hot rows”)

不過就實用性來說,效能的提昇還是最直接的... 接下來等 Percona 的人 porting 了。

AWS 在東京開第四個 AZ

Twitter 上看到 Jeff Barr 的說明:

居然默默地開了第四個 AZ 了... 不過大阪什麼時候要開放啊,以機房成本以及電力成本應該都會比東京低的前提下,不知道公告價錢會不會比較低...

Percona Server 引入 MyRocks

看到「MyRocks Engine: Things to Know Before You Start」這篇,才發現原來一月的時候 Percona Server 就已經將 MyRocks GA (General Availability) 了:「Percona Server for MySQL 5.7.20-19 Is Now Available」。

New Features:
Now MyRocks Storage Engine has General Availability status.

在二月這篇文章裡面有提到一些重點,像是安裝方式:

Now if you use Percona repositories, you can simply install MyRocks plugin and enable it with ps-admin --enable-rocksdb.

另外文章裡也提到了重要的差異 (在「What other differences should you be aware of?」這段),像是他並不是每個 table 都一個檔案,而是像早期 InnoDB 的作法,整個一包:

Let’s look at the directory layout. Right now, all tables and all databases are stored in a hidden .rocksdb directory inside mysqldir. The name and location can be changed, but still all tables from all databases are stored in just a series of .sst files. There is no per-table / per-database separation.

另外提到可以看到 Engine 的代碼是 ROCKSDB (從 ENGINE=ROCKSDB 那段看到的)。然後是 Isolation level 的支援度,只有 READ-COMMITTEDSERIALIZABLE,沒有 REPEATABLE-READ

Keep in mind that at this time MyRocks supports only READ-COMMITTED and SERIALIZABLE isolation levels. There is no REPEATABLE-READ isolation level and no gap locking like in InnoDB. In theory, RocksDB should support SNAPSHOT isolation level. However, there is no notion of SNAPSHOT isolation in MySQL so we have not implemented the special syntax to support this level. Please let us know if you would be interested in this.

然後 bulk load 在資料量超過記憶體大小時會有已知的 crash 問題:

For bulk loads, you may face problems trying to load large amounts of data into MyRocks (and unfortunately this might be the very first operation when you start playing with MyRocks as you try to LOAD DATA, INSERT INTO myrocks_table SELECT * FROM innodb_table or ALTER TABLE innodb_table ENGINE=ROCKSDB). If your table is big enough and you do not have enough memory, RocksDB crashes. As a workaround, you should set rocksdb_bulk_load=1 for the session where you load data.

然後目前沒有像 XtraBackup 的工具可以用,現階段如果要備份的話得透過傳統的方式來做 (mysqldump 或是 filesystem snapshot):

Right now there is no hot backup software like Percona XtraBackup to perform a hot backup of MyRocks tables (we are looking into this). At this time you can use mysqldump for logical backups, or use filesystem-level snapshots like LVM or ZFS.

想來找機會測試看看兩者差異...

Cloudflare 新推出的 Geo Key Manager

Cloudflare 對新推出的 Geo Key Manager 寫了兩篇文章說明:「Introducing the Cloudflare Geo Key Manager」、「Geo Key Manager: How It Works」。

這個服務是之前推出的 Keyless SSL 的延伸應用。

Keyless SSL 是將 Private Key 放在自己家,透過加密協定讓 Cloudflare 使用 (有點像是 HSM 的概念,也就是 Hardware security module,不讓應用的人存取到 Private Key)。這次推出的 Geo Key Manager 則是取中間值,希望針對效率與 High Availability 做出改善。

改善的方法還是將 Private Key 上傳到 Cloudflare 裡,但不是 Cloudflare 所有的機房,而是讓使用者挑選某些風險比較低的地區。

像是只放在美國,或是只放在歐盟,或是以安全度來選擇:

這其實是不信任政府單位而設計出來的系統,雖然效果如何還不知道...

AWS 的 us-east-1 開放第六個 AZ

AWSus-east-1 上次加第五個 AZ 不知道是什麼時候了,找資料找不太到... 這次宣佈加第六個 AZ 進去了:「Sixth AZ in US East (N. Virginia) Region」。

依照 AWS 之前有提出來的架構,所有 AZ 之間都是有互向連接的... 所以 us-east-1 加 AZ 都會比其他區域辛苦不少...

Lambda@Edge 的 GA

AWSLambda@Edge 宣佈 GA 了:「Lambda@Edge – Intelligent Processing of HTTP Requests at the Edge」。

最直接的應用就是在 CloudFront 的 edge 上執行一小段 code,修改 HTTP request 或是 HTTP response 了,不過可以看到一些限制:

不過要用來解哪些問題要再想一下...

MySQL 上 Replication 的方案

Percona 的人整理了一篇關於 Replication 的方案 (以及 NDB,不過這邊就先偷偷跳過去...),雖然標題寫的是 High Availability:「The MySQL High Availability Landscape in 2017 (The Elders)」。

先講他給的另外兩個方案,一個是 Shared Storage,另外一個是 NDB。

其中 Shared Storage 其實在儲存空間端還是有單點失效的問題,而 NDB 的特性跟 InnoDB 不同,有很多概念要重新學... 如果就這三個比較,常見的還是第一個提到的 Replication。

其實把 Replication 用熟的話已經可以解決不少問題了 (不論是早期的 MMM,或是 MHA)。而且因為技術已經發展很久了,大家幾乎都很熟特性 (以及 bug XD),網路上可以找到不少資料,甚至 Percona 也都能夠支援 (當你願意付錢的時候 XDDD)。

Amazon EC2 的 F1 type 開放一般使用

AWS 提供更快計算 Bitcoin 的 FPGA 機種開放一般使用了:「Amazon EC2 F1 Instances, Customizable FPGAs for Hardware Acceleration Are Now Generally Available」。

在 AWS 開始提供服務後,應該會有更多 library 支援吧... 現在現有的應用要上去還得自己先刻些東西,不像 TensorFlow 可以透過 GPU 運算。

F1 instances include the latest 16 nm Xilinx UltraScale Plus FPGA with local 64 GiB DDR4 ECC protected memory, with a dedicated PCI-e x16 connection to the instance. For F1.16xlarge instances, the dedicated PCI-e fabric lets the FPGAs share the same memory space and communicate with each other across the fabric at up to 12 GBps in each direction. The FPGAs within the F1.16xlarge share access to a 400 Gbps bidirectional ring for low-latency, high bandwidth communication.

Oracle 官方的 InnoDB Cluster 出 GA 了...

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 的競爭對手 (被 PerconaMariaDB 採用),產品成熟度還得再看如何...

Google 的 Cloud Spanner

GoogleCloud Spanner 這個服務拿出來賣了:「Introducing Cloud Spanner: a global database service for mission-critical applications」,以及說明的「Inside Cloud Spanner and the CAP Theorem」。

Cloud Spanner 的規劃上是希望有 RDBMS 的能力 (像是 ACID 特性),又有強大的擴充能力 (scalability) 與可用性 (availability):

Today, we’re excited to announce the public beta for Cloud Spanner, a globally distributed relational database service that lets customers have their cake and eat it too: ACID transactions and SQL semantics, without giving up horizontal scaling and high availability.

在說明裡有提到 Cloud Spanner 是做到 CAP theorem 裡面的 CP:

The purist answer is “no” because partitions can happen and in fact have happened at Google, and during some partitions, Spanner chooses C and forfeits A. It is technically a CP system.

然後把 A 拉高到使用者不會在意 downtime 的程度:

However, no system provides 100% availability, so the pragmatic question is whether or not Spanner delivers availability that is so high that most users don't worry about its outages.

當然,比較讓人爭議的是 Twitter 上 Google Cloud 官方帳號的 tweet,直接講同時解決了 CAP 三個條件:

價錢不算便宜,不過對於想要找方案的人至少有選擇...