3.2 產品的推薦設置
3.2.1 硬件
最小推薦：
--對於一個複製集羣，使用至少3個節點保證可用性，如果一個節點失敗，詳見集羣策略
--每個節點需要有足夠的CPU，RAM，網絡，存儲能力處理你的工作負載，最少1個CPU和2GB RAM每個節點，對於更復雜的工作負載，更高的併發，更快的性能需要額外的資源。
最高性能：
--使用超過HDDs的SSDs
--使用更大的更多的節點，添加更多的CPU比添加更多的RAM更有用。
最高彈性：
--使用多的小節點，而不是少的大節點。當數據分散在更多的節點時，恢復失敗節點更快。
--使用區域配置增加複製因子從默認的3到5，可以在整個集羣應用或者在具體的數據庫或者表上應用
3.2.2 集羣策略
當集羣運行在至少一個節點時，每個副本在不同的節點，爲保證集羣進程，多數副本必須是可達的。因此：
--使用至少3個節點，保證即使一個節點失敗，多數副本是可達的。
--將節點運行在分散的機器上，cockroachDB的副本集跨節點，在一臺機器上運行多個節點，若機器故障，增加了數據丟失的風險，如果一個機器有多個磁盤或者SSDs，運行節點使用—store參數。
--配置奇數副本
--當副本通過數據中心，推薦明確定義節點在那個數據中心使用—locality參數，如果數據中心比其他的遠，需要明確定義推薦的多級loaclity。
--當副本跨數據中心，需要注意潛在數據中心之間交互對你的數據庫性能的影響，跨地域的集羣性能比在地理上集羣節點位置相近的性能更差。
3.2.3 時鐘同步
CockroachDB需要適當的時鐘同步保證數據的一致性，當節點檢測到時鐘與至少一半的節點不同步，即超過80%的最大容忍偏移（500ms*0.8），節點自發停止。避免違反序列化一致性而導致的讀陳舊數據和寫偏序，通過在每個節點運行NTP或者其他時鐘同步軟件防止時鐘漂移過大。
一個較爲罕見的現象是，在節點檢測前，一個節點的時鐘突然跳變，超過最大偏移。雖然可能性較少，但是確實可能發生，例如：當cockroachDB在VM中運行，VM管理程序決定將虛擬機移動到不同時間的其他硬件，這時，有一個小的窗口時間，節點時鐘不同步，節點自發停止。在這段時間客戶端有可能讀陳舊的數據或者寫陳舊的數據。
注意：推薦使用google的額外的NTP服務，
3.2.3 緩存和SQL內存大小
默認，每個節點內存大小和當前SQL內存大小爲128M，這些默認的配置是幫助開發測試的，使用者更可能是在同一臺主機上運行多個節點。當運行一個集羣產品，每個節點運行在一臺主機上，推薦增加配置：
--增加cache size提高讀性能
--增加SQL內存大小，增加允許連接客戶端的併發數（128M允許最大6200個併發連接），增加節點的容忍度對於內存進程的行處理使用order by/group by/distinct/joins/windows 函數
手動增加節點的node緩存和SQL內存大小，開始一個節點
cockroach start--cache=25% --max-sql-memory=25% <other start flags>
cochroachDB使用大量的打開文件描述符，需要注意：
--最小，文件描述符限制必須爲1956（每個存儲1700+256網絡），如果小於這個閾值，節點不會啓動
--推薦將文件描述符設置爲無限，否則，推薦的大小至少爲15000（10000每個存儲+5000個網絡），保證性能和集羣增長
--當文件描述符限制不夠非配給推薦數量，cockroachDB分配10000每個存儲，剩餘的給網絡。如果網絡小於256，cockroachDB分配256個給網絡，其他的切分給存儲。