table

PostgreSQL 的 Logical Replication 還有很多限制...

雖然之前提過很多次 PostgreSQL 的 logical replication，但最近總算是有空實際架設起來測試，發現目前的 logical replication 還在進化的過程，只能算是階段性的產品。

在 PostgreSQL 16 的「31.6. Restrictions」裡面有列出了目前 logical replication 的限制。

第一條其實是最痛的，不支援各種 DDL 操作，所以像是 CREATE TABLE 或是 ALTER TABLE 都不會同步，這牽扯到 DBOps 的動作需要配合，DB schema 的改變會變得很詭異，需要 case by case 處理，甚至 application 端可能也會需要配合。

The database schema and DDL commands are not replicated.

另外一個頭痛的點是 sequence 資料居然不會同步，這個工具常被用到 SERIAL 類的設計 (雖然 SERIAL 被 deprecated 了)，這代表當偵測到 master 掛掉時無法直接 failover，除非有另外處理 sequence 的資料：

Sequence data is not replicated.

翻了資料發現官方 wiki 上有「Logical replication of DDLs」，裡面有今年六月的投影片：「Logical Replication of DDLs」，看起來 DDL 的部分有已經 patch 丟出來 (對 PostgreSQL 15 的 patch)，但看了 PostgreSQL 16 的 release notes 裡面還沒看到，看起來還要等...

所以 logical replication 看起來還在演進的過程，目前的限制使得 logical replication 還不到能用的成熟度。

可以繼續觀察看看...

Route 53 支援 DNS64，以及 NAT Gateway 支援 NAT64

AWS 宣佈了一套機制，讓 IPv6-only 的機器可以連到 IPv4-only 的服務：「Let Your IPv6-only Workloads Connect to IPv4 Services」。

首先是 DNS64，針對只有 IPv4-only 的 A record 自動加上 AAAA record (如果已經有 AAAA record 的則不變)，這邊提到的 64:ff9b::/96 是來自 DNS64 標準內的規範：

The DNS resolver first checks if the record contains an IPv6 address (AAAA record). If it does, the IPv6 address is returned. The IPv6 host can connect to the service using just IPv6. When the record only contains an IPv4 address, the Route 53 resolver synthesizes an IPv6 address by prepending the well-known 64:ff9b::/96 prefix to the IPv4 address.

再來就是 NAT Gateway 可以把 64:ff9b::/96 透過 NAT64 轉到 IPv4 network 上：

You may configure subnet routing to send all packets starting with 64:ff9b::/96 to the NAT gateway. The NAT gateway recognizes the IPv6 address prefix, extracts the IPv4 address from it, and initiates an IPv4 connection to the destination. As usual, the source IPv4 address is the IPv4 address of the NAT gateway itself.

由於有些 protocol 會帶 IP address 資訊，所以不能保證 NAT64 一定會動，但大多數的情況應該是可以解決，至少提供了 IPv6-only server 連到 IPv4-only network 上的方法...

AWS 增加 CloudFront 的 AWS-managed prefix list 讓管理者使用

看到 AWS 公告提供 CloudFront 的 origin subnet 資訊 (AWS-managed prefix list) 讓管理者可以用：「Amazon VPC now supports an AWS-managed prefix list for Amazon CloudFront」。

以往會自己去「AWS IP address ranges」這邊提供的 JSON 檔案定時撈出來再丟到 managed prefix list 裡面，這次的功能等於是 AWS 自己管理這個 prefix list 讓管理者使用。

馬上想的到的用途就是 HTTP/HTTPS port 了，只開放給 CloudFront 的伺服器存取：

Starting today, you can use the AWS managed prefix list for Amazon CloudFront to limit the inbound HTTP/HTTPS traffic to your origins from only the IP addresses that belong to CloudFront’s origin-facing servers. CloudFront keeps the managed prefix list up-to-date with the IP addresses of CloudFront’s origin-facing servers, so you no longer have to maintain a prefix list yourself.

要注意的是這不應該當作唯一的 ACL 手段，因為其他人也可以建立 CloudFront distribution 來穿透打進你的 origin server。

另外有個比較特別的地方，這個 prefix list 的權重很重，使用他會算 55 條 rule 的量，在 security group 內很容易撞到 60 條的限制，在 route table 裡面則是直接撞到 50 條的限制；不過這兩個限制都可以跟 AWS 申請調昇：

The Amazon CloudFront managed prefix list weight is unique in how it affects Amazon VPC quotas:

