Tag: async

Amazon Aurora (MySQL) 的 Stored Procedure 可以跑 AWS Lambda...

查了資料才發現去年十月 Amazon Aurora (MySQL-Compatible Edition) 就支援用 AWS Lambda 當 stored procedure 了，只是當時只支援 async mode，能做的事情比較有限：「Amazon Aurora New Features: AWS Lambda Integration and Data Load from Amazon S3 to Aurora Tables」。

Now you can invoke Lambda functions directly from within an Aurora database via stored procedures or user-defined functions. Lambda integration allows you to extend the capabilities of the database and invoke external applications to act upon data changes. For example, you can create a Lambda function that sends emails to customers whenever their address in the database is updated.

前幾天發表的則是支援 sync mode，可以等到：「Amazon Aurora with MySQL Compatibility Natively Supports Synchronous Invocation of AWS Lambda Functions」。

Starting with version 1.16, we are extending this feature to be able to able to synchronously invoke Lambda functions.

Use the native function lambda_sync when you must know the result of the execution before moving on to another action.

這解掉了 MySQL 的 stored procedure 一直很殘的問題...

Amazon DynamoDB 跨區 Replication 以及備份

Amazon DynamoDB 實做了全球性的 replication，以及備份功能：「Amazon DynamoDB Update – Global Tables and On-Demand Backup」。

跨區 replication 的功能讓每個 region 都可以存取當地機房的 DynamoDB：

Global Tables – You can now create tables that are automatically replicated across two or more AWS Regions, with full support for multi-master writes, with a couple of clicks. This gives you the ability to build fast, massively scaled applications for a global user base without having to manage the replication process.

這有點類似 Google 的 Cloud Spanner 在前陣子也推出全球性服務，但 DynamoDB 提供的比較偏向 NoSQL 而不是 RDBMS。

另外一個限制是跨區同步是 async，會有 replication lag 的問題：

Updates are propagated to other Regions asynchronously via DynamoDB Streams and are typically complete within one second (you can track this using the new ReplicationLatency and PendingReplicationCount metrics).

不過如果是這樣的機制，conflict 的問題不知道怎麼解決... 文章裡面沒看到。

然後目前支援的區域還是有限：

Global Tables are available in the US East (Ohio), US East (N. Virginia), US West (Oregon), EU (Ireland), and EU (Frankfurt) Regions today, with more Regions in the works for 2018.

另外一個是備份與還原機制，有這樣的功能對很多計畫方便不少：

On-Demand Backup – You can now create full backups of your DynamoDB tables with a single click, and with zero impact on performance or availability. Your application remains online and runs at full speed. Backups are suitable for long-term retention and archival, and can help you to comply with regulatory requirements.

而備份還原機制是陸陸續續開放的，區域也有限：

We are rolling this new feature out on an account-by-account basis as quickly as possible, with initial availability in the US East (Northern Virginia), US East (Ohio), US West (Oregon), and EU (Ireland) Regions.

Node.js 第一個 8.x LTS 推出

推出啦：「Node v8.9.0 (LTS)」，另外可以看「NEWS: Node.js 8 Moves into Long-Term Support and Node.js 9 Becomes the New Current Release Line」這篇。

從 6 到 8 多了 async & await (ES7)，應該會是對整個生態系改變最大的功能了，可以預期會有一堆人濫用... XD

剛剛測 n 的 lts 參數發現還沒更新，先用 n 8.9.0 換上去...

Amazon Aurora (MySQL) 推出的 Asynchronous Key Prefetch

Amazon Aurora (MySQL) 推出新的效能改善，可以改善 JOIN 時的效能：「Amazon Aurora (MySQL) Speeds Join Queries by More than 10x with Asynchronous Key Prefetch」。

看起來像是某個情況的 optimization，將可能的 random access 換成 sequential access 而得到大量的效能：

This feature applies to queries that require use of the Batched Key Access (BKA) join algorithm and Multi-Range Read (MRR) optimization, and improves performance when the underlying data set is not in the main memory buffer pool or query cache.

其實記憶體還是最好用的加速器，能加大硬拼就先硬拼... XD

MySQL 5.7 的 Pipeline 查詢加速

