## 事務一致性 這篇月報[Primary和Mirror同步機制](http://mysql.taobao.org/monthly/2016/01/02/ "GreenPlum Primary/Mirror 同步機制")講了Primary和Mirror之間各種數據和文件的同步過程。這些數據和文件的同步，看似彼此獨立。那么如何保證某個時間點Mirror的所有數據是一致的，即任何時間點發生HA切換，Mirror都能達到一致性狀態并對外提供服務？正如我們前面提到的，這主要靠同步的順序來保證： 1. AO表的同步是個強同步的過程，數據在更新發生時即同步到Mirror，Primary和Mirror時刻保持著數據一致性。另一方面，事務提交時會更新AO表文件的尾指針信息，并同步到備庫。這樣事務提交后，Mirror肯定可以看到所有已提交的數據。所以Primary failover切換后AO表數據不會丟失，不影響事務的一致性。 2. Heap表的數據的更新會寫入相應的Xlog，同時確保Heap表數據頁的同步必須在對應的Xlog同步完成后才能進行。 你可能有疑問：Heap表的數據更新同步到Mirror是個異步的過程，那么會不會出現一個事務提交了，Heap表數據更新還沒有來得及同步到Mirror，這時候Primary failover切換到Mirror，導致Heap表數據丟失？當然不會的，雖然Heap表數據同步是一個異步的過程，但是Xlog的同步卻是一個強同步的過程。Primary failover切換到Mirror之后，Mirror上面的Xlog和Primary的Xlog完全一致，這時候Mirror會啟動startup進程，進入Recovery模式，應用Xlog，所以即便Heap表數據沒有同步過來，Mirror也會通過Xlog將這些沒有過來的數據恢復。 3. 其他文件的更新，其實不需要實時同步。切換時Mirror會回放Xlog，恢復這些文件的內容。 這樣，如果Primary與Mirror保持同步，上述順序保證了任何時間點Mirror節點的數據都能達到一致。但是，假如出現了網絡阻塞或者Mirror宕機的情況，數據就無法及時同步到Mirror。此時，如果Primary在更新數據時，等待數據被同步到Mirror，就會被阻塞，而無法繼續提供服務。為解決這個問題，Greenplum提供了異常處理機制。 ## 異常處理 此處所說的對網絡阻塞或Mirror宕機異常情況的處理，其實就是Greenplum所謂的Change Tracking機制。在Primary向Mirror同步數據的時候，如果Mirror長時間沒有回應Primary，那么Primary將會認為Mirror掛掉，這個時候Master將會把系統表gp_segment_configuration里面的Mirror狀態(status)置為’d’，同時把Primary的模式(mode)置為’c’，而這個’c’模式就是ChangeTracing Mode。Primary進入Change Tracking狀態后，不會再試圖同步數據到Mirror（每次有數據更改時會調用FileRepPrimary_IsMirroringRequired進行檢查是否需要同步）。 Primary進入ChangeTracing Mode之后，每次更新數據產生的Xlog，會被立即解析成數據更新記錄，放入到Change log文件里面（參見`ChangeTracking_AddRecordFromXlog`函數）。Change log文件在pg_changetracking/目錄下： ~~~ -rw------- 1 bgadmin bgadmin 196608 Apr 10 18:22 CT_LOG_FULL -rw------- 1 bgadmin bgadmin 403991 Apr 10 18:22 FILEREP_CONFIG_LOG -rw------- 1 bgadmin bgadmin 105119744 Apr 10 18:22 FILEREP_LOG ~~~ ChangeTracing信息具體記錄在CT_LOG_FULL文件里面，文件記錄的核心信息是當前的數據更新在Xlog中的位置，文件內容經過解析之后如下： ~~~ postgres=# select * from gp_changetracking_log(0) limit 3; segment_id | dbid | space | db | rel | xlogloc | blocknum | persistent_tid | persistent_sn ------------+------+-------+-------+------+--------------+----------+----------------+--------------- 0 | 2 | 1663 | 10893 | 5043 | (0/40000160) | 0 | (2,36) | 538 0 | 2 | 1663 | 10893 | 5043 | (0/400001C0) | 0 | (2,36) | 538 0 | 2 | 1663 | 10893 | 5043 | (0/40000220) | 0 | (2,36) | 538 ~~~ Change log里面只存放Heap表的修改信息。AO表的更新信息存放在特定的表中，無需另外記錄。而Xlog和普通文件，都完整保存在Primary的數據目錄下，無需記錄修改信息（具體原因在異常恢復的說明中有介紹）。 Change log其實是存放的Heap表更改頁的元數據信息，并未存放更改的實際內容。所以它并不占用太多存儲空間，另外它還可以對相同頁上的修改進行合并，進一步壓縮大小，減少恢復時間（參見`FileRepPrimary_RunChangeTrackingCompacting`函數）。 那么，Mirror在宕機后重啟或網絡擁塞發生后恢復正常了，重新連接到Primary后，如何通過Change log恢復同步呢？ * 異常恢復 在異常情況消失后，需要通過執行`gprecoverseg -a`命令來恢復同步。下面我們還是把數據分成4類來說明這個過程總數據同步恢復的過程。 * Heap表恢復 當我們執行`gprecoverseg -a`命令恢復Mirror時，Primary的Resync進程通過Change log信息，再結合Xlog，將積累的數據變更再次同步給Mirror。 具體步驟如下： 1. Resync manager進程通過調用一系列函數FileRepResyncManager_InResyncTransition->PersistentFileSysObj_MarkPageIncrementalFromChangeLog->PersistentFileSysObj_MarkPageIncremental->PersistentFileSysObj_UpdateTuplePageIncremental，將需要更新的Page的信息加入到ResyncEntry同步隊列中。 2. Resync worker進程從ResyncEntry隊列中取出需要恢復到Mirror的任務，通過調用一系列函數FileRepPrimary_ResyncBufferPoolIncrementalWrite->smgrwrite將Page寫到緩沖區中，再通過上面的方法構造消息發送到Mirror。 * AO表恢復 因為AO表不寫Xlog，所以Change log中并沒有記錄AO表更新操作。那么Mirror是如何將AO表恢復到和Primary數據一致呢？其實在GP catalog中有一張gp_persistent_relation_node表，里面記錄了AO表同步到Mirror的最后一次文件位置(mirror_append_only_loss_eof)，以及當前文件位置(mirror_append_only_loss_eof)。AO表文件位置的更新是在FinishPreparedTransaction函數完成的(執行COMMIT PREPARED or ROLLBACK PREPARED)。最后Resyncworker進程將會把未同步到Mirror的增量數據再次通過消息同步給它，最終達到Primary和Mirror的數據一致性。 ~~~ postgres=# select * from gp_persistent_relation_node where relfilenode_oid=25386; -[ RECORD 1 ]-------------------------------------+---------- tablespace_oid | 1663 database_oid | 10893 relfilenode_oid | 25386 segment_file_num | 1 relation_storage_manager | 2 persistent_state | 2 create_mirror_data_loss_tracking_session_num | 0 mirror_existence_state | 3 mirror_data_synchronization_state | 1 mirror_bufpool_marked_for_scan_incremental_resync | f mirror_bufpool_resync_changed_page_count | 0 mirror_bufpool_resync_ckpt_loc | (0/0) mirror_bufpool_resync_ckpt_block_num | 0 mirror_append_only_loss_eof | 301742600 mirror_append_only_new_eof | 310752552 relation_bufpool_kind | 0 parent_xid | 0 persistent_serial_num | 754 previous_free_tid | (0,0) ~~~ * Xlog文件的恢復 我們知道，Xlog文件其實都保存在Primary的pg_xlog目錄下。在異常恢復時，把改目錄下的文件直接發送到Mirror即可。需要注意的是，異常期間是可以正常刪除或規定Xlog文件的，這是因為，所有的Heap表和AO表的修改都已經被保存下來了，無需另外保留一份Xlog來恢復數據。 * 其他文件的恢復 其他文件（pg_control, pg_clog, pg_mutitrans等文件）也和Xlog文件一樣，在恢復時直接全部發送到Mirror，具體參見`FileRepResyncManager_ResyncFlatFiles`函數。