It counts as 55 rules in a security group. The default quota is 60 rules, leaving room for only 5 additional rules in a security group. You can request a quota increase for this quota.

It counts as 55 routes in a route table. The default quota is 50 routes, so you must request a quota increase before you can add the prefix list to a route table.

如果 HTTP 一條，HTTPS 也一條，那就會算 110 rules 了，有暴力的感覺...

SQLite 3.37.0 以及 STRICT table 的設計

在 Hacker News 首頁上看到「SQLite Release 3.37.0 (sqlite.org)」，原文在「SQLite Release 3.37.0 On 2021-11-27」這邊。

這個版本引入了 STRICT Tables，先前在「SQLite 目前在規劃的 Strict Table，以及我從來不知道原來可以這樣惡搞...」這邊有提過。

官方給出來的範例是這樣，如果沒有要求 STRICT 的話，可以看到各種變化：

CREATE TABLE t1(a ANY);
INSERT INTO t1 VALUES('000123');
SELECT typeof(a), quote(a) FROM t1;
-- result: integer 123

加上 STRICT 後就會與「預期」的結果比較接近：

CREATE TABLE t1(a ANY) STRICT;
INSERT INTO t1 VALUES('000123');
SELECT typeof(a), quote(a) FROM t1;
-- result: text '000123'

對於希望 database 在處理資料嚴謹一點的人來說，應該是個不錯的新功能，但畢竟不是預設值，對於剛跨進來用的人應該還是有中獎機會 XD

用 PostgreSQL 的 int4range 與 GiST

發現自己根本還不熟悉 PostgreSQL 的特性，寫一下記錄起來。

產品上常常會有 coupon 與 voucher 之類的設計，這時候通常都會設定 coupon 或 voucher 的有效期間，在 MySQL 的環境下可能會這樣設計：

CREATE TABLE coupon (
  id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
  code VARCHAR(255) NOT NULL,
  started_at INT UNSIGNED NOT NULL,
  ended_at INT UNSIGNED NOT NULL
);

另外是設計 index 的部份，在產品推出夠久後，通常是過期的 coupon 或 voucher 會比目前還有效的多，而還沒生效的 coupon 與 voucher 通常都不多，所以會設計成對 ended_at 放一組 B-tree index：

CREATE INDEX ON t1 (ended_at);

這個設計不算差，不過用了一些假設。

如果不想要用這些假設，可以改用 Spatial 的資料型態去模擬並且加上 index (使用到 LineString Class)，這樣就直接對 a < x < b 這類查詢更有效率，不過缺點就是可讀性會比較差。

在 PostgreSQL 這邊就有更清晰的資料結構來處理這些事情，主要是有一般性的 int4range 與 int8range 以及時間類的 tsrange、tstzrange 與 daterange (參考「Range Types」這邊有更多資料型態)，所以會變成：

CREATE TABLE coupon (
  id INT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
  code VARCHAR NOT NULL,
  active_at INT4RANGE NOT NULL
);

然後用 GIST 建立 index：

CREATE INDEX ON t1 USING GIST(active_at);

後續的 query 語法就用 <@ 的語法：

SELECT COUNT(*) FROM coupon WHERE 10000 <@ active_at;

塞了 10M 筆資料後的 table 可以看到本來需要的時間是：

Time: 779.542 ms

變成：

Time: 5.510 ms

不過缺點就是 SQLite 沒支援這些資料型態，對於 test case 就一定得跑個 PostgreSQL 起來測...

MySQL InnoDB 的 OPTIMIZE TABLE 的 Lock

在 Backend Tw 的 https://www.facebook.com/groups/616369245163622/posts/2467225396744655/ 這邊看到：

先大概回答一下假設，DELETE 後的空間是可以被同一個表格重複使用的，所以應該是還好，不過離峰時間跑一下 OPTIMIZE TABLE 也沒什麼關係就是了。

裡面提到的「13.7.2.4 OPTIMIZE TABLE Statement」(MySQL 5.7 文件) 以及「13.7.2.4 OPTIMIZE TABLE Statement」(MySQL 5.6 文件) 都有講到目前比較新的版本都已經是 Online DDL 了：(這邊抓 5.6 的文件，有支援的版本資訊)

Prior to Mysql 5.6.17, OPTIMIZE TABLE does not use online DDL. Consequently, concurrent DML (INSERT, UPDATE, DELETE) is not permitted on a table while OPTIMIZE TABLE is running, and secondary indexes are not created as efficiently.

