Tag: lock

Amazon EBS 在 Compliance mode 下的 Snapshot Lock

Jeff Barr 寫了「New – Amazon EBS Snapshot Lock」這篇，介紹 Amazon EBS 的新功能 Snapshot Lock。

從名字就知道是鎖住 snapshot 不讓人刪除，比較特別的是有兩個模式，第一個是 Governance，這個模式下就只是防止誤刪除的情況：

This mode protects snapshots from deletions by all users. However, with the proper IAM permissions, the lock duration can be extended or shortened, the lock can be deleted, and the mode can be changed from Governance mode to Compliance mode.

比較重要的是第二個模式 Compliance，在超過猶豫期 (cooling-off period) 後就不能動了，就算你有最大的權限 (我猜是連 root account 也不能動)，唯一能操作的只有延長 lock 時間：

This mode protects snapshots from actions by the root user and all IAM users. After a cooling-off period of up to 72 hours, neither the snapshot nor the lock can be deleted until the lock duration expires, and the mode cannot be changed. With the proper IAM permissions the lock duration can be extended, but it cannot be shortened.

的確是遵循法規用的功能...

ClickHouse 弄了一個 C++ 寫的 ZooKeeper drop-in replacement：ClickHouse Keeper

在 Hacker News 上看到「ClickHouse Keeper: A ZooKeeper alternative written in C++ (clickhouse.com)」，原文是「ClickHouse Keeper: A ZooKeeper alternative written in C++」。

在 distributed coordination 這個領域目前應該是 etcd 比較知名，但 Apache ZooKeeper 畢竟算是元老，還是有不少應用程式會把 ZooKeeper 當作基礎建設在用。

因此 etcd 也包了一個 zetcd，可以用 etcd 當作底層結構，但提供 ZooKeeper API 的介面讓應用程式使用：

Serve the Apache Zookeeper API but back it with an etcd cluster

這次 ClickHouse 的人搞出一個用 C++ 寫的 ClickHouse Keeper，定位是 drop-in replacement，想要解決現有的應用程式遇到的記憶體資源問題。

從開頭的說明就可以看到著重在這塊：

up to 46 times less memory than ZooKeeper ​​for the same volume of data while maintaining performance close to ZooKeeper.

而對於新的應用程式，在開發時應該就不太會選 ZooKeeper 了，畢竟連 distributed lock 都得自己操作 znode 把功能疊出來 (像是官網很貼心的還提供了「ZooKeeper Recipes and Solutions」，裡面提供了 lock 的方法)，而這種事情太累，用 etcd 方便太多...

窮舉 PostgreSQL 的 LOCK 機制

PostgreSQL Lock Conflicts 這份資料窮舉了 PostgreSQL 的 lock 機制，分成兩種方式呈現：

  • 依照 Lock：文內列出 12 種 lock。
  • 依照 Command：文內列出了 67 種指令。

可以交叉查，用 lock 查出有哪些 command 有用到，或是反過來用 command 查會產生那些 lock：

This tool shows all commands and locks in postgres. If you select a command, it lists the locks that it acquires, commands that conflicts with it and commands that are allowed to run concurrently with it (with no conflict or blocking). If you select a lock, it lists commands that acquire the lock and what are the other conflicting locks.

舉個例子來說，Lock 列表裡的第一個，AccessShareLock，這個點進去後可以看到有三個指令會有使用到 AccessShareLock 的情境，分別是 SELECT、COPY TO 以及 ALTER TABLE ADD FOREIGN KEY (PARENT)。

是個更熟悉 PostgreSQL 的路徑？

XFCE (Xubuntu) 下的手動 lock + screensaver + DPMS 組合

桌機換成 Xubuntu 22.04 後會遇到手動鎖定螢幕時，螢幕不會進入省電模式，遇到的情況有點像是「DPMS Suspend on Screen Lock」這邊提到的情境。

這類問題如果用 search engine 一時間沒有找到解法的話，最好的方法都是直接去讀 source code，然後就發現透過 Ctrl+Alt+L 觸發的 /usr/bin/xflock4 其實是個 shell script，從 code 讀可以發現裡面只負責 lock 的部分，本來就跟 DPMS 無關。

我在下面提供的方案就是自己處理螢幕的部分，也就是自己先跑 DPMS 指令，然後再回頭呼叫 /usr/bin/xflock4：

#!/bin/sh
/usr/bin/xset dpms force off
exec /usr/bin/xflock4

把 Ctrl+Alt+L 的觸發程式掛上來，這樣就會正常處理了...

Amazon EFS 的 file lock 限制

看到「Amazon EFS now supports a larger number of concurrent file locks」這篇提到：

This Amazon EFS update increases the number of simultaneous file locks an NFS mount can acquire to 65,536 (from 8,192 previously), enabling Amazon EFS to be used for a broader set of applications that heavily leverage file locking (including message broker and distributed analytics applications).

所以 NFS 的部份先前有 8192 個的上限在，現在則是拉 65536 個了。

