alwayson 副本同步需要完成三件事：
1．把主副本上發生的資料變化記錄下來。
2．把這些記錄傳輸到各個輔助副本。
3．把資料變化在輔助副本上同樣完成一遍。
這3件工作主要由以下4個執行緒完成
log writer執行緒：當任何乙個sql使用者提交乙個資料修改事務時，它會負責把記錄本次修改的日誌資訊先記入一段記憶體中的日誌緩衝區，然後再寫入物理日誌檔案（日誌固化）。
log scanner工作執行緒：位於主副本所在sql server上。這個執行緒專門負責將日誌記錄從日誌緩衝區或者日誌檔案裡中讀出，打包成日誌塊，傳送給各個輔助副本。由於它的不間斷工作，才使主副本上的資料變化，可以不斷地向輔助副本上傳播。
固化（harden）執行緒和重做（redo）執行緒：位於輔助副本所在的sql server上。固化執行緒會將主副本log scanner所發過來的日誌塊寫入輔助副本的磁碟上的日誌檔案裡（這個過程被稱為"固化"）。而重做執行緒，則負責從磁碟上讀取日誌塊，將日誌記錄翻譯成資料修改操作，在輔助副本的資料庫上完成。
這些執行緒在工作上各自獨立，以達到更高的效率。log scanner負責傳送日誌塊，而無須等待log writer完成日誌固化；輔助副本完成日誌固化以後就會傳送訊息到主副本，告知資料已經傳遞完畢，而無須等待重做完成。其設計目標，是盡可能地減少alwayson所帶來的額外操作對正常資料庫操作的效能影響。
alwayson的資料同步有可分為非同步提交和同步提交
在同步提交模式下由可分為 輔助副本發出同步請求和主副本發出同步請求。
2.1 輔助副本發出同步請求
此情況，主要發生在輔助副本剛剛加入可用性組、或者網路等原因主副本出現差異、或者輔助副本出現髒頁（物理）等少數情況下。
步 驟
行 為
1.連線
輔助副本通過主副本的映象端點建立兩者之間的連線。
2.請求資料
輔助副本發出乙個請求到主副本，要求主副本傳送日誌塊。輔助副本和主副本
會協商出乙個日誌塊的lsn初始位置以及一些其他的資訊。
3.執行log scanner
在主副本上，log scanner的工作執行緒開始工作。log scanner負責將日誌塊
傳送到輔助副本。
4.固化和重做日誌
輔助副本會使用固化（harden）執行緒和重做（redo）執行緒的工作執行緒來處理
log scanner傳送過來的日誌塊，固化執行緒將日誌塊固化到輔助副本的磁碟上
，而重做執行緒負責將日誌中記錄的事務在輔助副本上重新演繹。
5.反饋進度
每當輔助副本收到3條來自主副本的訊息的時候，就把固化和重做的進度作為
乙個訊息返回給主副本。如果超過1秒還沒收到3條訊息，進度訊息也會被返回。
反饋到主副本的訊息裡包含了哪些lsn已經在輔助副本上被重做和固化。
2.1 主副本發出同步請求，即客戶端提交sql請求觸發的同步請求
步 驟
行 為
1.提交事務
在主副本上執行commit tran命令來提交事務.
2.寫入到本
地日誌記錄
在主副本上，commit tran命令會被寫成一條日誌記錄（此時記錄還在主資料庫的日誌快取中）.
然後主副本上的log writer工作執行緒會把直到commit命令為止的所有日誌記錄組成乙個日誌塊
從快取寫入到磁碟上的ldf檔案中。當日誌被寫入到磁碟之後，主資料庫就開始等待來自輔助副本
的訊息來確認日誌在輔助資料庫上被成功寫入磁碟。在這之前，該事務提交操作會保持等待。
3.掃瞄日誌
當日誌塊開始被從快取寫入到磁碟上時，它也會發訊號給log scanner工作執行緒，告訴
log scanner「日誌已經準備好了，可以被傳送到輔助副本上」。log scanner從快取中取出
日誌塊，把它傳送給alwayson的日誌塊解碼器（log block cracker）。解碼器會搜尋日誌
中那些需要特別處理的操作，比如file stream操作，檔案增長等。解碼器會把這些操作作為
乙個訊息傳送給輔助副本。一旦日誌塊被解碼完畢，整個日誌塊也會被作為訊息傳送給輔助副本.
4.處理日誌塊訊息
日誌塊訊息在輔助副本上得到處理。固化執行緒負責將日誌固化到磁碟上。然後日誌被儲存到輔助
資料庫的日誌快取中，重做執行緒從快取中獲得日誌塊並開始執行重做操作.
5.反饋進度
每當輔助副本收到3條來自主副本的訊息時，就把固化和重做的進度作為乙個訊息返回給主副本。
如果超過1秒還沒收到3條訊息，進度訊息也會被返回。進度資訊中包含當前哪些lsn被固化了，
哪些lsn已經被重做了。由於重做執行緒晚於固化操作啟動，被固化的lsn可能會多於被重做的lsn.
6.完成提交
主資料庫受到了輔助副本來的確認訊息，完成事務提交處理並向客戶端傳送一條確認訊息.
2. 補充說明
在同步提交模式下，日誌塊必須在主副本和輔助副本上都被固化到磁碟上，事務才能真正在主資料上提交。但是它並不要求日誌在輔助副本上完成重做，這樣可以減輕對主副本的效能影響。
進入disconnected
或"not synchronizing"
狀態後，即使可用性副本處於同步提交模式，事務也不需要等待該副本的響應就可以在主副本上提交。
如果為當前主副本配置了非同步提交可用性模式，則它將通過非同步方式為所有輔助副本提交事務，而不管這些副本各自的可用性模式設定如何。
它可以保證事務日誌是同步的，也就是可以保證不丟失資料，但不能保證資料變化沒有延時，這是由於輔助副本在接收主副本傳來的
trans log
時，首先將其緩到本地
log cache
，接著強制硬化到本地
ldf，然後隨即向主副本告知你可以
commit
了，但注意，此時的硬化到本地
ldf並非本地資料已經變化，這是因為輔助副本將
trans log
硬化到本地的同時，它是使用乙個非同步程序去
redo
這些trans log
產生的page
變化到data
檔案的，所以資料的延時就是肯定的了。
部分內容參照書籍《sql server 2012 實施與管理實戰指南》，感謝原作者。
Git git fork倉庫與原倉庫的同步
在團隊開發時，成員將repo fork到自己github下進行開發，然後在個人github repo中pull request將變動合併到團隊repo中。當有成員改動團隊repo時，我們需要將團隊遠端repo的變動同步到自己repo中。解決上述問題有兩個方案 在github網頁上通過反向pull r...
git 與原倉庫保持同步
git fetch git rebase 解決衝突 git add 衝突檔案 git rebase continue git push 參考 與原倉庫同步 git merge upstream master 同步 git push 檢視同步 git remote v git fetch upstre...
github fork專案和原專案同步
前提是自己已經設定好了git,並且配置了相應的許可權 然後使用git clone命令在本地轉殖自己 fork 的專案 git clone切換到自己之前轉殖的專案的路徑下，使用 git remote v 就可以看到當前專案的遠端倉庫配置origin fetch origin push 然後使用下面的命...