在DB2中部署Q Replication:包含哪些工作?

以下各節(jié)將介紹部署 q replication 所需的必要決策和操作,從規(guī)劃到系統(tǒng)設置和生產操作。需要執(zhí)行的操作包括: 1. 安裝前驗證和容量規(guī)劃,包括為 DB2 啟用復制 2. WebSphere MQ 和 Q Replication 許可的安裝和配置 3. 復制訂閱的定義;也就是說,您希望復制

以下各節(jié)將介紹部署 q replication 所需的必要決策和操作,從規(guī)劃到系統(tǒng)設置和生產操作。需要執(zhí)行的操作包括:

1. 安裝前驗證和容量規(guī)劃,包括為 DB2 啟用復制
2. WebSphere MQ 和 Q Replication 許可的安裝和配置
3. 復制訂閱的定義;也就是說,您希望復制哪些表?
4. 操作:開始和停止復制,處理中斷
5. 監(jiān)視、調節(jié)和故障排除,以便從解決方案獲得最大回報。

Q Replication 預安裝步驟和容量規(guī)劃

Q Replication 是一種日志捕獲/事務重放技術;也就是說,從 DB2 恢復日志中捕獲數據更改,并重構 SQL 語句,以便在目標上重放它們。 在目標上,出于 DB2 容量規(guī)劃和調節(jié)的目的,DB2 實例必須擁有足夠的容量來處理所復制的實際SQL 工作負載。一般而言,應用程序在源系統(tǒng)上所需的任何性能調節(jié)也適用于目標系統(tǒng)。

在源數據庫上,針對 DB2 的主要 Q Capture 活動是讀取日志,這一般不需要 DB2 調節(jié)。但是,您可能希望參閱DB2 信息中心中的針對 Linux、UNIX 和 Windows 的數據庫參數設置,了解調節(jié)建議,尤其在要復制的事務量特別大的時候。

CPU 需求

Q Capture 和 Q Apply 復制程序,以及 WebSphere MQ 都會為復制的 DB2 工作負載增加少量的開銷。

作為一條經驗規(guī)則,在目標上,對于將來自源數據庫的 DB2 更改應用到目標數據庫所需的 CPU 負載,Q Apply 和 WebSphere MQ 總共會為其增加 20% 到 25% 的開銷。也就是說,在目標上應用更改所需的 CPU 資源中,大約 75% 花在DB2 中,這相當于源系統(tǒng)上執(zhí)行這些相同的語句所需的 CPU 資源,所需 CPU 資源的大約 25% 花在 Q Apply 和 WebSphere MQ 中。來自 Q Apply 和 WebSphere MQ 的 CPU 開銷僅用在運行這些程序的成員上;在其他成員上的復制所產生的 CPU 開銷通常可忽略。對于來自包含大量成員的系統(tǒng)的大量復制的更改,專門分配一個成員在目標上運行 Q Apply 程序可能很有用。

在源系統(tǒng)上,在 4 個成員中的每一個成員都消耗其 50% 的 CPU 容量的大容量性能實驗中,Q Capture 程序會給運行它的成員增添大約 10% 的 CPU 開銷,用這筆開銷從所有其他成員捕獲更改。在其他成員上捕獲日志記錄的開銷可忽略不計。

一般而言,不同環(huán)境和工作負載的 CPU 需求有很大差別,建議您使用自己的應用進行測試。

磁盤空間需求

在目標上的 WebSphere MQ 接收隊列中暫存更改需要一定的磁盤空間。在最低限度上,此空間大小只需足夠處理可被復制的最大 DB2 事務即可,但該大小應該足夠存儲預計會在故障期間積累的更改量。例如,如果每秒復制 1000 行,其中每行平均 200 字節(jié),并且希望在目標數據庫關閉時將累積的更改保留 24 小時,那么您可以向目標系統(tǒng)上的接收隊列分配 1000 行 * 200 字節(jié)/行 * 3600 秒/小時 * 24 = 17.3GB 的空間。WebSphere MQ 消息頭有一個最低開銷,一般為每個復制的DB2 事務幾百個字節(jié),您可使用該開銷對估算結果進行舍入。但是,如果接收隊列填滿了,也不是問題。當復制空間不足時(無論是對于源隊列還是目標隊列),Q Capture 程序要么停止,要么會依據 qfull_retry_delay 和 qfull_num_retries 參數進入重試模式。 用于傳輸隊列的磁盤空間大小,只需足夠存儲可被復制的最大數據庫事務即可。

空間耗盡不是什么大問題。Q Replication 將讀取 DB2 日志的進度以及它已處理的 WebSphere MQ 消息的信息存儲在持久存儲中,所以復制流程的任何組件都可以隨時中斷(甚至突然中斷),不會丟失數據。

在本文中,我們對所有 DB2 和 WebSphere MQ 數據使用了相同的文件系統(tǒng),但是,為了實現(xiàn)最優(yōu)的性能,建議對 DB2 日志、DB2 數據、WebSphere MQ 日志和 WebSphere MQ 數據使用獨立的磁盤和文件系統(tǒng)。源系統(tǒng)上的 WebSphere MQ 日志需要的空間與可能在 XMITQ 中累積的消息量成正比;在目標上,它與 Q Apply 可同時應用的消息數量成正比。在這兩種情況下,它所需的空間都比 WebSphere MQ 數據小得多。一般而言,200 MB 就足以存儲 WebSphere MQ 日志了,除非您復制比此容量更大的單一 DB2 事務。

準備用于復制的數據庫

要準備好一個使用復制的數據庫,需要執(zhí)行以下操作:

1. 在另一個站點上對每個 DB2 數據庫進行編目,使 Q Apply 程序可在需要時遠程連接它,比如在初始表加載期間。我們通過別名對數據庫進行編目,比如站點 1 上的 QSAMPLE1 和站點 2 上的 QSAMPLE2。

2. 在數據庫上設置 LOGARCHMETH1=LOGRETAIN。不能使用循環(huán)的日志,因為可以重用一個仍需要用于復制的日志文件。

3. 調整您希望復制的表,以便啟用 DATA CAPTURE CHANGES。

Q Replication 安裝和配置

安裝和配置 Q Replication 涉及到以下步驟:

1. 并安裝 WebSphere MQ。
2. 創(chuàng)建 WebSphere MQ 對象。
3. 如果需要,請獲取一個 Q Replication 許可。
4. 初始化 shell 環(huán)境。
5. 創(chuàng)建用于 Q Replication 的控制表。

1. 下載并安裝 WebSphere MQ

參見附錄 2,了解下載和安裝 WebSphere MQ 的命令和說明。

2. 創(chuàng)建 WebSphere MQ 對象

我們需要創(chuàng)建隊列管理器、WebSphere MQ 隊列、通道和監(jiān)聽器、對于此任務,您需要知道運行 WebSphere MQ 的每個數據成員的 IP 主機名和 WebSphere MQ 使用的端口(默認為 1414 端口)。您還需要用于 WebSphere MQ 的共享文件系統(tǒng)的名稱,在我們的例子中,該名稱為站點 1 上的 /db2fs/data 和站點 2 上的 /db2fs/data2。

我們將使用與數據庫別名相同的名稱創(chuàng)建隊列管理器,即與站點 1 的 QSAMPLE1 和站點 2 的 QSAMPLE2 相同的名稱。 我們提供了一個 pureScale 實例的步驟,在另一個站點上重復這些步驟即可。

? 版權聲明
THE END
喜歡就支持一下吧
點贊8 分享