As of MySQL 5.6.17, OPTIMIZE TABLE uses online DDL for regular and partitioned InnoDB tables, which reduces downtime for concurrent DML operations. The table rebuild triggered by OPTIMIZE TABLE is completed in place. An exclusive table lock is only taken briefly during the prepare phase and the commit phase of the operation. During the prepare phase, metadata is updated and an intermediate table is created. During the commit phase, table metadata changes are committed.

文件上有提到會有一小段 lock 的時間，不過一般來說應該不會造成太大問題。

這邊要講的是早期的經典工具 pt-online-schema-change (pt-osc)，這是使用 TRIGGER-based 的方式在跑，他的範例就直接提供了一個不需要 Online DDL 支援的版本：

Change sakila.actor to InnoDB, effectively performing OPTIMIZE TABLE in a non-blocking fashion because it is already an InnoDB table:
pt-online-schema-change --alter "ENGINE=InnoDB" D=sakila,t=actor

這在早期的時候還蠻常被拿出來用的，如果還在維護一些舊系統的話還蠻推薦的...

SQLite 目前在規劃的 Strict Table，以及我從來不知道原來可以這樣惡搞...

在 Hacker News Daily 上看到「STRICT Tables」這篇，在講 SQLite 目前在規劃 strict table，對應的討論可以參考「Strict Tables – Column type constraints in SQLite - Draft (sqlite.org)」這邊。

我在 draft 文件開頭看到這個驚人的事實：轉型失敗的時候會直接寫進去，不是錯誤或是 0 或是 NULL 之類的值 XDDD

For example, if a table column has a type of "INTEGER", then SQLite tries to convert anything inserted into that column into an integer. So an attempt to insert the string '123' results in an integer 123 being inserted. But if the content cannot be losslessly converted into an integer, for example if the input is 'xyz', then the original string is inserted instead. See the Datatypes In SQLite document for additional information.

實際上測試建了一個表格測試：

SQLite version 3.31.1 2020-01-27 19:55:54
Enter ".help" for usage hints.
sqlite> CREATE TABLE a (id INTEGER PRIMARY KEY NOT NULL, col1 INTEGER);
sqlite> INSERT INTO a (id, col1) VALUES (1, 'a');
sqlite> SELECT * FROM a;
id          col1      
----------  ----------
1           a

我果然跟 SQLite 不熟...

Amazon VPC 允許直接把整個網段配到某台 EC2 Instance 上了

看到「Amazon Virtual Private Cloud (VPC) customers can now assign IP prefixes to their EC2 instances」這邊的消息，VPC 可以把整個網段配到某台 EC2 Instance 上了。

之前也有其他方法可以做到類似的事情：

用 VPC 提供的 Routing Table 把網段指到某台 EC2 的機器上。
把這台 EC2 機器的「Enable Source/Destination Check」關閉。

目前就是用這個方法搞定 VPN server 的：我們希望機器連上 VPN 後拿到 10.x.x.x 的 IP address，而且可以被 VPC 內直接存取，而不要被 NAT 掉。

好像該開張票轉移過去...

GitHub 對 Issues 增加了一些新功能

GitHub 推出了 Issues 的 beta program：「GitHub Issues · Project planning for developers」。

目前列出來的新功能裡，Board 與 Table 呈現方式 (Bored of boards? Switch to tables.)，以及 Subticket 的功能 (Break issues into actionable tasks)，這兩個算是在 project management 裡面很重要的功能，不過整體還是很陽春，只能說補上了一些重要的元素...

另外這次的 beta program 算是宣示 GitHub 有投入資源在改善 project management 這部份的功能，也許之後也許會有其他新功能繼續推出？

三不五時被提到的 LackRack

又在 Hacker News Daily 上看到 LackRack 了，這是 IKEA 的 LACK 系列家具，因為尺寸很剛好，有人就 hack 這個邊桌拿來當作機櫃用，甚至還有仿 IKEA 的組裝文件：「Manual」。

另外還可以疊 (不過要注意重量，畢竟這還是木頭)：

這張邊桌在台灣也有賣，有四種不同的外觀可以選：「LACK 邊桌, 白色」、「LACK 邊桌, 黑色」、「LACK 邊桌, 高亮面白色」與「LACK 邊桌, 黑棕色」，尺寸都是 55cmx55cmx45cm。