多活資料庫
副本集由若乾颱伺服器組成，分為三種角色：主伺服器、副伺服器、仲裁伺服器。根據集群搭建的需求，仲裁伺服器不是必需的。主伺服器提供主要的對外讀寫的功能，副伺服器作為備份。當主伺服器不可用時，其餘伺服器根據投票選出一個新的主伺服器，提供讀寫功能。因此，副本集可以提高集群的可用性。
分片(sharding)
分片主要是為減小高數據量和高吞吐量的資料庫應用對單機性能造成的壓力。將大的數據分片存儲在不同節點上，外部讀寫只操作相應的一個或一小部分節點，一次減少每個分片節點村春的數據量和處理的請求數 。
② 分布式資料庫和多活資料庫的區別
應該說數據的獨立性是資料庫的特點，與資料庫的分布式和集中式結構並無關系吧。
③ 異地多活實現教程，比如阿里，京東伺服器實現異地多活那種。
說難也難，說簡單也簡單。
資料庫主從賦值，網站負載均衡，兩台異地伺服器間有網路高速通道（帶寬跟內網似的），剩下的就等同於兩台內網機器互相容災了
④ 主要的通用網路安全技術有8種。不間斷電源保護屬於哪一種
異地多活災備或者UPS不斷電。
異地多活災備
阿里雲資料庫異地多活解決方案使用以下阿里雲核心產品，按照架構設計原則提供數據層多活解決方案。
DRDS
按照之前說的業務數據拆分的維度，阿里雲DRDS有兩種集群分別支持買家維度與賣家維度：
unit模式的DRDS集群：多地用戶分別在本地域讀寫本地域的數據，且本地域的數據會和中心數據做雙向同步。
模式的DRDS集群：此集群數據在中心資料庫寫，完成後全量同步到各個單元。需要注意的是，DRDS層面需要增加對數據寫入路由的判斷：如果是跨單元的寫，則判斷為非法操作並拋出異常，確保數據不會跨單元寫。
更多DRDS的介紹請參考分布式關系型資料庫DRDS一文。
DTS
數據復制是資料庫多活設計關鍵的一環，其中數據復制的正確性是第一位，同時效率也很關鍵。阿里雲DTS支持多重的check，避免循環復制（用事務表，或者thread_id方案），採用並行復制（串列的分發，沖突檢測，並行的執行）、大事務切割來保證最終一致性。
數據校驗也是關鍵的一環，阿里雲DTS通過全量校驗工具（TCP）和增量校驗工具（AMG）來保證實時/定時檢查中心和單元的數據准確性，確保線上數據的萬無一失。
更多的數據傳輸相關內容請參考數據傳輸服務一文。
HDM
阿里雲HDM提供了DRDS集群的搭建、同步鏈路的創建、多活的資料庫監控、數據校驗、集群擴縮容以及自動化的容災等服務，都可通過HDM完成，通過HDM實現了異地多活場景下資料庫的管理。
⑤ 雙活數據中心 是什麼
雙活數據中心指的是熱備份數據中心和冷備份中心。
1、在熱備份的情況下，只有主數據中心承擔用戶的業務，此時備數據中心對主數據中心進行實時的備份，備數據中心可以自動接管主數據中心的業務，用戶的業務不會中斷，所以也感覺不到數據中心的切換。
2、在冷備份的情況下，也是只有主數據中心承擔業務，但是備用數據中心不會對主數據中心進行實時備份，這時可能是周期性的進行備份或者乾脆不進行備份，如果主數據中心掛掉了，用戶的業務就會中斷。
(5)多活資料庫擴展閱讀：
雙活數據中心的優點：
能夠充分利用資源，避免了一個數據中心常年處於閑置狀態而造成浪費。通過資源整合，「雙活」數據中心的服務能力是雙倍的。雙活數據中心如果斷了一個數據中心，另外一個數據中心還在運行，對用戶來說是不可感知的。
雙活數據中心的建設三個條件：
雙活數據中心的建設首先要滿足三個條件，第一個是應用雙活，也就是說資料庫一定要實現雙活，第二個是網路要雙活，業務網路要保證能夠同時聯通兩個數據中心，第三個是數據要雙活，兩邊的數據要能夠實現被獨立使用。
參考資料來源：網路：數據中心
⑥ 各位大哥，領導安排小弟為現有報表平台的國產化替換做國產資料庫的調研，哪家比較靠譜
既然是報表平台應該就是OLAP了，數據量/規模有多大？對性能要求如何？
之前剛好作類似的調研，現階段來說分析型的MPP資料庫是比較好的選擇，擴展性、性能都比較好。
樓主提到的應該是國內最老牌的三家國產資料庫廠商都有對應的MPP分析型資料庫產品。就我個人來說南大通用GBase似乎更合適一點。
-------------------------------分割線-----------------------------------------
首先三家的OLAP產品：
人大金倉：
KADB，MPP分析型資料庫，主要在公安、網安、軍工等行業應用，缺點是集群規模擴展能力較差，最多支持50個節點，能夠支撐的數據規模有限。
武漢達夢：
DM TDD，實現了計算、日誌、存儲層分離的share-nothing架構，但管理和計算節點綁定，存在網路瓶頸、集群規模受限。同樣不支持超過100個節點的集群。
南大通用：
GBase 8a MPP，實現了類似於hadoop2.0的share-nothing聯邦架構，計算、管理節點集群靈活部署，擴展性很強並且更加靈活，並且集群規模最大支持超過300個節點，在金融行業應用案例也很多，包括農行、中行都有在用。
-------------------------------分割線-----------------------------------------
下面簡單介紹下GBase 8a MPP
南大通用大規模分布式並行資料庫集群系統，簡稱：GBase 8a MPP Cluster，它是在 GBase 8a 列存儲資料庫基礎上開發的一款 Share Nothing 架構的分布式並行資料庫集群，具備高性能、高可用、高擴展特性，可以為超大規模數據管理提供高性價比的通用計算平台，並廣泛地用於支撐各類數據倉庫系統、BI 系統和決策支持系統。
GBase 8a MPP Cluster 具備以下技術特徵：
1) 低硬體成本：完全使用 x86 架構的 PC Server，不需要昂貴的 Unix 伺服器和磁碟陣列；
2) 集群架構與部署：完全並行的 MPP + Share Nothing 的分布式架構，採用多活 Coordinator 節點、對等數據節點的兩級部署結構。 Coordinator 節點支持最多部署 32 個，數據節點支持最多部署 300個，數據量支持 15PB。
3) 海量數據分布壓縮存儲：可處理 PB 級別以上的結構化數據，採用hash 或 random 分布策略進行數據分布式存儲。同時採用先進的壓縮演算法，減少存儲數據所需的空間，可以將所用空間減少 1～20 倍，並相應地提高了 I/O 性能；
4) 數據載入高效性：基於策略的數據載入模式，集群整體載入速度隨節點數增加線性增長；
5) 高擴展、高可靠：支持集群節點的在線擴容和縮容，效率更高，對業務的影響更小。支持全量、增量的備份/恢復。
6) 高可用、易維護：數據通過最多 2 個副本提供冗餘保護，自動故障探測和管理，自動同步元數據和業務數據。提供圖形化監控工具和企業管理器等管理工具，簡化管理員對資料庫的管理工作；
7) 高並發：讀寫沒有互斥，支持簡化模式的 MVCC，支持數據的邊載入邊查詢，單個節點並發能力大於 300 用戶；
8) 行列轉換存儲：提供行列轉換存儲方案，從而提高了列存資料庫特殊查詢場景的查詢響應耗時；
9) 標准化：支持 SQL92 標准，支持 ODBC、JDBC、ADO.NET 等國際介面規范。
10) 數據節點多分片：在一個數據節點上可同時部署多個數據分片；單數據節點數據分片數量支持最多 32 個。
11) 靈活的數據分布：用戶可以按照業務場景的需求，自定義數據分布策略，從而在性能、可靠性和靈活性間獲得最佳匹配。
12) 非同步消息：Coornator 默認採用非同步消息模式與數據節點通信，支持高達 300 節點的集群規模。
⑦ 兩地三中心數據中心和同城雙活數據中心的區別
兩地三中心：是指同城雙中心加異地災備的一種商用容災備份解決方案。兩地是指同城、異地；三中心是指生產中心、同城容災中心、異地容災中心。結合近年國內出現的大范圍自然災害，以同城雙中心加異地災備中心的「兩地三中心」的災備模式也隨之出現，這一方案兼具高可用性和災難備份的能力。
雙活數據中心，所謂「雙活」或「多活」數據中心，區別於傳統數據中心和災備中心的模式，前者多個或兩個數據中心都處於運行當中，運行相同的應用，具備同樣的數據，能夠提供跨中心業務負載均衡運行能力，實現持續的應用可用性和災難備份能力，所以稱為「雙活」和「多活」；後者是生產數據中心投入運行，災備數據中心處在不工作狀態，只有當災難發生時，生產數據中心癱瘓，災備中心才啟動。
「雙活」數據中心最大的特點是：一、充分利用資源，避免了一個數據中心常年處於閑置狀態而造成浪費，通過資源整合，「雙活」數據中心的服務能力是翻倍的；二、「雙活」數據中心如果斷了一個數據中心，其業務可以迅速切換到另外一個正在運行的數據中心，切換過程對用戶來說是不可感知的。
⑧ 大型互聯網公司有哪些容災災備模式
災備的幾種方式：
1、主備鏡像
兩個數據中心伺服器部署完全一樣，每次網站發布都要在兩個數據中心同時發布，保證運行系統版本一致。兩個數據中心有主備之分，數據通過准實時的同步系統從主站不斷同步到備站。主站發生災害性故障導致完全不可用，則將域名解析切換到備站。這種方案純粹是為了容災。
2、業務互補，數據同步
如某網站美國機房和國內機房部署的服務在業務上互補，美國機房部署買家服務，國內機房部署賣家服務，海外用戶（主要是買家）訪問美國機房，國內用戶（主要是賣家）訪問國內機房。主要業務數據互相實時同步，因為數據在兩個機房同時寫入，可能會發生沖突。
3、主主鏡像
部署和發布模式與主備一樣，但是多個數據中心是同時啟用的，根據用戶地域將域名解析到不同的機房，數據實時同步。如新浪微博。
4、一寫多讀
數據寫入只發生在一個數據中心，但是為了加快地區用戶訪問，會將數據同步到其他數據中心供只讀訪問。這種方案適用於讀多寫少的網站。比如wikipedia。
引用鏈接：https://www.hu.com/question/21861839/answer/19548321
⑨ OpenStack平台的資料庫和存儲節點怎麼做冗餘
OpenStack其實有三個與存儲相關的組件，這三個組件被人熟知的程度和組件本身出現時間的早晚是相符的，按熟悉程度排列如下：
Swift——提供對象存儲 （Object Storage），在概念上類似於Amazon S3服務，不過swift具有很強的擴展性、冗餘和持久性，也兼容S3 API
Glance——提供虛機鏡像（Image）存儲和管理，包括了很多與Amazon AMI catalog相似的功能。（Glance的後台數據從最初的實踐來看是存放在Swift的）。
Cinder——提供塊存儲（Block Storage），類似於Amazon的EBS塊存儲服務，目前僅給虛機掛載使用。
（Amazon一直是OpenStack設計之初的假象對手和挑戰對象，所以基本上關鍵的功能模塊都有對應項目。除了上面提到的三個組件，對於AWS中的重要的EC2服務，OpenStack中是Nova來對應，並且保持和EC2 API的兼容性，有不同的方法可以實現）
⑩ 餓了么MySQL異地多活的數據雙向復制經驗談
轉載:餓了么MySQL異地多活的數據雙向復制經驗談（附PPT）
本文根據陳永庭老師在〖DAMS 2017中國數據資產管理峰會〗現場演講內容整理而成。
（點擊底部「閱讀原文」獲取陳永庭演講完整PPT）
講師介紹
陳永庭，餓了么框架工具部高級架構師，主要負責MySQL異地雙向數據復制，支撐餓了么異地多活項目。曾就職於WebEx、Cisco、騰訊等公司。
今天我主要分享餓了么多活的底層數據實施，會和大家介紹在整個多活的設計和實施過程中我們是怎麼處理異地數據同步的，而這個數據同步組件在我們公司內部稱之為DRC。
異地多活背景
在講DRC或者講數據復制之前，先跟大家回顧一下異地多活的背景。
去年我們在做多活調研的時候，整個公司所有的業務服務都是部署在北京機房，伺服器大概有四千多台，災備的機器是在雲端，都是虛擬機，大概有三千多台。當時我們峰值的業務訂單數量已經接近了千萬級別，但是基本上北京機房（IDC）已經無法再擴容了，也就是說我們沒有空餘的機架，沒有辦法添加新的伺服器了，必須要再建一個新的機房，於是我們在上海建一個新的機房，上海機房要在今年的4月份才會投入使用，所以需要在上海機房建成之後，異地多活項目能具備在生產環境上進行灰度。
異地多活的底層數據同步實施
這是異地多活的底層數據同步實施的一個簡單的概要圖，大家可以看到，我們有兩個機房，一個是北京機房，一個是上海機房。在這個時候，我們期望目標是北方所有的用戶請求、用戶流量全部進入北京機房，南方所有的用戶請求、用戶流量進入上海機房。困難的地方是，這個用戶有可能今天在北方，明天在南方，因為他在出差，還有就是存在一些區域在我們劃分南北shard的時候，它是在邊界上面的，這種情況會加劇同一個用戶流量在南北機房來回漂移的