NLB 接 ALB?

AWS API Changes 上看到這個修改:「2021/09/27 - Elastic Load Balancing - 3 updated api methods」。

說明是這樣:

Adds new ALB-type target group to facilitate forwarding traffic from NLB to ALB

所以是 NLB 可以接到 ALB 嗎,這看起來讓彈性變大不少...

MySQL InnoDB 的 OPTIMIZE TABLE 的 Lock

Backend Twhttps://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

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

Multithreading 版本 pt-online-schema-change

看起來是個嘗試,Percona 的人試著修改 pt-online-schema-change,讓他可以在 INSERT 時 multi-threading,然後看效果:「Multithreaded ALTER TABLE with pt-online-schema-change and myloader」。

可以看出來 thread 夠多的情況下其實都變快不少 (上圖主要是看絕對數字,下圖是看相對比率):

如果沒有意外的話應該會有更多的測試,而這些測試沒問題的話,之後的官方版本裡面應該就會有這個功能。

AWS API Changes

Twitter 上看到 Jeff Barr 提到的,看 whois 資料是去年年底生出來的網域名稱,整理了 AWS 服務上 API 的改變說明:「AWS API Changes」。

有提供 RSS feed 可以訂閱,所以除了可以透過 reader 訂起來以外,也可以透過 IFTTT 這類服務轉到 Telegram 或是其他的 IM 上,不過好像不是官方的服務,但總是比較有系統的整理出來了...

在 Galera Cluster 上的 DDL 操作 (e.g. ALTER TABLE)

Percona 整理了一份關於 Galara Cluster 上 DDL 操作的一些技巧,這包括了 Percona XtraDB ClusterMariaDB 的版本:「How to Perform Compatible Schema Changes in Percona XtraDB Cluster (Advanced Alternative)?」。

在不知道這些技巧前,一般都是拿 Percona Toolkit 裡的 pt-online-schema-change 來降低影響 (可以降的非常低),所以這些技巧算是額外知識,另外在某些極端無法使用 pt-online-schema-change 的情境下也可以拿來用...

裡面的重點就是 wsrep_OSU_method 這個參數,預設的值 TOI 就是一般性的常識,所有的指令都會被傳到每一台資料庫上執行,而 RSU 則是會故意不讓 DDL 操作 (像是 ALTER TABLE) 被 replicate 到其他機器,需要由管理者自己到每台機器上執行。

利用這個設定,加上透過工具將流量導到不同後端的資料庫上,就有機會分批進行修改,而不需要透過 pt-online-schema-change 這種工具。

nginx 1.13 將支援 TLSv1.3

nginx 的「CHANGES」這邊看到 1.13.0 把 TLSv1.3 加進去了 (雖然都還沒成為正式的標準,但一堆人都在支援 XDDD):

*) Feature: the "TLSv1.3" parameter of the "ssl_protocols" directive.

這樣以後出 1.14 的 stable 版本應該就可以玩 TLSv1.3 了...

強迫要求使用者改密碼反而會不安全?

在「Want Safer Passwords? Don't Change Them So Often」這邊在討論改目前 password policy 會有要求一定時間要改密碼造成的問題。原報導出自 美國聯邦貿易委員會 blog 上的「Time to rethink mandatory password changes」。

當你強制要求改密碼時,由於因為是被逼的,他們不會放太多心力:

Lorrie Cranor recently outlined, the weight of recent research agrees that when people are forced to change their passwords on the regular, they don’t put a whole lot of mental muscle behind it.

而在沒有準備的情況下產生出來的密碼將會是比較容易預測的:

Instead, Cranor notes, according to one UNC study, people “tended to create passwords that followed predictable patterns, called ‘transformations,’ such as incrementing a number, changing a letter to similar-looking symbol (for example changing an S to a $), adding or deleting a special character (for example, going from three exclamation points at the end of a password to two), or switching the order of digits or special characters (for example moving the numbers to the beginning instead of the end).”

另外你應該鼓勵使用者用 password manager 管理密碼,雖然不是完美的,但至少是目前比較合理的方案:

If for whatever reason you still can’t let go of making people change passwords as often as they turn the pages of their wall calendars, Cranor suggests that you at least encourage them to use a password manager, like LastPass or DashLane. They’re not perfect, but they can be a “very reasonable strategy” for coping, mostly because they don’t require people to balance unpredictable passwords with ones they can actually remember.

關於 RDBMS 的 Schema Migration...

在「NoSQL 大腸花」這份投影片裡面的 Page 12 有提到關於 RDBMS 的 Schema Migration:

以目前 open source 的兩個專案,MySQLPostgreSQL 來看,裡面提到的 lock 應該都不是問題...

首先是 MySQL 的部份,真的量大的網站都應該是往 InnoDB 投靠,而 pt-online-schema-change 在這個領域則是處理的很好。

Facebook 的 Mark Callaghan 曾經在 2010 年寫過一篇關於 InnoDB 的 online schema change 的原理:「Online Schema Change for MySQL」,主要是利用 Trigger 的機制,用七個步驟架構出沒有 downtime 的 online scheme change。

就算不考慮 pt-online-schema-change 這種工具,在 MySQL 5.6 開始,就有愈來愈多 ALTER TABLE 的行為是不會影響到 read/write 了:「Avoiding MySQL ALTER table downtime」。

而 PostgreSQL 的情況也差不多,常見的 ALTER TABLE (新增與刪除 column 與 index) 也都不會影響 read/write。

這些在 Stack Overflow 上有不少討論:「ALTER TABLE without locking the table?」。

MySQL 在 RDBMS 領域裡比起來的確是不怎樣,不過沒有這麼糟糕啊...

利用 pt-online-schema-change 同步 master 與 slave 的資料

在「Syncing MySQL slave table with pt-online-schema-change」這篇看到 master 與 slave 的資料不同步時,強制性同步的方法:

pt-online-schema-change --alter 'ENGINE=INNODB' D=dbname,t=tblname

由於 pt-online-schema-change 的作法是建一個新的表格,然後把舊表格的資料寫過去,而這些行為會被 replicate 到新機器上,於是就同步了...

這招有趣 XDDD