多活数据库
副本集由若干台服务器组成，分为三种角色：主服务器、副服务器、仲裁服务器。根据集群搭建的需求，仲裁服务器不是必需的。主服务器提供主要的对外读写的功能，副服务器作为备份。当主服务器不可用时，其余服务器根据投票选出一个新的主服务器，提供读写功能。因此，副本集可以提高集群的可用性。
分片(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的时候，它是在边界上面的，这种情况会加剧同一个用户流量在南北机房来回漂移的