Greenplum最佳實踐Note
-------------------------------------------------------
最佳實踐概述
GPDB是一個基于大規模并行處理(MPP)和shared-nothing架構的分析型資料庫。這種資料庫的資料模式與高度規範化的事務性SMP的資料庫顯著不同,支援具有大事實表和小次元表的Star或者雪花模式。
1.Greenplum Best Practice
*資料模型*
* 跨表關聯(JOIN)時字段使用相同的資料類型。
* 堆存儲和追加優化存儲(Append-Optimized,下稱 AO)
* 若表和分區表需要進行疊代式的批處理或者頻繁執行單個UPDATE、DELETE或INSERT操作,
* 若表和分區表需要并發執行 UPDATE、DELETE 或 INSERT 操作,使用堆存儲。
* 若表和分區表在資料初始加載後更新不頻繁,且僅以批處理方式插入資料,則使用 AO 存儲。
* 不要對 AO 表執行單個 INSERT、UPDATE 或 DELETE 操作。
* 不要對 AO 表執行并發批量 UPDATE 或 DELETE 操作,但可以并發執行批量 INSERT 操作。
*行列存儲*
* 若資料需要經常更新或者插入,則使用行存儲。
* 若需要同時通路一個表的很多字段,則使用行存儲。
* 對于通用或者混合型業務,建議使用行存儲。
* 若查詢通路的字段數目較少,或者僅在少量字段上進行聚合操作,則使用列存儲。
* 若僅常常修改表的某一字段而不修改其他字段,則使用列存儲。
*資料壓縮*
* 對于大 AO 表和分區表使用壓縮,以提高系統 I/O。
* 在字段級别配置壓縮。
* 考慮壓縮比和壓縮性能之間的平衡。
*資料分布Distribute*
為所有表定義分布政策:要麼定義分布鍵,要麼使用随機分布。不要使用預設分布方式。
* 優先選擇可均勻分布資料的單個字段做分布鍵。
* 不要選擇經常用于 WHERE 子句的字段做分布鍵。
* 不要使用日期或時間字段做分布鍵
* 分布鍵Distribute和分區鍵Partition不要使用同一字段。
* 對經常執行 JOIN 操作的大表,優先考慮使用關聯字段做分布鍵,盡量做到本地關聯,以提高性能。
* 資料初始加載後或者每次增量加載後,檢查資料分布是否均勻。
* 盡可能避免資料傾斜。
Comments:檢視資料分布:SELECT gp_segment_id,COUNT(1) FROM tablename GROUP BY gp_segment_id;
*記憶體管理*
* 設定 vm.overcommit_memory 為 2
* 不要為作業系統的頁設定過大的值
* 使用 gp_vmem_protect_limit 設定單個節點資料庫(Segment Database)可以為所有查詢分 配的最大記憶體量。
- 不要設定過高的 gp_vmem_protect_limit 值,也不要大于系統的實體記憶體。
- gp_vmem_protect_limit 的建議值計算公式為: (SWAP + (RAM * vm.overcommit_ratio)) * 0.9 / number_Segments_per_server
* 使用 statement_mem 控制節點資料庫為單個查詢配置設定的記憶體量。(注意該參數生效的前提是設定gpresqueue_memory_policy為auto,預設是eager_free)
* 使用資源隊列設定隊列允許的目前最大查詢數(ACTIVE_STATEMENTS)和允許使用的記憶體大小(MEMORY_LIMIT)。
- 不要使用預設的資源隊列,為所有使用者都配置設定資源隊列。 根據負載和時間段,設定和隊列實際需求相比對的優先級(PRIORITY)。 保證資源隊列的記憶體配額不超過 gp_vmem_protect_limit。
- 動态更新資源隊列配置以适應日常工作需要。
*資料分區*
* 隻為大表設定分區,不要為小表設定分區。
* 僅在根據查詢條件可以實作分區裁剪時使用分區表。
* 建議優先使用範圍(Range)分區,否則使用清單(List)分區。
* 根據查詢特點合理設定分區。
* 不要使用相同的字段即做分區鍵又做分布鍵。
* 不要使用預設分區。
* 避免使用多級分區;盡量建立少量的分區,每個分區的資料更多些。
* 通過查詢計劃的 EXPLAIN 結果來驗證查詢對分區表執行的是選擇性掃描 (分區裁剪)。
* 對于列存儲的表,不要建立過多的分區,否則會造成實體檔案過多:Physical files = Segments * Columns * Partitions。
*索引*
一般來說 GPDB 中索引不是必需的。
* 對于高基數(HIGH Cardinality-唯一值多)的列存儲表,如果需要周遊且查詢選擇性較高,則建立單列索引。
* 頻繁更新的列不要建立索引。
* 在加載大量資料之前删除索引,加載結束後再重新建立索引。
* 優先使用 B 樹索引。
* 不要為需要頻繁更新的字段建立位圖索引。
* 不要為唯一性字段,基數非常高或者非常低的字段建立位圖索引。
* 不要為事務性負載建立位圖索引。
* 一般來說不要索引分區表。如果需要建立索引,則選擇與分區鍵不同的字段。
*資源隊列*
* 使用資源隊列管理叢集的負載。
* 為所有角色定義适當的資源隊列。
* 使用 ACTIVE_STATEMENTS 參數限制隊列成員可以并發運作的查詢總數。
* 使用 MEMORY_LIMIT 參數限制隊列中查詢可以使用的記憶體總量。
* 不要設定所有隊列為 MEDIUM,這樣起不到管理負載的作用。
* 根據負載和時間段動态調整資源隊列。
_JDBC Driver_
使用Greenplum DataDirect JDBC Driver(相比postgresql jdbc driver,性能差。。。需研究)
2.BestPractice詳細内容
**2.0.系統監控**
監控工具 nmon_x86_64_centos7
**2.1.自建資源隊列**
建議通過greenplum command center的Administration->Manage resource queues選項操作。
自己建立資源隊列,系統預設的資源隊列pg_default,對記憶體參數沒有做出限制，會有記憶體溢出的風險
Comment:必須設定資源隊列,否則大資料量查詢很容易産生記憶體溢出異常
資源隊列具體參數設定:
ACTIVE_STATEMENTS:此參數限制隊列中同是執行的query數量,當query數量超過此值是則處于等待狀态。pg_default預設值是20。
MEMORY_LIMIT:此參數限制起源隊中所有活動query(參見ACTIVE_STATEMENTS參數)能使用的最大記憶體，不能超過實體記憶體，計算方法為
實體momery/機器的節點個數 x 0.9;
* 建立資源隊列
CREATE RESOURCE QUEUE ir_rq WITH(
ACTIVE_STATEMENTS=20,
MEMORY_LIMIT=1800M)
* 建立使用者
CREATE ROLE username with login ENCRYPTED PASSWORD RESOURCE QUEUE ir_rq;
*2.2.統計優化Vacuum*
greenplum4後版本支援壓縮表的插入删除和更新操作
GP删除資料是辨別删除,磁盤上的資料并沒有真正删除,是以該空間不可重用
官方建議Vacuum的執行周期是每晚.該政策需測試
* vacuum隻是簡單的回收空間且令其可以再次使用，沒有請求排它鎖，仍舊可以對表讀寫
* vacuum full執行更廣泛的處理，包括跨塊移動行，以便把表壓縮至使用最少的磁盤塊數目存儲。相對vacuum要慢，而且會請求排它鎖。
* 定期執行：在日常維護中，需要對資料字典定期執行vacuum，可以每天在資料庫空閑的時候進行。然後每隔一段較長時間（兩三個月）對系統表執行一次vacuum full，這個操作需要停機，比較耗時，大表可能耗時幾個小時。
* reindex:執行vacuum之後,最好對表上的索引進行重建
*2.2.1.Heap表*
Vacuum指令會讓标記删除資料占有空間變得可以被使用。參數具體如下
* FULL:回收空間并且對磁盤上的資料進行整理,類似磁盤碎片整理,耗時較長,并且鎖表。是以不建議執行該指令
* ANALYZE:更新統計資訊,查詢分析器生成更新的EXPLAIN Plan.
* table:預設的是目前資料庫下的所有表
* column:預設的目前表的所有列
*2.2.2.Append-Optimised追加優化*
greenplum 4.x 以後的appendonly表可以支援更新和删除操作，但是限制不能更新分布鍵distributeKey所在的列
Vacuum首先整理優化索引,接下來順序的在每個segment節點上執行優化,最後整理優化輔助表并更新統計資訊。在每個segment節點上操作如下:
1. 複制目前segment所有可見的資料行到一個新的segment,之後删除目前segment上的資料并且讓新segment上的資料變得可用
2. Vacuum不帶full參數,增删改查可以正常操作
3. Vacuum full指令,鎖表
4. gp_appendonly_compaction_threshold,控制Vacuum(without full)運作時是否進行表優化
壓縮系統設定
當一個查詢的結果過大溢出到硬碟時 采用gp_workfile_compress_algorithm 指定的參數壓縮，預設值none，可選值zlib，設定成zlib後，在密集型查詢系統中可提升10%-20%的效率
設定方法gpconfig -c gp_workfile_compress_algorithm -v zlib
**2.3.ANALYZE**
* 指令：analyze [talbe [(column,..)]]
* 收集表内容的統計資訊，以優化執行計劃。如建立索引後，執行此指令，對于随即查詢将會利用索引。
* 自動統計資訊收集
* 在postgresql.conf中有控制自動收集的參數gp_autostats_mode設定，gp_autostats_mode三個值：none、no_change、on_no_stats（預設）
* none：禁止收集統計資訊
* on change：當一條DML執行後影響的行數超過gp_autostats_on_change_threshold參數指定的值時，會執行完這條DML後再自動執行一個analyze 的操作來收集表的統計資訊。
* no_no_stats：當使用create talbe as select 、insert 、copy時，如果在目标表中沒有收集過統計資訊，那麼會自動執行analyze 來收集這張表的資訊。gp預設使用on_no_stats，對資料庫的消耗比較小，但是對于不斷變更的表，資料庫在第一次收集統計資訊之後就不會再收集了。需要人為定時執行analyze.
* 如果有大量的運作時間在1分鐘以下的SQL，你會發現大量的時間消耗在收集統計資訊上。為了降低這一部分的消耗，可以指定對某些列不收集統計資訊，如下所示：
1. create table test(id int, name text,note text);
上面是已知道表列note不需出現在join列上，也不會出現在where語句的過濾條件下，因為可以把這個列設定為不收集統計資訊：
2. alter table test alter note SET STATISTICS 0;
**2.4.兩種聚合方式**
* HashAggregate 根據group by字段後面的值算出hash值，并根據前面使用的聚合函數在記憶體中維護對應的清單，幾個聚合函數就有幾個數組。相同資料量的情況下，聚合字段的重複度越小，使用的記憶體越大。
* GroupAggregate 先将表中的資料按照group by的字段排序，在對排好序的資料進行全掃描，并進行聚合函數計算。消耗記憶體基本是恒定的。
* 選擇在SQL中有大量的聚合函數，group by的字段重複值比較少的時候，應該用groupaggregate
**2.5.JOIN關聯方式**
分為三類：hash join、nestloop join、merge join，在保證sql執行正确的前提下，規劃器優先采用hash join。
* hash join: 先對其中一張關聯的表計算hash值，在記憶體中用一個散清單儲存，然後對另外一張表進行全表掃描，之後将每一行與這個散清單進行關聯。
* nestedloop:關聯的兩張表中的資料量比較小的表進行廣播，如笛卡爾積：select * fromtest1，test2
* merge join:将兩張表按照關聯鍵進行排序，然後按照歸并排序的方式将資料進行關聯，效率比hash join差。full outer join隻能采用merge join來實作。
* 關聯的廣播與重分布解析P133，一般規劃器會自動選擇最優執行計劃。
* 有時會導緻重分布和廣播，比較耗時的操作
**2.6.Redistribute重分布**
一些sql查詢中，需要資料在各節點重新分布，受制于網絡傳輸、磁盤I/O，重分布的速度比較慢。
* 關聯鍵強制類型轉換
一般，表按照指定的分布鍵作hash分部。如果兩個表按照id:intege、id:numericr分布，關聯時，需要有一個表id作強制類型轉化，因為不同類型的hash值不一樣，因而導緻資料重分布。
* 關聯鍵與分部鍵不一緻
* group by、開窗函數、grouping sets會引發重分布
**2.7.資料Load政策**
_gpfdist/gpload_
- 使用 gpfdist 進行資料的加載和導出。
- 随着段資料庫個數的增加,并行性增加。
- 盡量将資料均勻地分布到多個 ETL 節點上。 将非常大的資料檔案切分成相同大小的塊,并放在盡量多的檔案系統上。
- 一個檔案系統運作兩個 gpfdist 執行個體。
- 在盡可能多的網絡接口上運作 gpfdsit。
- 使用 gp_external_max_segs 控制通路每個 gpfdist 伺服器的段資料庫的個數.建議gp_external_max_segs的值和gpfdist程序個數為偶數。
- 資料加載前删除索引;加載完後重建索引。
- 資料加載完成後運作 ANALYZE 操作。
- 資料加載過程中,設定 gp_autostats_mode 為 NONE,取消統計資訊的自動收集。 若資料加載失敗,使用 VACUUM 回收空間。
_COPY_
使用COPY指令前,删除Index和外鍵限制,事後運作VACUUM ANALYZE
**2.8.Greenplum Index**
-[sql_commands_create_index](http://gpdb.docs.pivotal.io/4320/ref_guide/sql_commands/CREATE_INDEX.html)
- GP不建議使用索引
- GP主要做快速有序地掃描（基于分區）
- 如果建立全局索引，資料分布機制和分區機制，會完全打亂索引。如果基于單個分區去建立索引，這個有點像阿裡的xxx，應該有一定效果吧
GP中索引的起作用的場景：
傳回1條或者很小的集合時
當可以使用index來替代全表掃描的查詢(append-optimized tables)
GP隻支援在使用者建立的表上建立索引，不支援GP依據分區建立的葉表上建立索引。建立的索引會被複制到各個葉表上。
Greenplum supports B-Tree, Bitmap, and GiST indexes.
- B-Tree indexes can be unique or not.
- Bitmap indexes are good useful when there are 100 to 100,000 distinct values (Bitmap indexes are best suited on columns for querying than updating).
- GiST (Generalized Search Tree) indexes are used to support PostGIS.
3.Data Modeling & Design-資料模型與設計
Greenplum資料模型設計:
- 确定和描述在資料倉庫中使用的資料模型與哪些資料可存儲在GP中.Identify and describe the data models used in data warehousing and describe how data is stored in Greenplum.
- 分布存儲資料在GP中,使用分布鍵(distribution key), 分區表(partitioning)與限制(constraints).Distribute and store data in Greenplum using a distribution key,partitioning,and constraints.
**3.1.Data Models-資料模型**
* Logical data model - Cube
* Enhanced logical data model - AggregateResult/View
* The physical data model - DBTable
Entity|Attribute|Relationship|Constraint
*A.Logical Data Models-邏輯Cube模型*
* Star Schema 星型模型
* Snowflake Schema 雪花模型
* Third Normal Form(3NF) 第三範式
Dimensional Approach in DW:Star and snowflake schemas are the most common in DW implementations.
*B.Physical Data Models-實體表模型*
* Select the best distribution key used for distributing data
* Check for data skew(資料傾斜)
* Identfy the benefits of partitioning a table and when to partition a table
* Determine partitioning candidates
* Select appropriate data type for your data
* Define constraints on tables and columns
**3.2.Table Compression**
Rules of Compression:
- Use compression on pretty large AO (append-optimized) and partitioned tables, to improve disk I/O across the system. It won’t help very much for smaller tables.
- The best practice is to set the column compression settings at the level where the data resides.
- New partitions added to a partitioned table do not automatically inherit compression defined at the table level; you must specifically define compression when you add new partitions.
- Data compression should never be used for data that is stored on a compressed file system.
**3.3.Data Distribution**
-Using the same distribution key for commonly joined tables
-Avoid redistribute motion for large tables
-Avoid broadcast motion for large tables
- 充分利用并行計算MPP
- 避免資料傾斜
- 為所有表要麼明确地指明其分布字段,要麼使用随機分布(DISTRIBUTED RANDOMLY)。不要使用預設方式。
- 分布字段的資料要麼是唯一值要麼基數很大。以避免資料傾斜
- 不要使用在WHERE會用到字段作為分布鍵
- 不要使用date/timestamp類型字段作為分布鍵
- 如果單個字段不能實作資料均勻分布,則考慮使用兩個字段做分布鍵。作為分布鍵的字段最
好不要超過兩個。
- 由于GP的随機分布不是round-robin,是以無法保證每個segment資料量相當。
- join關聯查詢、開窗函數等使用其關聯字段作為分布distribute鍵。這樣能讓表關聯JOIN資料都分布在同一segment,以減少redistribution motion.
**3.4.Check for Data Skew-檢查資料傾斜**
- 資料傾斜是影響性能的主要原因,是以驗證資料分布合理與否非常重要。使用gp_tookit可檢查傾斜
- 檢視某表是否分布不均: select gp_segment_id,count(*) from fact_table group by gp_segment_id
- 在segment一級，可以通過select gp_segment_id,count(*) from fact_table group by gp_segment_id的方式檢查每張表的資料是否均勻存放
- 在系統級,可以直接用df -h 或du -h檢查磁盤或者目錄資料是否均勻
- 檢視資料庫中資料傾斜的表
首先定義資料傾斜率為：最大子節點資料量/平均節點資料量。為避免整張表的資料量為空，同時對結果的影響很小，在平均節點資料量基礎上加上一個很小的值，SQL如下：
SELECT tabname, max(SIZE)/(avg(SIZE)+0.001) AS max_div_avg, sum(SIZE) total_size FROM (
SELECT gp_segment_id, oid::regclass tabname, pg_relation_size(oid) SIZE FROM gp_dist_random('pg_class')
WHERE relkind='r' AND relstorage IN ('a','h')
) t GROUP BY tabname ORDER BY max_div_avg DESC; gp_toolkit administrative schema offers two views:
- gp_toolkit.gp_skew_coefficients
- gp_toolkit.gp_skew_idle_fractions
**3.5.Partitions**
好的分區表政策可以提高系統Scan資料的性能。
- 隻為大表設定分區,不要為小表設定分區。一般超過1億以上的資料才值得分區。
- 每個Partition都是在每個segment中的一個獨立實體表
- 查詢所有分區要比查詢同樣資料在非分區表更慢
- 隻有當partition elimination能實作時才需要分區
- 盡量使用range partition(date類型或numeric類型)替代list partition
- 盡量讓預設分區為空。因為預設分區總是會被掃描,更重要的是很多情況下會導緻溢出而造成性能不佳。
- 禁止分布鍵與分區字段相同
- Partitioning Table
- Table Partitioning BP
- Distribution and Partition
4.GP系統參數
配置檔案 – postgresql.conf中,列出一些最常用的參數。
- shared_buffers：剛開始可以設定一個較小的值，比如總記憶體的15%，然後逐漸增加，過程中監控性能提升和swap的情況。
- effective_cache_size : 這個參數告訴PostgreSQL的優化器有多少記憶體可以被用來緩存資料，以及幫助決定是否應該使用索引。這個數值越大，優化器使用索引的可能性也越大。是以這個數值應該設定成shared_buffers加上可用作業系統緩存兩者的總量。通常這個數值會超過系統記憶體總量的50%。
- work_mem: 當PostgreSQL對大表進行排序時，資料庫會按照此參數指定大小進行分片排序，将中間結果存放在臨時檔案中，這些中間結果的臨時檔案最終會再次合并排序，是以增加此參數可以減少臨時檔案個數進而提升排序效率。當然如果設定過大，會導緻swap的發生，是以設定此參數時仍需謹慎，剛開始可設定為總記憶體的5%。
- temp_buffers: 即臨時緩沖區，擁有資料庫通路臨時資料，GP中預設值為1M，在通路比較到大的臨時表時，對性能提升有很大幫助。
- gp_fts_probe_threadcount: 設定ftsprobe線程數，此參數建議大于等于每台伺服器segments的數目。
- gp_hashjoin_tuples_per_bucket: 此參數越小，hash_tables越大，可提升join性能。
- gp_interconnect_setup_timeout: 此參數在負載較大的叢集中，應該設定較大的值。
- gp_vmem_protect_limit: 控制了每個段資料庫為所有運作的查詢配置設定的記憶體總量。如果查詢需要的記憶體超過此值，則會失敗。使用下面公式确定合适的值：
(swap + (RAM * vm.overcommit_ratio)) * 0.9 / number_of_Segments_per_server
例如，具有下面配置的段伺服器：
8GB 交換空間
128GB 記憶體
vm.overcommit_ratio = 50
8 個段資料庫
(8 + (128 * .5)) * 0.9 / 8 = 8 GB， 則設定gp_vmem_protect_limit為 8GB：
[VMemCalcPage](
https://greenplum.org/calc/)
- gp_statement_mem: 伺服器配置參數 gp_statement_mem 控制段資料庫上單個查詢可以使用的記憶體總量。如果語句需要更多記憶體，則會溢出資料到磁盤。用下面公式确定合适的值：
(gp_vmem_protect_limit * .9) / max_expected_concurrent_queries
例如，如果并發度為40， gp_vmeme_protect_limit為8GB，則 gp_statement_mem 為：
(8192MB * .9) / 40 = 184MB，每個查詢最多可以使用 184MB 記憶體，之後将溢出到磁盤。
- gp_workfile_limit_files_per_query:
如果為SQL查詢配置設定的記憶體不足，Greenplum資料庫會建立溢出檔案（也叫工作檔案）。在預設情況下，一個SQL查詢最多可以建立 100000 個溢出檔案，這足以滿足大多數查詢。
該參數決定了一個查詢最多可以建立多少個溢出檔案。0 意味着沒有限制。限制溢出檔案資料可以防止失控查詢破壞整個系統。
如果配置設定記憶體不足或者出現資料傾斜，則一個SQL查詢可能産生大量溢出檔案。如果超過溢出檔案上限，Greenplum資料庫報告如下錯誤：
ERROR: number of workfiles per query limit exceeded
在嘗試增大gp_workfile_limit_files_per_query前，先嘗試通過修改 SQL、資料分布政策或者記憶體配置以降低溢出檔案個數。
- max_connections: 最大連接配接數，Segment建議設定成Master的5-10倍。
- gpconfig -c optimizer -v off(根據查詢SQL特征決定查詢優化器的選擇)
set optimizer = on;(應用GPORCA)
GPORCA比較适合 1.分區表 2.子查詢 3.Join查詢
- [Configure Params](
https://gpdb.docs.pivotal.io/570/ref_guide/config_params/guc-list.html5.GP Performance Check
- gpcheckperf -f hostlist -d /data1 -d /data2 -r ds
- gpcheckperf -f hostfile_gpchecknet_ic1 -r N -d /tmp
- [gpcheckperf](
http://gpdb.docs.pivotal.io/4320/utility_guide/admin_utilities/gpcheckperf.html6.GP Functions
[GP Functions](
http://gpdb.docs.pivotal.io/4380/admin_guide/query/topics/functions-operators.htmlGPText：Greenplum全文檢索引擎
7.GP System Recovery
**Greenplum系統恢複**
要求:PrimarySegment超過一半節點處于Down狀态下,就需要啟動系統恢複機制
先切換到gpadmin賬号下, su - gpadmin
**7.1.gpstate**
Show detailed status information of a Greenplum Database system:
- gpstate -s
Do a quick check for down segments in the master host system catalog:
- gpstate -Q
Show information about mirror segment instances:
- gpstate -m
**7.2.gprecoverseg**
Rebalance your Greenplum Database system after a recovery by resetting all segments to their preferred role. First check that all segments are up and synchronized.
$ gpstate -m
$ gprecoverseg
$ gprecoverseg -r **7.3.Greenplum備份管理**
**7.3.1.gpcrondump(gp_dump)**
Back up a database:
gp_dump gpdb
Back up a database, and create dump files in a centralized location on all hosts:
gp_dump --gp-d=/home/gpadmin/backups gpdb **7.3.2.gpdbrestore(gp_restore)**
Restore a Greenplum database using backup files created by gp_dump:
gp_restore --gp-k=2005103112453 -d gpdb **7.4.Greenplum Segment更新**
**7.4.1.Segment擴充**
[參考資料](
https://yq.aliyun.com/articles/177**7.4.2.Segment異常恢複**
[gprecoversegInfo](
http://gpdb.docs.pivotal.io/4320/utility_guide/admin_utilities/gprecoverseg.html_A.磁盤異常,可替換磁盤(不添加Host)_
執行gprecoverseg -F (full recovery)
執行gprecoverseg -S (擷取預設配置檔案)
執行gprecoverseg -s Note: The -s and -S options are only used when you recover to existing hosts in the cluster. You cannot use these options
when you recover to a new host. To recover to a new host,use the -i and -o options.
_B.硬體異常,Host不可用,使用新Host_
When a segment host is not recoverable
[GP SegmentHost恢複方案](
https://yq.aliyun.com/articles/79165_C.重點步驟:_
備份GP伺服器搭建
重建立立叢集内部的ssh通信認證(替換之前主機ssh在know_hosts,添加新主機的ssh-key)
**7.4.3.删除Segment**
- [RemoveSegment](
http://blog.csdn.net/u011478909/article/details/52692280x.Ref
- [Greenplum offical](
http://greenplum.org/- [Greenplum最佳實踐](
https://wenku.baidu.com/view/2f36c23d30126edb6f1aff00bed5b9f3f90f721c.html- [Tuning Greenplum](
https://www.linkedin.com/pulse/tuning-greenplum-database-sandeep-katta-- [Data Modeling for Greenplum](
http://download.csdn.net/download/darkcatc/8474339