不過提到 message broker，應該是以前的應用利用 NFS file lock 來做一些事情？

密碼輸入上的 UX

Hacker News 上看到「Gmail password first character is case insensitive on mobile device (support.google.com)」這篇，在講密碼輸入上的 UX。

在 Hacker News 上的討論看到這則：

This is a well-understood feature. Facebook does the same thing[0].

Quote:

Facebook actually accepts three forms of your password:

* Your original password.

* Your original password with the first letter capitalized. This is only for mobile devices, which sometimes capitalize the first character of a word.

* Your original password with the case reversed, for those with a caps lock key on.

[0]: https://www.zdnet.com/article/facebook-passwords-are-not-case-sensitive-update/

接受三種密碼，第一種是完全正確的密碼，第二種是第一個字如果是大寫時的密碼 (在行動裝置上可能的行為)，第三種是大小寫全部相反的密碼，這在沒注意到 caps lock 時會發生。

強度不會削弱太多，但對於 user experience 好很多的設計。

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

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

PostgreSQL 的 Job Queue、Application Lock 以及 Pub/Sub

Hacker News Daily 上看到一篇講 PostgreSQL 做 Job Queue、Application Lock 以及 Pub/Sub 的方法：「Do You Really Need Redis? How to Get Away with Just PostgreSQL」，對應的討論在「Do you really need Redis? How to get away with just PostgreSQL (atomicobject.com)」這邊可以翻到。

拿 PostgreSQL 跑這些東西的確有點浪費，不過如果是自己的專案，不想要把 infrastructure 搞的太複雜的話，倒是還不錯。

首先是 Job Queue 的部份，從他的範例看起來他是在做 async job queue (不用等回傳值的)，這讓我想到很久前寫的 queue service (應該是 2007 年與 2012 年都寫過一次)，不過我是用 MySQL 當作後端，要想辦法降低 InnoDB 的 lock 特性。

async job queue 設計起來其實很多奇怪的眉角，主要就是在怎麼處理失敗的狀態。大多數的需求可以放到兩個種類，最常見用的是 at-least-once，保證最少跑一次，大多數從設計上有設計成 idempotence 的都可以往這類丟，像是報表類的 (重複再跑一次昨天的報表是 OK 的)，另外每天更新會員狀態也可以放在這邊。

另外少見一點的是 at-most-once 與 exactly-once，最多只跑一次與只跑一次，通常用在不是 idempotence 的操作上，像是扣款之類的，這邊的機制通常都會跟商業邏輯有關，反正不太好處理...

第二個是 Application Lock，跨機器時的 lock 機制，量沒有很大時拿 PostgreSQL 跑還行，再大就要另外想辦法了，馬上想到的是 ZooKeeper，但近年設計的系統應該更偏向用 etcd 與 Consul 了...

最後提到的 Pub/Sub，一樣是在量大的時候拿 PostgreSQL 跑還行，更大的時候就要拿 Kafka 這種專門為了效能而設計出來的軟體出來用...

繞過 Screensaver Lock 的有趣話題...

在 Hacker News Daily 上看到「Screensaver lock by-pass via the virtual keyboard」這篇，裡面這邊題到了 screensaver lock 的有趣話題。

先講嚴肅一點的，這個 bug 被編號為 CVE-2020-25712，問題出在 xorg-x11-server 上：

A flaw was found in xorg-x11-server before 1.20.10. A heap-buffer overflow in XkbSetDeviceInfo may lead to a privilege escalation vulnerability. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

比較有趣的事情是，這個 bug 是小朋友在亂玩時拉出 virtual keyboard 觸發的：

A few weeks ago, my kids wanted to hack my linux desktop, so they typed and clicked everywhere, while I was standing behind them looking at them play... when the screensaver core dumped and they actually hacked their way in! wow, those little hackers...

然後他說他自己搞不出來：

I tried to recreate the crash on my own with no success, maybe because it required more than 4 little hands typing and using the mouse on the virtual keyboard.

另外一個人也說他家小朋友也弄出 segfault 了：

My kids came upon a similar cinnamon-screensaver segfault! I've emailed details of how to reproduce the problem to root@linuxmint.com.

小朋友超強 XDDD

用 flock 防止指令同時間重複執行

flock(1) 是個好用的工具，可以避免指令同時重複執行。基本的用法是：

flock /tmp/example.lock /usr/bin/example

從這邊的 /tmp/example.lock 可以看出是透過檔案系統層的鎖實做的，也因為這樣的設計，所以用在 NFS 上時，可以規劃出跨機器的鎖定機制。(不過要注意舊版的 NFSv2/NFSv3 是可以刻意不跑 lock daemon 的，這樣就爛掉了 XD)

配合 crontab 執行時，-n 也是常用的選項，用在「這次沒跑也沒關係」的東西上，通常用在是計算出來後丟到 cache 內的程式，跑比較久的時候就跳過這次...