全新Greenplum集羣傳輸工具—GPCOPY 2.1.0正式發佈

​GPCOPY是新一代的支持Greenplum集羣之間快速高效傳輸數據的工具。做爲Greenplum集羣數據傳輸的官方首選配套工具，GPCOPY除了具備高速穩定易用的特色外，還支持不一樣版本Greenplum集羣之間的傳輸（固然支持同版本之間的傳輸）。GPCOPY支持從GP4.3.x到GP 5.x、GP5.x到GP6.x、甚至GP4.3.x到GP6.x的數據傳輸。它也同時支持同等規模集羣和不等規模集羣之間的傳輸。另外GPCOPY還支持數據的校驗，支持事務，增長了數據傳輸的可靠性。GPCOPY目前尚未開源，最新版本2.1.0在3月9日正式發佈上線，作了不少方面的提高，能夠在官網https://network.pivotal.io/pr...。

新功能

1. 支持有外鍵的表、view以及有繼承關係的表 

GPCOPY是以表爲單位從源數據庫中把表的定義及表中數據複製到目標數據庫中。

首先GPCOPY拷貝表是支持事務的，若是再拷貝過程當中出錯則回滾。例如若是目標數據庫中不存在要拷貝的表，GPCOPY首先會建立目標表，而後把源表的數據拷貝到目標表，若是在拷貝數據的過程當中因爲某種緣由出錯了，則整個表的拷貝會回滾，被建立的目標表不會出如今目標數據庫中。

其次，GPCOPY支持並行拷貝多個表。使用--jobs能夠指定最多同時拷貝多少個表。--jobs的最大值是由運行GPCOPY機器的性能、源數據庫的性能、目標數據庫的性能等多個因素共同決定的。並行拷貝表使GPCOPY擁有出色的性能，可是數據庫中有些表並非相互獨立存在的，好比有外鍵的表、view、有繼承關係的表都須要依賴其它的表，此時並行拷貝表就會出現問題。在GPCOPY 2.1.0版本以前，這個問題一直存在，例若有兩個表：

CREATE TABLE t(id INT PRIMARY KEY,name TEXT)；

CREATE TABLE ft(item_id INT NOT NULL, foreign_id INT REFERENCES t(id))；

假設目標數據庫不存在這兩個表，使用GPCOPY 拷貝這個兩個表，jobs 的值設置爲2。GPCOPY會並行拷貝數據表」t」 和」ft」，而且拷貝「ft」表時會出現以下錯誤：

[CRITICAL]:-pq: relation "t" does not exist.

 Failed to  create table "testdb"."public".」ft

爲何會出現這個錯誤？

讓咱們先來看一下GPCOPY 在目標數據庫建立表」ft「的步驟：

1）在源數據庫使用pg_dump -t table_name 導出建立表」ft「的SQL。

2)  在目標數據庫執行這些SQL語句建立表」ft「。

CREATE TABLE ft (
    item_id integer NOT NULL,
    foreign_id integer
) DISTRIBUTED BY (item_id);
ALTER TABLE public.ft OWNER TO gpadmin;
--
-- Name: ft_foreign_id_fkey; Type: FK CONSTRAINT; Schema: public; Owner: gpadmin
--
ALTER TABLE ONLY ft
 ADD CONSTRAINT ft_foreign_id_fkey FOREIGN KEY (foreign_id) REFERENCES t(id);

上面是建立表「ft」的SQL，裏面會引用「t」這個表。可是GPCOPY是在目標端並行地、而且在不一樣事務中建立表「t」和表「ft」，此時表「t」並不存在，所以會出錯。

在GPCOPY 2.1.0中，咱們經過分析表之間的依賴關係，對於有外鍵的表、view、以及有繼承關係的表，先拷貝他們依賴的表。若是被依賴的表拷貝成功，再拷貝這些表；若是被依賴的表拷貝失敗，則這些表不會被拷貝。如上例所示，GPCOPY 2.1.0 會先拷貝表「t」，表「t」拷貝成功後再拷貝表「ft」。對於沒有依賴關係的表，咱們依舊並行地進行拷貝。

GPCOPY 2.1.0 作到了既能並行拷貝表的DDL和數據，又能處理表之間的依賴的關係。

2. 新增選項 dest-mapping-file

運行gpcopy --help能夠看到對該選項的說明：

Use the host to IP map file in case of destination cluster IP auto-resovling fails

意思是當GPCOPY遇到沒法解析HOSTNAME的時候，能夠把HOSTNAME對應的IP地址配置到一個文件中，經過dest-maping-file把該文件傳給GPCOPY。

GPCOPY何時須要解析HOSTNAME？須要解析誰的HOSTNAME？

接下來用上圖來解釋這兩個問題。

GPCOPY 在源數據庫和目標數據庫之間主要是經過segment到segment相互傳輸數據。源端和目標端的segment每每不在同一個host上，經過gpcopy_helper實現跨機器的數據傳輸。運行在源端segment上gpcopy_helper負責發送數據，運行在目標端segment上的gpcopy_helper負責接收數據。gpcopy_helper發送數據的時候，須要知道接收數據的gpcopy_helper的地址，即目標segment的IP地址。 

2.1.0版本以前GPCOPY 沒有dest-mapping-file這個選項，那麼它是怎麼獲取目標端segment IP地址的，以及存在什麼問題呢？

首先查詢目標數據庫中gp_segment_configuration 表，獲取segment的HOSTNAME 。源端不能直接使用該HOSTNAME，須要其對應的IP地址。因此GPCOPY會在在目標集羣的master上查詢該HOSTNAME對應的IP地址（GPCOPY已知目標端master的地址，master知道segment HOSTNAME對應的IP)。可是有時目標端master只配置了segment HOSTNAME對應的私有IP地址， 源數據庫和目標數據庫並不在一個集羣中，致使源端的gpcopy_helper和目標端的gpcopy_helper沒法通訊。

