精華)2020年8月31日 計算機操作系統 IO概念和五種IO模型">(精華)2020年8月31日 計算機操作系統 IO概念和五種IO模型
655
2025-03-31
發布、訂閱都在同一臺服務器
本地發布數據庫SQLTEST、發布表user_info
本地訂閱數據庫copy_for_sqltest
一、配置分發
配置分發是發布和訂閱前的基礎,沒有分發庫就不能完成。
快照文件夾:可以使用默認的,也可以自己自定義(F:\My_Code\MSSQL_ReplData)
分發數據庫名稱用默認的:distribution
二、快照發布
顧名思義,就像拍照片一樣,發布服務器對你要同步的表數據做一張快照,快照的數據集保存在本地的快照文件夾。
然后按照你設定的時間間隔向訂閱服務器傳輸快照集,訂閱服務器就按照收到的最新快照集完全覆蓋當前對應的表數據。
1、創建本地發布
可以看到,配置完分發后,在系統系數庫下生成了一個分發數據庫distribution
點擊新建發布后,彈出的窗體分別為
【新建發布向導】——下一步
【發布數據庫】——SQLTEST
2、發布類型
3、選擇發布的項目
本地發布選擇user_info表
如果要對user_info表數據做篩選的話,就添加篩選條件,我這里直接整表發布,下一步
4、快照代理
設置運行快照任務的時間
我設置成每天0:50:0就運行快照,將user_info表的快照集保存在快照文件夾
5、設置快照代理的安全設置
發布命名【本地快照發布】,完成發布的創建
6、快照發布創建成功
7、發布的作業自動生成
創建完本地的快照發布后,在代理作業中,你會發現,自動多出了一些作業。
本地快照文件夾中會發現生成了發布表user_info的快照集
8、創建本地訂閱
【新建訂閱向導】——下一步
【發布】——發布服務器就是本地服務器的名稱咯
9、分發代理位置——推送訂閱/請求訂閱
因為我這里是在同一臺服務器上執行復制,所以推送和訂閱都會是本地服務器,也就沒什么分別了。
10、訂閱服務器
選擇另外一個數據庫訂閱SQLTEST庫的user_info表
11、設置分發代理安全性
因為是同一臺服務器,所以這里不管選發布還是訂閱端運行代理,設置的賬號密碼都直接是本機賬號密碼即可。
12、 訂閱的同步計劃
連續運行就是訂閱一直推送/請求
定義計劃吧,可以定時執行:時間可以設置在上面的快照生成時間之后
如果要實時地執行同步每一個數據變化的同步的話,默認代理啟動時啟動就好,不需要實時的話就自定義計劃的實行時間。
但是,快照發布這種方式,最好不要設置實時,因為它的同步方式是一次性復制所有訂閱的表數據到訂閱服務器。
如果發布服務器每做一個小修改都對訂閱服務器整個表重新覆蓋一次,這會造成頻繁的頁面數據短時間無法顯示問題,因為在覆蓋期間,訂閱端的表數據會先整表刪除,再整表覆蓋。
所以,快照發布適合那些更新不頻繁,但每次更新都比較大的數據,選擇一個不多人使用的時段進行整表更新。
13、初始化訂閱
如果上面創建本地發布時沒有生成快照的話,這里選立即是不會運行成功的,因為沒有對應的快照給訂閱端覆蓋數據。
選哪個都沒關系,都可以后面再啟動發布生成快照,然后再啟動訂閱獲取快照
訂閱創建成功
14、訂閱的作業自動生成
可看到,繼發布的作業生成后,再創建訂閱后,訂閱的作業也自動生成了。
15、發布、訂閱創建后的運行測試
② 推送最新快照倒訂閱端
③ 看訂閱端數據庫copy_for_sqltest
已經把發布端的user_info表中整表的數據覆蓋了過來
④數據修改
這個,可以在發布的數據庫SQLTEST中,將發布表user_info中的數據進行修改,再重復①發布端生成最新快照、② 推送最新快照倒訂閱端這兩步,就可以把發布數據庫SQLTEST中的user_info表生成快照,推送到訂閱庫opy_for_sqltest,對訂閱庫的user_info表進行完全覆蓋。
(做定時任務也是相同的步驟:①發布端生成最新快照、② 推送最新快照倒訂閱端)
16、快照發布原理圖
做完上面的步驟,現在再來看這張圖,是不是瞬間完全理解了!
①、發布服務器,將要發布的表數據整個做一個快照,放在快照文件夾內
②、發布服務器將快照傳給訂閱服務器/訂閱服務器向發布服務器請求快照
③、快照文件夾中的快照傳到訂閱服務器上
三、事務發布
與快照發布的整表覆蓋到訂閱庫不同的是,事務發布是將發布端數據庫發生的事務日志(也就是數據庫的所有增刪改操作)發送到訂閱端,訂閱端再根據事務日志執行一遍發布端執行過的操作。
不過,傳輸事務流的基礎還是快照復制,訂閱端還是得有一個初始架構和數據(這個通過快照復制完成),然后訂閱端才能在初始架構和數據上,當發布服務器把每一次改動以日志的方式傳送到訂閱服務器后,進行數據同步。
1、新建發布
2、發布類型
3、選擇發布項目
這里看到,和之前快照發布不同的是,多了一個user_info_work表,而前邊的兩個表居然不能被選擇。
這是因為前面的兩個表都沒有主鍵,所以我復制了一個和user_info同樣的,但是帶主鍵的user_info_work表
4、快照代理
5、設置快照代理的安全設置
這里不同的是,快照代理下面還多出了一個日志讀取器代理(如果想設置別的代理,將下面的【使用快照代理的安全設置】勾選去掉就好)
6、事務發布創建成功
【向導操作】——下一步
【完成向導】——命名為【本地事務發布】
7、發布的作業自動生成
與快照發布不同的是,在作業處,多了一個沒有【本地事務發布】后綴名的任務。
右鍵該作業的屬性進去查看,發現這個是日志讀取的作業
8-14的步驟和快照發布一致
8、創建本地訂閱
【發布】——發布服務器就是本地服務器的名稱咯
9、分發代理位置——推送訂閱/請求訂
10、訂閱服務器
11、設置分發代理安全
12、訂閱的同步計劃
如果要實時地執行同步每一個數據變化的同步的話,默認代理啟動時啟動就好,不需要實時的話就自定義計劃的實行時間。
與快照發布不同的是,事務發布適合用于要求實時性較短的環境。
13、初始化訂閱
14、訂閱的作業自動生成
15、發布、訂閱創建后的運行測試
會發現,相比快照發布多了一個【查看日志讀取器代理狀態】
①對訂閱端生成初始架構和數據
這個一般在發布和訂閱創建完成時就已經同步完成了,如果查看訂閱端的數據庫發現表沒有同步的話,就重新生成一下初始數據的快照
快照生成后,再重新初始化一下,將其傳到訂閱端
或者也可以重新初始化所有訂閱,重新用最新快照初始化訂閱端的表,然后再啟動訂閱的同步狀態
②修改發布端的表數據
③讀取發布端的update的事務日志
④將事務日志傳到訂閱端
⑤查看
訂閱庫的copy_for_sqltest的表user_info_work,已經同步了發布庫的事務
16、事務發布原理圖
①、先通過快照復制,將發布服務器的基礎架構和表數據生成快照,傳到訂閱服務器,在訂閱服務形成初始架構
②、發布服務器的數據修改后(執行增刪改等操作),生成事務日志
③、分發服務器的日志讀取代理讀取發生改變的數據的事務日志,把這些事務日志保存在發布服務器的發布數據庫中。
④、分發服務器的分發代理程序 將分發數據庫中的事務日志分發到各個訂閱服務器上,然后把歷史記錄和錯誤記錄在分發數據庫中。
四、對等發布
五、合并發布
發布、訂閱在不同的服務器
服務器A、服務器B之間,A數據庫發布、B數據庫訂閱。
首先,A服務器和B服務器之間,數據庫可互連,這個可以從這篇文章看一下怎么實現【服務器間的數據庫遠程連接】
建立發布和訂閱的步驟和上面在同一服務器基本一致。
不同的是:創建訂閱時,推送訂閱和請求訂閱會有所不同。
一、推送訂閱
推送就是按照發布端設定的計劃,向訂閱端推送快照/事務日志。
(賬號填寫都是用發布服務器的)
二、請求訂閱
請求就是按照訂閱端設定的計劃,向發布端請求獲取快照/事務日志。
運行分發代理進程的賬戶是填寫的訂閱服務器的,連接的分發服務器是發布服務器的。
(如果分發服務器又建在另一臺服務器的話,又是另一種比較復雜的情況了…)
一些遇到的報錯問題
1、運行同步時報錯,無法讀取快照文件夾中的快照
處理:這是在快照文件夾中沒讀取到最新的快照集,我重新生成一個最新快照就解決了。
2、無法將【服務器名】配置為分發服務器
處理:這個就是被自己本地的殺毒軟件攔截了數據庫的進程,打開我的360,發現安全中心的攔截記錄出現一些攔截記錄。
設置360的防護彈窗模式,每次系統要執行什么操作時,都會彈窗提示,可以自己選擇拒絕還是允許
(說作為程序員還用360的話,我無F可說)
3、對快照路徑的訪問被拒絕
這個就是在不同服務器做發布、訂閱,請求訂閱時會遇到的問題。
因為請求訂閱是要在訂閱服務器去訪問發布服務器的快照文件夾,如果發布服務器的快照文件夾不共享給訂閱服務器的話,訂閱服務就無法同步到快照數據。
處理:這個就搜一下如何將文件夾共享給另一個服務就好,這里就不展示了。
4、無法連接到【服務器名】
在與SQL Server建立連接時出現與網絡相關的或特定于實例的錯誤。未找到或無法訪問服務器。請驗證…
處理:這個出現的時候,也是讓我弄了好久,最后在發布服務器的防火墻出站規則中發現,居然是1433端口被禁止了!
數據庫
版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。
版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。