Requirements 要求：

  • server 必須開啟 log_bin，若為 Slave 同時也必須開啟 log_slave_updates
  • 需要一台 binlog_format 為 ROW模式的 server
  • 如果在slave上使用，必須確保要ALTER的TABLE在Master和Slave上Schema相同
權限：
ALTER, CREATE, DELETE, DROP, INDEX, INSERT, LOCK TABLES, SELECT, TRIGGER, UPDATE ON database.* OR *.*
SUPER, REPLICATION SLAVE on *.* 或 REPLICATION CLIENT, REPLICATION SLAVE on *.*
SUPER權限用於 STOP SLAVE 和 START SLAVE，具體用途為：
  1. 當 binlog_format不是 ROW 並且指定 --switch-to-rbr 時，將切換 binlog_format 並重啟 replication。如果是 ROW 模式可以指定 --assume-rbr 避免 STOP SLAVE 和 START SLAVE ，在此情況下，不需要提供 SUPER 權限。
      2. (提醒！若自行切換 binlog_format 須記得重啟replication！)
  1. 運行 --test-on-replica 時，gh-ost切換表後會停止 replication ，讓使用者比較兩張表。

Limitations 限制：

  • 目前不支持外鍵。未來可能會提供一定程度的支持
  • 目前不支持trigger。未來可能會提供支持
  • 支持MySQL 5.7的 JSON ，但前提是不能是 PRIMARY KEY 的一部分
  • 新表和舊表必須使用相同的 PRIMARY KEY 或 UNIQUE KEY 。因為複製時會 gh-ost 會利用該 KEY遍歷所有行。遷移鍵必須為 NOT NULL (可以為空值)。或是有 NULL屬性 並使用 --allow-nullable-unique-key 但必須確保實際上沒有 NULL 值，否則可能導致數據不完整。
  • 當存在名稱相同僅大小寫不同的table時無法進行
  • 阿里雲RDS能正常運作，僅需要添加 --aliyun-rds
  • Google Cloud SQL可使用，僅需添加 --gcp
  • 當 SLAVE 的來源為multi時，無法支持在 SLAVE 上執行，建議直接在 MASTER上進行，需添加 --allow-on-master
  • 目前當在 master-master 運行 gh-ost 時，沒有辦法支援兩邊都有寫入的情況。將來可能支援
  • 若將 enum 型態的欄位作為 PRIMARY KEY 將使性能降低
  • 不支援 federated Table ，並且與 gh-ost 想要解決的方案無關
  • 不支持 ALTER TABLE ... RENAME TO some_other_name ，這樣的操作不應該是用 gh-ost

Concurrent migrations 並發遷移：

  • 絕對不要運行在同一個 Table 上。
  • 如果運行在不同的 SLAVE 上，不需要其他調整。例如：table1 on slave1 和 table2 on slave2。
如果在同一個機器運行 gh-ost
  • 確保 -server-socket-file 設置不同名稱（或由 gh-ost 命名）。
  • 透過 -throttle-additional-flag-file 控制所有 gh-ost，另外透過 throttle-flag-file 控制單一 gh-ost 。
  • 如果 -host 相同，則必須對每個 gh-ost 設定唯一的 replica-server-id 避免衝突。