這是文章的子討論串,你可以回到上層查看所有討論和文章
Ant 積分 5

pt-online-schema-change 是過渡期工具,主要供 MySQL 5.6 之前版本。它的執行原理非常暴力, copy table + trigger,所以沒有 locking。

到了 MySQL 5.6 之後,因為支援 Online DDL (MySQL 5.7 支援更全面),很多 ALTER TABLE 都不再 locking,可以在生產線上直接運行,只是免不了效能的抖動。因為 MySQL 資料結構與 PostgreSQL 不同,所以 schema change 再怎麼做還是不會比 PostgreSQL 來得有效率。

對我來說,PostgreSQL 最大的問題在於沒有很成熟的 master-master 及跨數據中心的同步方案。master-master 有它先天的問題。可是 master-slave 有 SPOF 及 single write hotspot 問題,前者可用 HA 解,但後者無解。

跨數據中心又是另一個麻煩事,如果不支援就要自己搞 Sharding,不是做不到。而且 Sharding 很難維護又很可能一不小心就破壞商業邏輯。就算要搞 Sharding,MySQL 還是有比 PostgreSQL 相對成熟的方案,就是官方的 Fabric,夠傻瓜夠直覺夠彈性。

從 Enterprise requirement 可以看出 PostgreSQL 與 MySQL 發展思路上的差異,如果是走穩定、數據保證,目前 PostgreSQL 絕對會是首選 (但 MySQL 5.7 追上來了);如果是走網路服務的高延展性、跨數據中心,那目前就是 MySQL 的天下了。

kaif 積分 0

請教「 master-master 及跨數據中心的同步方案」是指?

master-master是galera或官方的orcale mysql cluster (NDB)嗎? 跨數據中心是replication?

kaif 積分 1 編輯於

這個應該主要是來處理alter table locking的,效能不確定有沒有改善。不過聽我們不太專業的DBA講好像用起來也有些issue

如果postgresql可以在上億筆資料一秒alter table without locking,那還蠻吸引我的。

HYL 積分 4

PG 的檔案結構跟 MySQL 不一樣, PG 是一個 column 一個檔案,所以新增一個 nullable column 的話,就是開一個空的檔案而已,刪掉某個欄位也是刪掉一個檔案而已。

MySQL 是整個 Table 一個檔案,所以 ADD/DELETE column 都要整個 Table 重寫一次。

Ant 積分 3

目前大家討論的是 MySQL InnoDB & PostgreSQL,但 MySQL 還有一個很大的特色:可熱抽換的引擎。MogoDB 3.0 也引用了這項優點。

如果覺得 InnoDB engine 不好,可以換成別的 engine,甚至 MySQL 可以讓某些 engines 彼此 replication 混用。

前者,可以因應業務場景的改變抽換 engine,例如 OLTP 換成 OLAP 再換成 Warehouse 時,一行指令就可以搞定其對應的適用 engine。

後者,讓 DBA 可以用多個 engines 應付不同的業務,同時維運管理仍可視為同一集群而降低成本及風險。

PostgreSQL 只有一種 engine,不可抽換,這會限制它可適用的範圍。未來 PostgreSQL 有沒有可能引入可熱抽換 eninge?也許有可能,但至今沒看到相關計畫,而且 PostgreSQL 太多底層都跟現行的 eninge 相依太高,要改變實屬不易。

kaif 積分 0

mysql現在有engine可以在一億筆資料快速alter table嗎?感覺網路服務還蠻常需要做這件事的。

ryudoawaru 積分 0

要用外部工具這點不是很好啊...如果是用 ORM 做 migration 的話就 GG 了

kaif 積分 2 編輯於

我家做zero down time service通常不會讓ORM自動做migration。畢竟ORM頂多只能作到schema change,遇到要配合程式邏輯update資料的時候,還是要手工,不如就全手工了。此外也不太信任ORM。

IngramChen 積分 3

同意。

其實我也不知道為什麼 ORM migration 會盛行。程式邏輯變更要手動下 update 很常發生啊,怎麼可能自動 migrate ? 而且常常遇到的情況是:

  1. 先修改 schema 一輪,讓新舊 app servers 能同時運作
  2. rolling upgrade app servers
  3. 再修改 schema 一次,這次可以將舊的 table/column 都清理掉

說真的我不太了解 ORM migration 可以做到什麼程度,但像上面這樣的流程我如果不一行行看 SQL 執行,一行行 review alter schema 的結果,我完全不放心啊。(強迫症...)

ryudoawaru 積分 2

用 ORM migration != 不能手寫 SQL 式 migration 啊..至少 ActiveRecord 可以

c9s 積分 1

ORM 不是都有提供 migration script 撰寫的機制嗎?流程可以完全客製化

我都會先在開發機上先下完一輪 SQL 然後改到 migration script 上,避免在 SOP 的過程中有遺漏的部分

其他人在同步更新時,也可以透過這個 migration script 自動 upgrade,同樣的也可以避免 SOP 中有遺漏

IngramChen 積分 0

原來現在已經有這種工具了啊。很快就會用到了

qrtt1 積分 2 編輯於

我是都有在追 gslin 的 RSS 才知的,不過要注意一下提醒事項。要先在 staging 測過,而且使用前記得備份。 :P

我自己只用過他的備份工具,還沒機會用到 pt-* 系列的工具。 這篇的 master/slave 強制同步妙計1 真令人驚豔啊。