gh-ost和pt-osc性能對比

 haughty_xiao 

基于MySQL row格式的複制現在趨于主流，是以可以使用此格式的binlog來跟蹤改變而不是觸發器。與percona toolkit的pt-online-schema-online相比，gh-ost做法更為幹淨，更安全。由于gh-ost不使用觸發器，可能會産生更低的開銷并且工作更快。

聲明：這些基準對應于一個特定結構和硬體配置的表上的一個特定的ALTER TABLE。 我沒有設定一套廣泛的測試。

Benchmark Setup Details：

● pt-online-schema-change from Percona Toolkit 3.0.3 

● gh-ost 1.0.36 

● Percona Server 5.7.18 on Ubuntu 16.04 LTS 

● Hardware: 28CPU cores/56 Threads. 128GB Memory. Samsung 960 Pro 512GB 

● Sysbench 1.0.7

通過如下指令生成測試表：

sysbench --threads=40 --rate=0 --report-interval=1 --percentile=99 --events=0 --time=0 --db-ps-mode=auto --mysql-user=sbtest --mysql-password=sbtest  /usr/share/sysbench/oltp_read_write.lua --table_size=10000000 prepare           

表大小為3GB 

設定如下參數以滿足“full ACID”：

• sync_binlog=1
• innodb_flush_log_at_trx_commit=1
• innodb_doublewrite=1

使用pt-online-schema-online更改表結構：

time pt-online-schema-change --execute --alter "ADD COLUMN c1 INT" D=sbtest,t=sbtest1           

使用gh-ost更改表結構：

time ./gh-ost  --user="sbtest" --password="sbtest" --host=localhost --allow-on-master --database="sbtest" --table="sbtest1"  --alter="ADD COLUMN c1 INT" --execute           

測試細節：

對于每個測試，丢棄舊的sysbench表被并準備好一個新表。 在每次測量了所有情況下的alter table完成時間，以及alter所産生的開銷（換句話說，通過通過工具運作alter table可以減少多少峰值吞吐量）。 在三種不同的情況下進行alter table測試： 

● When nothing else was running (“Idle Load”) 空負載 

● When the system handled about 2% of load it can handle at full capacity (“Light Background Load”)系統有2%左右的負載（低負載） 

● When the system handled about 40% of the possible load, with sysbench injected about 25% of the transactions/sec the system could handle at full load (“Heavy Background Load”)系統處理40%左右的負載（高負載）

Idle Load（空負載）

對于空閑負載測試，pt-online-schema-change完成幾乎比gh-ost快一倍。可以看到gh-ost的大部分CPU使用情況在MySQL伺服器端。 也許差異與用于執行非阻塞alter table的SQL有關。

Light Background Load（低負載）

通過運作下面的sysbench指令生成了Light Background Load。 它對應于大約4％的負載，因為系統可以在滿負荷的情況下處理這種并發的大約2500個事務/秒。 調整–rate值以縮放系統。

time sysbench --threads=40 --rate=100 --report-interval=1 --percentile=99 --events=0 --time=0 --db-ps-mode=auto --mysql-user=sbtest --mysql-password=sbtest  /usr/share/sysbench/oltp_read_write.lua --table_size=10000000 run           

時間變化如逾期一樣，pt-osc仍然比gh-ost快一倍 

在這種情況下真正有趣的是如何相對較輕的背景負載影響過程完成時間。

Heavy Background Load（高負載）

運作下面sysbench指令生成的Heavy Background Load。 它對應于大約40％的負載，因為系統可以在滿負載的情況下處理這種并發性的大約2500個事務/秒。 調整–rate值以縮放系統。

time sysbench --threads=40 --rate=1000 --report-interval=1 --percentile=99 --events=0 --time=0 --db-ps-mode=auto --mysql-user=sbtest --mysql-password=sbtest  /usr/share/sysbench/oltp_read_write.lua --table_size=10000000 run           

在這種情況下發生了什麼？當負載變高時，gh-ost無法跟上二進制日志處理，而且永遠完不成。

雖然這可能令人驚訝，但如果您更多地考慮這些工具的工作原理，這是有道理的。 pt-online-schema-change使用觸發器，雖然它們有很多限制和開銷，但它們可以并行執行。另一方面，gh-ost将二進制日志處理在單個線程中，可能無法跟上。

在MySQL 5.6中，我們無法并行複制同一個表中。對于該版本，第一個限制可能不是一個大的問題，因為這麼大的負載會導緻複制滞後。 MySQL 5.7具有并行複制功能。這使得快速複制對于gh-ost來說太重的工作負載更容易處理。

此時應該注意到，在這個基準測試中模拟的工作量是一個相當極端的情況。在這裡由gh-ost更改的表同時處理一個背景加載，是以它不能在單個線程中複制。

gh-ost的未來版本可以通過并行應用binlog事件來改善這個問題，就想MySQL複制一樣。