在「MySQL 5.7.12 – Part 2: Improving the MySQL Protocol」這邊看到介紹 MySQL 的 Asynchronous API，藉由 pipeline 加速查詢。

本來的：

res_1 = conn.query("DO 1");
res_2 = conn.query("DO 2");

會產生這樣的 flow：

而 Asynchronous API 可以這樣寫，先把兩個 SQL query 都丟出去，然後等結果：

hndl_1 = conn.query_send("DO 1");
hndl_2 = conn.query_send("DO 2");

# wait for completion
res_1 = conn.query_recv(hndl_1);
res_2 = conn.query_recv(hndl_2);

也就是產生這樣的 flow：

感覺 PHP 上只要 PDO 改善這塊後，各家 ORM library 就可以支援受益...

Facebook 的 InnoDB patch 讓 table scan 速度變快...

Facebook 的 Database Engineering team 實作了 patch，讓 InnoDB 在 table scan 的速度大幅提昇：「Making full table scan 10x faster in InnoDB」。

第一個 patch 叫做 Logical Readahead。第二個 patch 是針對 async i/o 的改善 (Submitting multiple async I/O requests at once)。

引用文章內的幾段話就知道這幾個 patch 的功力了：

Logical backup size is much smaller. 3x-10x size difference is not uncommon.

備份出來的資料會變小，而且宣稱 1/3 到 1/10 不是罕見情況... -_-

With logical readahead, our full table scan speed improved 9~10 times than before under usual production workloads. Under heavy production workloads, full table scan speed became 15~20 times faster.

然後 table scan 的速度會快非常多... 10 倍？如果是平常就很操的 database 會更明顯？

如果這幾個 patch 如果沒有什麼問題，可以預期會被 merge 到 Percona 與 MariaDB，至於 Oracle 官方的 source tree... 有的話當然很好，沒有的話也很正常？

jQuery 1.11 Beta 1 與 2.1 Beta 1...

特地寫是因為 jQuery 1.11 將會是第一個完整切換到 AMD (Asynchronous Module Definition) 架構的版本：「jQuery 1.11 and 2.1 Beta 1 Released」。

雖然對 AMD 並不是全正面的看法，不過畢竟是一個通用的標準...

Percona 的 Crash-resistant replication

前幾天 Percona 寫了篇文章說明自家專有的 Crash-resistant replication (用在 Percona Server 5.1 與 5.5)：「Crash-resistant replication: How to avoid MySQL replication errors」。

這是 async replication 用在 slave server crash 時的保護機制。

當 slave 更新資料後，會更新 relay log 寫下「目前 apply 到哪個位置」(預設值是 relay-log.info)，也就可以依照這個資訊計算出 replication lag 的時間。在 mytop 裡看到的 Delay 欄位就是由此算出來的。

但當 MySQL 寫入後，但 relay-log.info 還沒更新時當掉，會造成下次啟動時重複 apply 同一筆資料。

而 Crash-resistant replication 就是把這個資訊寫到 transaction 內，避免這個問題。

也因此這個功能只有 InnoDB 類的 Engine 才有用，MyISAM 仍然是不受 Crash-resistant replication 保護的。

要打開這個功能也很簡單，只要 my.cnf 設起來就好了，設定說明可以參考原文。

在 Percona XtraDB Cluster 裡使用 async replication 時人工 failover 的方式...

在使用 Galera Cluster 時還是可以架設一般的 slave server (Percona XtraDB Cluster 則是 Percona 對 Galera Cluster 的封裝)，像是這樣的架構：

其中 node{1,2} 為 cluster，node3 則是傳統的 async replication，來源的 master 為 node1。

當 node1 掛掉時，我們沒辦法自動將 node3 的 master 從 node1 改指到 node2，因為 binlog 的位置不一定正確。

在「Changing an async slave of a PXC cluster to a new Master」則是提供如何人工用最簡單的方式介入。

主要是靠 Galera Cluster 會在 binlog 內寫入 Xid 這個值，這個值可以在 global status 內的 wsrep_last_committed 看到。因為這個值在全 cluster 都是同步的，就可以拿來人工尋找 binlog 位置後手動下 CHANGE MASTER TO，而不用 pt-table-sync 同步修老半天...

而且邏輯被整理出來以後，就有機會寫成程式自動化... 這算是一個不錯的開頭 :p