爲解決該問題，GPCOPY 2.1.0 增長了dest-mapping-file 選項，當GPCOPY經過以上方法沒法獲取segment公有IP的時候，用戶能夠經過配置文件設置；或者當目標端的segment沒有public IP的時候，能夠設置一個用來作數據轉發的IP地址。

GPCOPY 2.1.0 新增dest-mapping-file選項能夠幫助用戶解決源數據庫和目標數據庫之間的通訊問題。

3. 減小端口占用

如前面提到， GPCOPY 能夠同時運行多個job，每一個job 負責拷貝一個表。GPCOPY 2.1.0以前的版本，每一個目標表都有獨立的gpcopy_helper進程用來接收數據，每一個gpcopy_helper進程分別佔用不用的端口。所以會出現若是設置的job數量不少，則佔用的端口會過多的狀況。GPCOPY 2.1.0 實現了多個gpcopy_helper進程能夠複用同一個端口來接收數據，從而減小了端口資源的佔用。

4. 增長進度展現及統計信息

每一個表拷貝完成時，GPCOPY都會展現出當前的拷貝進度：總共多少表須要拷貝，已有多少表完成拷貝。

當全部表拷貝完成時，GPCOPY會如上圖同樣顯示本次拷貝總共花費的時間，總共傳輸的數據量及平均傳輸速度。

5. 優化命令行

2.1.0版本，GPCOPY 命令支持單字符的option。

架構

​GPCOPY的架構圖如上圖所示，大概包括三層：

1）最上層負責參數解析及獲取要拷貝的表的元數據，爲進行表拷貝作準備。

2）中間層即第二層負責分析表之間的依賴關係，生成拷貝依賴關係，並負責調度拷貝任務。

3）最底層也即第三層，負責一個表的拷貝。包括拷貝表的DDL、拷貝數據、數據驗證及對錶進行ANALYZE。

第一層比較好理解，不作過多解釋。第三層是拷貝一個表必須的，第二層是並行拷貝多個表所必須的，接下來將自底向上進行詳細介紹。

1. 拷貝一個表

• 拷貝DDL

目前GPCOPY基於pg_dump實現拷貝表的DDL。首先在源端使用pg_dump -t 導出源表的DDL，而後在目標數據庫執行該DDL來建立表，並對建立表涉及的schema、sequence 、權限等作了處理。

• 拷貝數據

把數據從源表拷貝到目標源有兩種模式，一種是master之間拷貝，另一種是segment之間拷貝。當數據量比較小的時候建議使用master拷貝數據，不然使用segment拷貝數據，模式選擇可參考 --on-segment-threshold 選項使用說明。

不管是哪式拷貝模式，主要的步驟大體以下：

1)使用copy 工具把數據從源表中導出。

2)而後gpcopy_helper把數據從源master/segment傳遞到目標端master/segment上

3)最後再使用copy工具把數據導入到目標表中。

當使用segment模式進行拷貝數據的時候，使用的是copy on segment命令將數據導入導出到segment上，可是該命令將數據導入到表的時候不支持重分佈。所以當數據在目標須要重分佈時候，使用臨時外部表代替copy 命令將數據導入表中。

• 驗證數據

該模塊用於驗證拷貝到目標表中的數據是否正確。有兩種數據驗證方法：md5xor 和 count。  md5xor是比較嚴格的數據驗證方法，會把源表和目標表中的每行數據都計算在內，所以該方法比較耗時。而count方法則相反，只簡單的對比源表和目標表中的數據條數，比較簡單也不嚴格。用戶可根據本身的需求選擇驗證數據或者不驗證，或者選擇不一樣的驗證方法。

• ANALYZE

gpdb中提供了ANALYZE命令用於更新數據庫中表的統計信息。GPCOPY中也提供在拷貝完一個數據表後自動調用ANALYZE命令的功能。

2. 並行拷貝多個表

在本文前面已經提到有外鍵的表、view、有繼承關係的表，這些類型的表不是獨立存在的，它們依賴於其它的表。這種依賴關係對於並行拷貝多個表形成了很大的困難。GPCOPY主要經過如下幾個模塊解決該問題。

• 生成表之間的拷貝依賴關係

對於數據庫，表之間的依賴關係有不少種，好比有外鍵的表是表中的某一列引用另一個表的一列，經過pg_constraint可獲取該依賴關係；view則是一個表依賴於另一個表或者多個表，經過pg_depend和pg_rewrite可獲取該依賴關係；有繼承關係的表（包括partition 表）則經過pg_inherits來獲取該依賴關係。但對於GPCOPY來說，只有一種依賴關係，即拷貝依賴關係：一個表依賴於另一個表，被依賴的表須要先拷貝。

該模塊經過查詢源數據庫的catalog，分析表之間不一樣的依賴關係，最終生成表之間的拷貝依賴關係。

• 調度器

調度器主要負責兩個工做：第一，保證表的拷貝順序符合表之間的依賴關係；第二，控制拷貝表的併發度。

怎麼才能使拷貝順序符合表之間的依賴關係？思路很簡單，沒有任何依賴的表或者其依賴的表所有拷貝完成，則調度拷貝該表，不然該表不會被調度。

• 生成報告

該模塊比較簡單，收集並行執行的表拷貝的結果，生成拷貝進度信息及彙總信息。

將來規劃

GPCOPY的官方文檔能夠參考https://gpdb.docs.pivotal.io/...。在接下來的版本，GPCOPY還會支持增量傳輸，進一步提升性能。也但願廣大用戶多多反饋，多提寶貴意見。