來自gh-ost日志的摘錄，顯示了如何完全備份嘗試應用二進制日志：

root@rocky:/tmp# time ./gh-ost  --user="sbtest" --password="sbtest" --host=localhost --allow-on-master --database="sbtest" --table="sbtest1"  --alter="ADD COLUMN c1 INT" --execute
2017/06/25 19:16:05 binlogsyncer.go:75: [info] create BinlogSyncer with config &{99999 mysql localhost 3306 sbtest sbtest  false false <nil>}
2017/06/25 19:16:05 binlogsyncer.go:241: [info] begin to sync binlog from position (rocky-bin.000018, 640881773)
2017/06/25 19:16:05 binlogsyncer.go:134: [info] register slave for master server localhost:3306
2017/06/25 19:16:05 binlogsyncer.go:568: [info] rotate to (rocky-bin.000018, 640881773)
2017-06-25 19:16:05 ERROR parsing time "" as "2006-01-02T15:04:05.999999999Z07:00": cannot parse "" as "2006"
# Migrating `sbtest`.`sbtest1`; Ghost table is `sbtest`.`_sbtest1_gho`
# Migrating rocky:3306; inspecting rocky:3306; executing on rocky
# Migration started at Sun Jun 25 19:16:05 -0400 2017
# chunk-size: 1000; max-lag-millis: 1500ms; max-load: ; critical-load: ; nice-ratio: 0.000000
# throttle-additional-flag-file: /tmp/gh-ost.throttle
# Serving on unix socket: /tmp/gh-ost.sbtest.sbtest1.sock
Copy: 0/9872432 0.0%; Applied: 0; Backlog: 0/100; Time: 0s(total), 0s(copy); streamer: rocky-bin.000018:641578191; State: migrating; ETA: N/A
Copy: 0/9872432 0.0%; Applied: 0; Backlog: 100/100; Time: 1s(total), 1s(copy); streamer: rocky-bin.000018:641626699; State: migrating; ETA: N/A
Copy: 0/9872432 0.0%; Applied: 640; Backlog: 100/100; Time: 2s(total), 2s(copy); streamer: rocky-bin.000018:641896215; State: migrating; ETA: N/A
Copy: 0/9872432 0.0%; Applied: 1310; Backlog: 100/100; Time: 3s(total), 3s(copy); streamer: rocky-bin.000018:642178659; State: migrating; ETA: N/A
Copy: 0/9872432 0.0%; Applied: 1920; Backlog: 100/100; Time: 4s(total), 4s(copy); streamer: rocky-bin.000018:642436043; State: migrating; ETA: N/A
Copy: 0/9872432 0.0%; Applied: 2600; Backlog: 100/100; Time: 5s(total), 5s(copy); streamer: rocky-bin.000018:642722777; State:
...
Copy: 0/9872432 0.0%; Applied: 120240; Backlog: 100/100; Time: 3m0s(total), 3m0s(copy); streamer: rocky-bin.000018:694142377; State: migrating; ETA: N/A
Copy: 0/9872432 0.0%; Applied: 140330; Backlog: 100/100; Time: 3m30s(total), 3m30s(copy); streamer: rocky-bin.000018:702948219; State: migrating; ETA: N/A
Copy: 0/9872432 0.0%; Applied: 160450; Backlog: 100/100; Time: 4m0s(total), 4m0s(copy); streamer: rocky-bin.000018:711775662; State: migrating; ETA: N/A
Copy: 0/9872432 0.0%; Applied: 180600; Backlog: 100/100; Time: 4m30s(total), 4m30s(copy); streamer: rocky-bin.000018:720626338; State: migrating; ETA: N/A
Copy: 0/9872432 0.0%; Applied: 200770; Backlog: 100/100; Time: 5m0s(total), 5m0s(copy); streamer: rocky-bin.000018:729509960; State: migrating; ETA: N/A           

線上架構改變性能影響

對于這個測試，我啟動了alter table，等待了60秒，然後全速運作sysbench五分鐘。 然後我通過運作該工具來衡量性能受到的影響：

sysbench --threads=40 --rate=0 --report-interval=1 --percentile=99 --events=0 --time=300 --db-ps-mode=auto --mysql-user=sbtest --mysql-password=sbtest  /usr/share/sysbench/oltp_read_write.lua --table_size=10000000 run           

我們可以看到，在這種情況下，gh-ost的開銷可以忽略不計。 另一方面，pt-osc模式性能下降了12％。 值得注意的是，盡管在這種情況下，pt-online-schema-change仍然取得進展（盡管緩慢），而gh-ost永遠不會完成相應更改。

總結

雖然gh-ost引入了一些設計優勢，并且在某些情況下給出了更好的結果，但是， 至少在某些情況下，pt-online-schema-change提供比gh-ost更好的性能，而且存在gh-ost無法完成的schema更改。