数据库集群

1. 详细阐述数据库集群的分类 ？

  正确回答通过率：53.0% 

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 高难

数据库集群技术是将多台服务器联合起来组成集群来实现综合性能优于单个大型服务器的技术，这种技术不但能满足应用的需要，而且大幅度的节约了投资成本。数据库集群技术分属两类体系：基于数据库引擎的集群技术和基于数据库网关（中间件）的集群技术。在数据库集群产品方面，其中主要包括基于数据库引擎的集群技术的 Oracle RAC、Microsoft MSCS、IBM DB2UDB、Sybase ASE，以及基于数据库网关（中间件）的集群技术的 ICX-UDS 等产品。

一般来讲，数据库集群软件侧重的方向和试图解决的问题划分为三大类：
l 负载均衡集群（Load Balance Cluster，LBC）侧重于数据库的横向扩展，提升数据库的性能。l 高可用性集群（High Availability Cluster，HAC）侧重保证数据库应用持续不断。大部分的数据库集群侧重与此。l 高安全性集群（High Security Cluster，HSC）侧重于容灾。
只有 Oracle RAC 能实现以上三方面

可扩展的分布式数据库架构

(一) Oracle RAC：
其架构的最大特点是共享存储架构（Shared-storage），整个 RAC 集群是建立在一个共享的存储设备之上的，节点之间采用高速网络互联。OracleRAC 提供了非常好的高可用特性，比如负载均衡和应用透明切块（TAF），其最大的优势在于对应用完全透明，应用无需修改便可切换到RAC 集群。但是RAC 的可扩展能力有限，首先因为整个集群都依赖于底层的共享存储，所以共享存储的 I/O 能力和可用性决定了整个集群的可以提供的能力，对于 I/O 密集型的应用，这样的机制决定后续扩容只能是
Scale up（向上扩展）类型，对于硬件成本、开发人员的要求、维护成本都相对比较高。Oracle显然也意识到了这个问题，在 Oracle 的 MAA（Maximum Availability Architecture）架构中，采用 ASM 来整合多个存储设备的能力，使得 RAC 底层的共享存储设备具备线性扩展的能力，整个集群不再依赖于大型存储的处理能力和可用性。
RAC 的另外一个问题是，随着节点数的不断增加，节点间通信的成本也会随之增加，当到某个限度时，增加节点可能不会再带来性能上的提高，甚至可能造成性能下降。这个问题的主要原因是 Oracle RAC 对应用透明，应用可以连接集群中的任意节点进行处理，当不同节点上的应用争用资源时，RAC 节点间的通信开销会严重影响集群的处理能力。所以对于使用 ORACLE RAC 有以下两个建议：
l 节点间通信使用高速互联网络；l 尽可能将不同的应用分布在不同的节点上。
基于这个原因，Oracle RAC 通常在 DSS 环境（决策支持系统Decision Support System ，简称DSS)中可以做到很好的扩展性，因为 DSS 环境很容易将不同的任务分布在不同计算节点上，而对于 OLTP 应用（On-Line Transaction Processing联机事务处理系统），Oracle
RAC 更多情况下用来提高可用性，而不是为了提高扩展性。

(二) MySQL Cluster
MySQL cluster 和 Oracle RAC 完全不同，它采用 无共享架构Shared nothing（shared nothing architecture）。整个集群由管理节点(ndb_mgmd)，处理节点(mysqld)和存储节点(ndbd)组 成，不存在一个共享的存储设备。MySQL cluster 主要利用了 NDB 存储引擎来实现，NDB 存储引擎是一个内存式存储引擎，要求数据必须全部加载到内存之中。数据被自动分布在集群中的不同存 储节点上，每个存储节点只保存完整数据的一个分片(fragment)。同时，用户可以设置同一份数据保存在多个不同的存储节点上，以保证单点故障不会造
成数据丢失。MySQL cluster 主要由 3 各部分组成：
l SQL 服务器节点l NDB 数据存储节点l 监控和管理节点
这样的分层也是与 MySQL 本身把 SQL 处理和存储分开的架构相关系的。MySQL cluster 的优点在于其是一个分布式的数据库集群，处理节点和存储节点都可以线性增加，整个集群没有单点故障，可用性和扩展性都可以做到很高，更适合 OLTP 应用。但是它的问题在于：
l NDB（“NDB” 是一种“内存中”的存储引擎，它具有可用性高和数据一致性好的特点。）
存储引擎必须要求数据全部加载到内存之中，限制比较大，但是目前 NDB 新版本对此做了改进，允许只在内存中加 载索引数据，数据可以保存在磁盘上。l 目前的 MySQL cluster 的性能还不理想，因为数据是按照主键 hash 分布到不同的存储节点上，如果应用不是通过主键去获取数据的话，必须在所有的存储节点上扫描， 返回结果到处理节点上去处理。而且，写操作需要同时写多份数据到不同的存储节点上，对节点间的网络要求很高。
虽然 MySQL cluster 目前性能还不理想，但是 share nothing 的架构一定是未来的趋势，Oracle 接手 MySQL之后，也在大力发展 MySQL cluster，我对 MySQL cluster 的前景抱有很大的期待。

(三) 分布式数据库架构
MySQL 5 之后才有了数据表分区功能（Sharding）， Sharding 不是一个某个特定数据库软件附属的功能，而是在具体技术细节之上的抽象处理，是水平扩展(Scale Out，亦或横向扩展、向外扩展)的解决方案，其主要目的是为突破单节点数据库服务器的 I/O 能力限制，解决数据库扩展性问题。比如 Oracle 的 RAC 是采用共享存储机制，对于 I/O 密集型的应用，瓶颈很容易落在存储上，这样的机制决定后续扩容只能是 Scale Up（向上扩展） 类型，对于硬件成本、开发人员的要求、维护成本都相对比较高。Sharding
基本上是针对开源数据库的扩展性解决方案，很少有听说商业数据库进行 Sharding 的。目前业界的趋势基本上是拥抱 Scale Out，逐渐从 Scale Up 中解放出来。

Sharding 架构的优势在于，集群扩展能力很强，几乎可以做到线性扩展，而且整个集群的可用性也很高，部分节点故障，不会影响其他节点提供服务。Sharding 原理简单，容易实现，是一种非常好的解决数据库扩展性的方案。Sharding 并不是数据库扩展方案的银弹，也有其不适合的场景，比如处理事务型的应用它可能会造成应用架构复杂或者限制系统的功能，这也是它的缺陷所在。读写分离是架构分布式系统的一个重要思想。不少系统整体处理能力并不能同业务的增长保持同步，因此势必会带来瓶颈，单纯的升级硬件并不能一劳永逸。针对业务类型特点，需要从架构模式进行一系列的调整，比如业务模块的分割，数据库的拆分等等。集中式和分布式是两个对立的模式，不同行业的应用特点也决定了架构的思路。如互联网行业中一些门户站点，出于技术和成本等方面考虑，更多的采用开源的数据库产品(如 MYSQL)，由于大部分是典型的读多写少的请求，因此为
MYSQL 及其复制技术大行其道提供了条件。而相对一些传统密集交易型的行业，比如电信业、金融业等，考虑到单点处理能力和可靠性、稳定性等问题，可能更多的采用商用数据库，比如 DB2、Oracle 等。就数据库层面来讲，大部分传统行业核心库采用集中式的架构思路，采用高配的小型机做主机载体，因为数据库本身和主机强大的处理能力，数据库端一般能支撑业务的运转，因此，Oracle 读写分离式的架构相对MYSQL 来讲，相对会少。读写分离架构利用了数据库的复制技术，将读和 写分布在不同的处理节点上，从而达到提高可用性和扩展性的目的。最通常的做法是利用
MySQL Replication 技术，Master DB 承担写操作，将数据变化复制到多台 Slave DB上，并承担读的操作。这种架构适合 read-intensive 类型的应用，通过增加 Slave DB 的数量，读的性能可以线性增长。为了避免 Master DB 的单点故障，集群一般都会采用两台 Master DB 做双机热备，所以整个集群的读和写的可用性都非常高。除了 MySQL，Oracle 从 11g 开始提供 Active Standby 的功能，也具备了实现读写分离架构的基础。读写分离架构的缺陷在于，不管是
Master 还是 Slave，每个节点都必须保存完整的数据，如 果在数据量很大的情况下，集群的扩展能力还是受限于单个节点的存储能力，而且对于 Write-intensive 类型的应用，读写分离架构并不适合。

采用 Oracle 读写分离的思路，Writer DB 和 Reader DB 采用日志复制软件实现实时同步； Writer DB 负责交易相关的实时查询和事务处理，Reader DB 负责只读接入，处理一些非实时的交易明细,报表类的汇总查询等。同时，为了满足高可用性和扩展性等要求，对读写端适当做外延，比如 Writer DB 采用 HA 或者 RAC 的架构模式，目前，除了数据库厂商的 集群产品以外，解决数据库扩展能力的方法主要有两个：数据分片和读写分离。数据分片(Sharding)的原理就是将数据做水平切分，类似于
hash 分区 的原理，通过应用架构解决访问路由和Reader DB 可以采用多套，通过负载均衡或者业务分离的方式，有效分担读库的压力。

对于 Shared-nothing 的数据库架构模式，核心的一个问题就是读写库的实时同步；另外，虽然 Reader DB只负责业务查询，但并不代表数据库在功能上是只读的。只读是从应用角度出发，为了保证数据一致和冲突考虑，因为查询业务模块可能需要涉及一些中间处理，如果需要在数据库里面处理(取决与应用需求和设计)，所以Reader DB 在功能上仍然需要可写。下面谈一下数据同步的技术选型问题：

能实现数据实时同步的技术很多，基于 OS 层(例如 VERITAS VVR)，基于存储复制(中高端存储大多都支持)，基于应用分发或者基于数据库层的技术。因为数据同步可能并不是单一的 DB 整库同步，会涉及到业务数据选择以及多源整合等问题，因此 OS 复制和存储复制多数情况并不适合做读写分离的技术首选。基于日志的 Oracle 复制技术，Oracle 自身组件可以实现，同时也有成熟的商业软件。选商业的独立产品还是 Oracle 自身的组件功能，这取决于多方面的因素。比如团队的相应技术运维能力、项目投入成本、业务系统的负载程度等。

采用 Oracle 自身组件功能，无外乎 Logical Standby、Stream 以及 11g 的 Physical Standby(Active Data Guard)，对比来说，Stream 最灵活，但最不稳定，11g Physical Standby 支持恢复与只读并行，但由于并不是日志的逻辑应用机制，在读写分离的场景中最为局限。如果技术团队对相关技术掌握足够充分，而选型方案的处理能力又能支撑数据同步的要求，采用 Oracle 自身的组件完全可行。选择商业化的产品，更多出于稳定性、处理能力等考虑。市面上成熟的
Oracle 复制软件也无外乎几种，无论是老牌的 Shareplex，还是本土 DSG 公司的 RealSync 和九桥公司的 DDS，或是 Oracle 新贵 Goldengate，都是可供选择的目标。随着 GoldenGate 被 Oracle 收购和推广，个人认为 GoldenGate 在容灾、数据分发和同步方面将大行其道。当然，架构好一个可靠的分布式读写分离的系统，还需要应用上做大量设计

2. 数据库为什么要做集群？

 正确回答通过率：84.0% 

[ 详情 ] 推荐指数： ★★★★ 试题难度： 初级

随着经济的高速发展，企业规模的迅猛扩张，企业用户的数量、数据量的爆炸式增长，对数据库提出了严峻的考验。对于所有的数据库而言，除了记录正确的处理结果之外，还面临着以下几方面的挑战。
如何提高处理速度，实现数据库的均衡负载。
如何保证数据库的可用性、数据安全性、以及如何实现数据集群可扩性。
怎么综合解决这些问题成为众多企业关注的焦点。
在数据库上，组建集群也是同样的道理，主要有以下几个原因：
1、伴随着企业的成长，业务量提高，数据库的访问量和数据量快速增长，其处理能力和计算速度也相应增大，使得单一的设备根本无法承担。
2、在以上情况下，若扔掉现有设备，做大量的硬件升级，势必造成现有资源的浪费，而且下一次业务量提升时，又将面临再一次硬件升级的高额投入。于是，人们希望通过几个中小型服务器组建集群，实现数据库的负载均衡及持续扩展；在需要更高数据库处理速度时，只要简单的增加数据库服务器就可以得到扩展。
3、数据库作为信息系统的核心，起着非常重要的作用，单一设备根本无法保证系统的下持续运行，若发生系统故障，将严重影响系统的正常运行，甚至带来巨大的经济损失。于是，人们希望通过组建数据库集群，实现数据库的高可用，当某节点发生故障时，系统会自动检测并转移故障节点的应用，保证数据库的持续工作。
4、企业的数据库保存着企业的重要信息，一些核心数据甚至关系着企业的命脉，单一设备根本无法保证数据库的安全性，一旦发生丢失，很难再找回来。于是，人们希望通过组建数据库集群，实现数据集的冗余，通过备份数据来保证安全性。

3. 数据库集群有哪些分类 ？

 正确回答通过率：79.0% 

[ 详情 ] 推荐指数： ★★★★ 试题难度： 初级

数据库集群技术是将多台服务器联合起来组成集群来实现综合性能优于单个大型服务器的技术，这种技术不但能满足应用的需要，而且大幅度的节约了投资成本。数据库集群技术分属两类体系：基于数据库引擎的集群技术和基于数据库网关（中间件）的集群技术。在数据库集群产品方面，其中主要包括基于数据库引擎的集群技术的 Oracle RAC、Microsoft MSCS、IBM DB2UDB、Sybase ASE，以及基于数据库网关（中间件）的集群技术的 ICX-UDS 等产品。

一般来讲，数据库集群软件侧重的方向和试图解决的问题划分为三大类：

负载均衡集群（LOAD BALANCE CLUSTER，LBC）侧重于数据库的横向扩展，提升数据库的性能。
高可用性集群（HIGH AVAILABILITY CLUSTER，HAC）侧重保证数据库应用持续不断。大部分的数据库集群侧重与此。
高安全性集群（HIGH SECURITY CLUSTER，HSC）侧重于容灾。
只有 ORACLE RAC 能实现以上三方面

4. 请简述主流的分布式可扩展分布式数据库集群 ？

  正确回答通过率：52.0% 

[ 详情 ] 推荐指数： ★★★★ 试题难度： 中级

【Oracle RAC】
Oracle RAC架构的最大特点是共享存储架构（SHARED-STORAGE），整个 RAC 集群是建立在一个共享的存储设备之上的，节点之间采用高速网络互联。OracleRAC 提供了非常好的高可用特性，比如负载均衡和应用透明切块（TAF），其最大的优势在于对应用完全透明，应用无需修改便可切换到RAC 集群。但是RAC 的可扩展能力有限，首先因为整个集群都依赖于底层的共享存储，所以共享存储的 I/O 能力和可用性决定了整个集群的可以提供的能力，对于 I/O 密集型的应用，这样的机制决定后续扩容只能是 Scale up（向上扩展）类型，对于硬件成本、开发人员的要求、维护成本都相对比较高。Oracle显然也意识到了这个问题，在 Oracle 的 MAA（Maximum Availability Architecture）架构中，采用 ASM 来整合多个存储设备的能力，使得 RAC 底层的共享存储设备具备线性扩展的能力，整个集群不再依赖于大型存储的处理能力和可用性。
RAC 的另外一个问题是，随着节点数的不断增加，节点间通信的成本也会随之增加，当到某个限度时，增加节点可能不会再带来性能上的提高，甚至可能造成性能下降。这个问题的主要原因是 Oracle RAC 对应用透明，应用可以连接集群中的任意节点进行处理，当不同节点上的应用争用资源时，RAC 节点间的通信开销会严重影响集群的处理能力。所以对于使用 ORACLE RAC 有以下两个建议：
节点间通信使用高速互联网络；
尽可能将不同的应用分布在不同的节点上。
基于这个原因，Oracle RAC 通常在 DSS 环境（决策支持系统Decision Support System ，简称DSS)中可以做到很好的扩展性，因为 DSS 环境很容易将不同的任务分布在不同计算节点上，而对于 OLTP 应用（On-Line Transaction Processing联机事务处理系统），Oracle RAC 更多情况下用来提高可用性，而不是为了提高扩展性。

【MySQL Cluster】
MySQL Cluster 和 Oracle RAC 完全不同，它采用无共享架构Shared nothing（shared nothing architecture）。整个集群由管理节点(NDB_MGMD)，处理节点(MYSQLD)和存储节点(ndbd)组 成，不存在一个共享的存储设备。MySQL Cluster 主要利用了 NDB 存储引擎来实现，NDB 存储引擎是一个内存式存储引擎，要求数据必须全部加载到内存之中。数据被自动分布在集群中的不同存 储节点上，每个存储节点只保存完整数据的一个分片(fragment)。同时，用户可以设置同一份数据保存在多个不同的存储节点上，以保证单点故障不会造成数据丢失。MySQL Cluster 主要由 3 各部分组成：
SQL 服务器节点
NDB 数据存储节点
监控和管理节点
这样的分层也是与 MySQL 本身把 SQL 处理和存储分开的架构相关系的。MySQL Cluster 的优点在于其是一个分布式的数据库集群，处理节点和存储节点都可以线性增加，整个集群没有单点故障，可用性和扩展性都可以做到很高，更适合 OLTP 应用。但是它的问题在于：
NDB（“NDB” 是一种“内存中”的存储引擎，它具有可用性高和数据一致性好的特点。） 存储引擎必须要求数据全部加载到内存之中，限制比较大，但是目前 NDB 新版本对此做了改进，允许只在内存中加 载索引数据，数据可以保存在磁盘上。
目前的 MySQL Cluster 的性能还不理想，因为数据是按照主键 hash 分布到不同的存储节点上，如果应用不是通过主键去获取数据的话，必须在所有的存储节点上扫描， 返回结果到处理节点上去处理。而且，写操作需要同时写多份数据到不同的存储节点上，对节点间的网络要求很高。
虽然 MySQL Cluster 目前性能还不理想，但是 share nothing 的架构一定是未来的趋势，Oracle 接手 MySQL之后，也在大力发展 MySQL Cluster，期待 MySQL Cluster 能在未来有好的发展。

5. 简述什么是分布式数据架构 ？

 正确回答通过率：52.0% 

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 中级

MySQL 5 之后才有了数据表分区功能（Sharding）， Sharding 不是一个某个特定数据库软件附属的功能，而是在具体技术细节之上的抽象处理，是水平扩展(Scale Out，亦或横向扩展、向外扩展)的解决方案，其主要目的是为突破单节点数据库服务器的 I/O 能力限制，解决数据库扩展性问题。比如 Oracle 的 RAC 是采用共享存储机制，对于 I/O 密集型的应用，瓶颈很容易落在存储上，这样的机制决定后续扩容只能是 Scale Up（向上扩展） 类型，对于硬件成本、开发人员的要求、维护成本都相对比较高。Sharding 基本上是针对开源数据库的扩展性解决方案，很少有听说商业数据库进行 Sharding 的。目前业界的趋势基本上是拥抱 Scale Out，逐渐从 Scale Up 中解放出来。

Sharding 架构的优势在于，集群扩展能力很强，几乎可以做到线性扩展，而且整个集群的可用性也很高，部分节点故障，不会影响其他节点提供服务。Sharding 原理简单，容易实现，是一种非常好的解决数据库扩展性的方案。Sharding 并不是数据库扩展方案的银弹，也有其不适合的场景，比如处理事务型的应用它可能会造成应用架构复杂或者限制系统的功能，这也是它的缺陷所在。读写分离是架构分布式系统的一个重要思想。不少系统整体处理能力并不能同业务的增长保持同步，因此势必会带来瓶颈，单纯的升级硬件并不能一劳永逸。针对业务类型特点，需要从架构模式进行一系列的调整，比如业务模块的分割，数据库的拆分等等。集中式和分布式是两个对立的模式，不同行业的应用特点也决定了架构的思路。如互联网行业中一些门户站点，出于技术和成本等方面考虑，更多的采用开源的数据库产品(如 MYSQL)，由于大部分是典型的读多写少的请求，因此为 MYSQL 及其复制技术大行其道提供了条件。而相对一些传统密集交易型的行业，比如电信业、金融业等，考虑到单点处理能力和可靠性、稳定性等问题，可能更多的采用商用数据库，比如 DB2、ORACLE 等。就数据库层面来讲，大部分传统行业核心库采用集中式的架构思路，采用高配的小型机做主机载体，因为数据库本身和主机强大的处理能力，数据库端一般能支撑业务的运转，因此，Oracle 读写分离式的架构相对MYSQL 来讲，相对会少。读写分离架构利用了数据库的复制技术，将读和 写分布在不同的处理节点上，从而达到提高可用性和扩展性的目的。最通常的做法是利用 MySQL Replication 技术，Master DB 承担写操作，将数据变化复制到多台 Slave DB上，并承担读的操作。这种架构适合 read-intensive 类型的应用，通过增加 Slave DB 的数量，读的性能可以线性增长。为了避免 Master DB 的单点故障，集群一般都会采用两台 Master DB 做双机热备，所以整个集群的读和写的可用性都非常高。除了 MySQL，ORACLE 从 11G 开始提供 Active Standby 的功能，也具备了实现读写分离架构的基础。读写分离架构的缺陷在于，不管是 Master 还是 Slave，每个节点都必须保存完整的数据，如 果在数据量很大的情况下，集群的扩展能力还是受限于单个节点的存储能力，而且对于 Write-intensive 类型的应用，读写分离架构并不适合。 采用 Oracle 读写分离的思路，Writer DB 和 Reader DB 采用日志复制软件实现实时同步； Writer DB 负责交易相关的实时查询和事务处理，Reader DB 负责只读接入，处理一些非实时的交易明细,报表类的汇总查询等。同时，为了满足高可用性和扩展性等要求，对读写端适当做外延，比如 Writer DB 采用 HA 或者 RAC 的架构模式，目前，除了数据库厂商的 集群产品以外，解决数据库扩展能力的方法主要有两个：数据分片和读写分离。数据分片(Sharding)的原理就是将数据做水平切分，类似于 hash 分区 的原理，通过应用架构解决访问路由和Reader DB 可以采用多套，通过负载均衡或者业务分离的方式，有效分担读库的压力。

对于 Shared-nothing 的数据库架构模式，核心的一个问题就是读写库的实时同步；另外，虽然 Reader DB只负责业务查询，但并不代表数据库在功能上是只读的。只读是从应用角度出发，为了保证数据一致和冲突考虑，因为查询业务模块可能需要涉及一些中间处理，如果需要在数据库里面处理(取决与应用需求和设计)，所以Reader DB 在功能上仍然需要可写。下面谈一下数据同步的技术选型问题：

能实现数据实时同步的技术很多，基于 OS 层(例如 VERITAS VVR)，基于存储复制(中高端存储大多都支持)，基于应用分发或者基于数据库层的技术。因为数据同步可能并不是单一的 DB 整库同步，会涉及到业务数据选择以及多源整合等问题，因此 OS 复制和存储复制多数情况并不适合做读写分离的技术首选。基于日志的 Oracle 复制技术，Oracle 自身组件可以实现，同时也有成熟的商业软件。选商业的独立产品还是 Oracle 自身的组件功能，这取决于多方面的因素。比如团队的相应技术运维能力、项目投入成本、业务系统的负载程度等。

采用 Oracle 自身组件功能，无外乎 Logical Standby、Stream 以及 11g 的 Physical Standby(Active Data Guard)，对比来说，Stream 最灵活，但最不稳定，11g Physical Standby 支持恢复与只读并行，但由于并不是日志的逻辑应用机制，在读写分离的场景中最为局限。如果技术团队对相关技术掌握足够充分，而选型方案的处理能力又能支撑数据同步的要求，采用 Oracle 自身的组件完全可行。选择商业化的产品，更多出于稳定性、处理能力等考虑。市面上成熟的 Oracle 复制软件也无外乎几种，无论是老牌的 Shareplex，还是本土 DSG 公司的 RealSync 和九桥公司的 DDS，或是 Oracle 新贵 Goldengate，都是可供选择的目标。随着 GoldenGate 被 Oracle 收购和推广，个人认为 GoldenGate 在容灾、数据分发和同步方面将大行其道。当然，架构好一个可靠的分布式读写分离的系统，还需要应用上做大量设计，不在本文讨论范围内。

6. 简述MySQL的高可用方案 ？

  正确回答通过率：58.0% 

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 中级

大致有6种方案
MySQL 官方提供的方案
MySQL Replication
MySQL Fabirc
MySQL Cluster

第三方方案
MMM (Master Replication Manager for MySQL)
依托硬件的方案
心跳检测+SAN共享存储
心跳检测+DRDB磁盘复制

7. 简述MySQL Replication集群方案 ？

  正确回答通过率：59.0% 

[ 详情 ] 推荐指数： ★★★★ 试题难度： 高难

mysql复制（MySQL Replication），是mysql自带的功能。
主从复制是通过重放binlog实现主库数据的异步复制。即当主库执行了一条sql命令，那么在从库同样的执行一遍，从而达到主从复制的效果。
MySQL Replication是一主多从的结构，主要目的是实现数据的多点备份（没有故障自动转移和负载均衡）。
相比于单个的mysql，一主多从下的优势如下：

1.读写分离，负载均衡
如果让后台读操作连接从数据库，让写操作连接主数据库，能起到读写分离的作用，这个时候多个从数据库可以做负载均衡。
2.热备份
可以在某个从数据库中暂时中断复制进程，来备份数据，从而不影响主数据的对外服务（如果在master上执行backup，需要让master处于readonly状态，这也意味这所有的write请求需要阻塞）。

就各个集群方案来说，其优势为：
主从复制是mysql自带的，无需借助第三方。
数据被删除，可以从binlog日志中恢复。
配置较为简单方便。

其劣势为：
从库要从binlog获取数据并重放，这肯定与主库写入数据存在时间延迟，因此从库的数据总是要滞后主库。
对主库与从库之间的网络延迟要求较高，若网络延迟太高，将加重上述的滞后，造成最终数据的不一致。
单点故障问题：单一的主节点挂了，将不能对外提供写服务。

8. 简述MySQL Fabirc集群方案 ？

  正确回答通过率：56.0% 

[ 详情 ] 推荐指数： ★★★ 试题难度： 中级

mysql官方提供的，这是在MySQL Replication的基础上，增加了故障检测与转移，自动数据分片功能。
不过依旧是一主多从的结构
MySQL Fabirc只有一个主节点，区别是当该主节点挂了以后，会从从节点中选择一个来当主节点。
就各个集群方案来说，其优势为：
mysql官方提供的工具，无需第三方插件。
数据被删除，可以从binlog日志中恢复。
单点故障问题：主节点挂了以后，能够自动从从节点中选择一个来当主节点，不影响持续对外提供写服务。
其劣势为：
从库要从binlog获取数据并重放，这肯定与主库写入数据存在时间延迟，因此从库的数据总是要滞后主库。
对主库与从库之间的网络延迟要求较高，若网络延迟太高，将加重上述的滞后，造成最终数据的不一致。
事务及查询只支持在同一个分片内，事务中更新的数据不能跨分片，查询语句返回的数据也不能跨分片。
节点故障恢复30秒或更长（采用InnoDB存储引擎的都这样）。
分片：分片可以简单定义为将大数据库分布到多个物理节点上的一个分区方案。每一个分区包含数据库的某一部分，称为一个片
分区：分区则是把一张表的数据分成 N 多个区块，这些区块可以在同一个磁盘上，也可以在不同的磁盘上。

9. 简述MySQL Cluster 集群方案 ？

  正确回答通过率：67.0% 

[ 详情 ] 推荐指数： ★★ 试题难度： 中级

mysql官方提供的，多主多从结构

就各个集群方案来说，其优势为：

mysql官方提供的工具，无需第三方插件。
多个主节点，没有单点故障的问题，节点故障恢复通常小于1秒。
负载均衡优秀，可同时用于读操作、写操作都都密集的应用，也可以使用SQL和NOSQL接口访问数据。
高可用性和可伸缩性
可以自动切分数据，方便数据库的水平拓展
能跨节点冗余数据（其数据集并不是存储某个特定的MySQL实例上，而是被分布在多个Data Nodes中，即一个table的数据可能被分散在多个物理节点上，任何数据都会在多个Data Nodes上冗余备份。任何一个数据变更操作，都将在一组Data Nodes上同步，以保证数据的一致性）。
其劣势为：

架构模式和原理很复杂。
只能使用存储引擎 NDB ，与平常使用的InnoDB 有很多明显的差距，可能会导致日常开发出现意外，。
表现在以下三点
事务（其事务隔离级别只支持Read Committed，即一个事务在提交前，查询不到在事务内所做的修改）
外键（虽然最新的NDB 存储引擎已经支持外键，但性能有问题，因为外键所关联的记录可能在别的分片节点）
表限制
对节点之间的内部互联网络带宽要求高
作为分布式的数据库系统，各个节点之间存在大量的数据通讯，比如所有访问都是需要经过超过一个节点（至少有一个 SQL Node和一个 NDB Node）才能完成。
对内存要求大
Data Node数据会被尽量放在内存中，对内存要求大，而且重启的时候，数据节点将数据load到内存需要很长时间

10. 简述MySQL MMM (Master Replication Manager for MySQL) 集群方案 ？

  正确回答通过率：86.0% 

[ 详情 ] 推荐指数： ★★★★ 试题难度： 初级

MMM是在MySQL Replication的基础上，对其进行优化。
MMM（Master Replication Manager for MySQL）是双主多从结构
这是Google的开源项目，使用Perl语言来对MySQL Replication做扩展，提供一套支持双主故障切换和双主日常管理的脚本程序，主要用来监控mysql主主复制并做失败转移。
注意：这里的双主节点，虽然叫做双主复制，但是业务上同一时刻只允许对一个主进行写入，另一台备选主上提供部分读服务，以加速在主主切换时刻备选主的预热。

就各个集群方案来说，其优势为：
自动的主主Failover切换，一般3s以内切换备机。
多个从节点读的负载均衡。

其劣势为：
无法完全保证数据的一致性。如主1挂了，MMM monitor已经切换到主2上来了，而若此时双主复制中，主2数据落后于主1（即还未完全复制完毕），那么此时的主2已经成为主节点，对外提供写服务，从而导致数据不一。
由于是使用虚拟IP浮动技术，类似Keepalived，故RIP（真实IP）要和VIP（虚拟IP）在同一网段。如果是在不同网段也可以，需要用到虚拟路由技术。但是绝对要在同一个IDC机房，不可跨IDC机房组建集群。

11. 简述MySQL MHA 集群方案 ？

  正确回答通过率：74.0% 

[ 详情 ] 推荐指数： ★★★★ 试题难度： 中级

1 基本原理
MHA（master high availability）是一款开源的 MySQL 高可用程序，目前在 MySQL 高可用方案中是相对成熟的解决方案。
MHA 是基于标准的 MySQL 复制（异步/半同步），为 MySQL 主从复制架构提供了【自动故障转移】的功能。
MHA 由 管理节点（MHA Manager）和 数据节点（MHA Node）两部分组成。
MHA Manager 会定时探测集群中的 master 节点，当 master 节点出现故障时，它可以自动将拥有最新数据的 slave 节点提升为新的 master 节点。
MHA 还提供了 master 节点在线切换的功能，也就是说，可以按需切换 master/slave 节点。
2 MHA角色
MHA 服务有两种角色：MHA Manager（管理节点）、MHA Node（数据节点）。
MHA Manager：通常单独部署在一台机器上，用来管理多个 master/slave 集群（组），每个 master/slave 集群称作一个 application，用来管理统筹整个集群。
MHA Node：运行在每台 MySQL 服务器上（master/slave/manager），它通过监控具备解析和清理 logs 功能的脚本来加快故障转移。
3架构
目前 MHA 主要支持一主多从的架构，搭建 MHA 要求一个【复制集群】中必须【最少】有三台数据库服务器，一主二从，即一台 master，一台备用 master，另外一台从库。SO，至少需要三台服务器，再加上 MHA Manager 一台，可能就需要四台服务器。

12. MySQL数据库的主从复制原理简述 ？

  正确回答通过率：64.0% 

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 中级

1).客户端在master上执行DDL、DML操作，将数据变更记录到 bin log（二进制日志）；
2).从库 slave 的I/O线程连接上 master，请求读取指定位置 position 的日志内容；
3).master 收到从库 slave 请求后，将指定位置 position 之后的日志内容和主库 bin log 文件的名称以及在日志中的位置推送给从库 slave。 ① 通过 show master status 可以查看最新的 bin log 日志文件名称和位置等信息；
② 定位一个 logEvent 需要通过 binlog filename + binlog position进行定位。
4).slave 的I/O线程接收到数据后，将接收到的日志内容依次写入到 relay log（中继日志）文件的最末端，并将读取到的主库 bin log 文件名和位置 position 记录到 master info 文件中，方便下一次读取的时候能够清楚的告诉 master“我需要从某个bin log日志的某个位置开始往后的日志内容”。
5).slave 的 sql 线程检测到 relay log 中的内容更新后，读取日志并解析成可执行的 sql 语句进行重做

13. 请说明MYSQL主从复制(一主多从)核心配置流程 ？

 正确回答通过率：59.0% 

[ 详情 ] 推荐指数： ★★★★ 试题难度： 中级

1、修改配置文件
分别在三台服务器中使用如下命令修改配置文件
$ vim /etc/my.cnf
分别向三台服务器的/etc/my.cnf mysql配置文件添加如下内容：
masetr slave1 slave2
server-id=1
#主库开启binlog日志
log-bin=/var/lib/mysql/mysql-bin
server-id=2 server-id=3
2、在主库创建复制用户
在mysql命令下输入如下命令创建一个用户供从库（slave）复制主库（master）
mysql> grant replication slave on . to ‘test’@‘%’ identified by ‘123456’;
Query OK, 0 rows affected (0.00 sec)
mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)
3、从库关联主库
使用一下命令查看主库（master）的状态
mysql> show master status;
输出以下信息，当然你的可以和我的不一样
mysql> show master status;
±-----------------±---------±-------------±-----------------±------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
±-----------------±---------±-------------±-----------------±------------------+
| mysql-bin.000002 | 5141037 | | | |
±-----------------±---------±-------------±-----------------±------------------+
1 row in set (0.00 sec)
可以看到以上结果，这儿只需要看 File 和 Position，其它的两个分别是白名单和黑名单，意思为同步哪几个数据库和不同步哪几个数据库，可自行根据需求进行设置。记录以上前两个字段信息后（）。
分别在两台从库（slave）上操作如下命令：
mysql> change master to master_host=‘47.100.222.111’, master_port=3306, master_user=‘test’, master_password=‘123456’, master_log_file=‘mysql-bin.000002’, master_log_pos=5141037;
mysql> flush privileges；
mysql> slave start;
执行完毕后，在从库上继续执行如下语句：
mysql> show slave status\G;
输出如下信息：
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 47.100.225.121
Master_User: helper
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000002
Read_Master_Log_Pos: 5141037
Relay_Log_File: slave1-relay-bin.000003
Relay_Log_Pos: 5140628
Relay_Master_Log_File: mysql-bin.000002
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
----------以下省略
如果 Slave_IO_Running: 和Slave_SQL_Running: 都为YES那证明配置已经成功。

14. 请说明MYSQL主从复制 ( 双主多从 )核心配置流程 ？

 正确回答通过率：59.0% 

[ 详情 ] 推荐指数： ★★★★ 试题难度： 高难

1.1 Master1 配置
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
#[必须] 主服务器唯一ID
server-id=1
#[必须]启用二进制日志，指明路径。比如：自己本地的路径 /log/mysqlbin
log-bin=mysql-bin
#设置不要复制的数据库(可设置多个)
binlog-ignore-db=mysql
binlog-ignore-db=information_schema
#设置需要复制的数据库
binlog-do-db=mydb1
#设置logbin格式
binlog_format=STATEMENT
#在作为从数据库的时候，有写入操作也要更新二进制日志文件
log-slave-updates
#表示自增长字段每次递增的量，指自增字段的起始值，其默认值是1，取值范围是1 … 65535
auto-increment-increment=2
#表示自增长字段从哪个数开始，指字段一次递增多少，他的取值范围是1 … 65535
auto-increment-offset=1

1.2 Master2配置
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
#[必须] 主服务器唯一ID
server-id=3
#[必须]启用二进制日志，指明路径。比如：自己本地的路径 /log/mysqlbin
log-bin=mysql-bin
#设置不要复制的数据库(可设置多个)
binlog-ignore-db=mysql
binlog-ignore-db=information_schema
#设置需要复制的数据库
binlog-do-db=mydb1
#设置logbin格式
binlog_format=STATEMENT
#在作为从数据库的时候，有写入操作也要更新二进制日志文件
log-slave-updates
#表示自增长字段每次递增的量，指自增字段的起始值，其默认值是1，取值范围是1 … 65535
auto-increment-increment=2
#表示自增长字段从哪个数开始，指字段一次递增多少，他的取值范围是1 … 65535
auto-increment-offset=2

2、双从机配置
修改配置
vim /etc/my.cnf
2.1 Slave1配置
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
#[必须] 主服务器唯一ID
server-id=2
#启用中继日志
relay-log=mysql-relay
2.2 Slave2配置
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
#[必须] 主服务器唯一ID
server-id=4
#启用中继日志
relay-log=mysql-relay

15. 简述MySQL主从同步延时的问题 ？

  正确回答通过率：59.0% 

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 高难

Mysql默认采用的异步操作，因为它的效率明显是最高的。因为只要写入bin log后事物就结束返回成功了。但由于从库从主库异步拷贝日志 以及
串行执行 SQL 的特点，所以从库的数据一定会比主库慢一些，是有延时的。所以经常出现，刚写入主库的数据可能是读不到的，要过几十毫秒，甚至几百毫秒才能
读取到。这就是主从同步延时问题。
1、如何查看主从延迟时间
通过监控 show slave status 命令输出的Seconds_Behind_Master参数的值来判断：
mysql> show slave status\G;
// 状态一
Seconds_Behind_Master: NULL
// 状态二
Seconds_Behind_Master: 0
// 状态三
Seconds_Behind_Master: 79
Seconds_Behind_Master=0: 表示主从复制良好；
Seconds_Behind_Master=NULL: 表示io_thread或是sql_thread有任何一个发生故障；
Seconds_Behind_Master=79: 数字越大表示从库延迟越严重。
2、影响延迟因素
这里整理了影响主从复制延迟大致有以下几个原因：
1）主节点如果执行一个很大的事务，那么就会对主从延迟产生较大的影响
2）网络延迟，日志较大，slave数量过多
3）主上多线程写入，从节点只有单线程同步
4）机器性能问题，从节点是否使用了“烂机器”
5）锁冲突问题也可能导致从机的SQL线程执行慢
3、优化主从复制延迟
这个没有说去完全解决，要想解决那么就只能采用同步复制策略。不过，一般不建议使用这种同步模式。显而易见，如果写操作必须等待更新同步完成，肯定会
极大地影响性能，除非你不在乎性能。
1）大事务：将大事务分为小事务，分批更新数据
2）减少Slave的数量，不要超过5个，减少单次事务的大小
3）MySQL 5.7之后，可以使用多线程复制，使用MGR复制架构
4）在磁盘、raid卡、调度策略有问题的情况下可能会出现单个IO延迟很高的情况，可用iostat命令查看DB数据盘的IO情况，再进一步判断
5）针对锁问题可以通过抓去processlist以及查看information_schema下面和锁以及事务相关的表来查看
总结
主机与从机之间的物理延迟是无法避免的，既然无法避免就可以考虑尝试通过缓存等方式，降低新修改数据被立即读取的概率。

16. 简述MYSQL的主从延迟，怎么解决？

  正确回答通过率：59.0% 

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 高难

主从复制分了五个步骤进行：

步骤一：主库的更新事件(update、insert、delete)被写到binlog
步骤二：从库发起连接，连接到主库。
步骤三：此时主库创建一个binlog dump thread，把binlog的内容发送到从库。
步骤四：从库启动之后，创建一个I/O线程，读取主库传过来的binlog内容并写入到relay log
步骤五：还会创建一个SQL线程，从relay log里面读取内容，从Exec_Master_Log_Pos位置开始执行读取到的更新事件，将更新内容写入到slave的db
主从同步延迟的原因

一个服务器开放Ｎ个链接给客户端来连接的，这样有会有大并发的更新操作, 但是从服务器的里面读取binlog的线程仅有一个，当某个SQL在从服务器上执行的时间稍长 或者由于某个SQL要进行锁表就会导致，主服务器的SQL大量积压，未被同步到从服务器里。这就导致了主从不一致， 也就是主从延迟。

主从同步延迟的解决办法

主服务器要负责更新操作，对安全性的要求比从服务器要高，所以有些设置参数可以修改，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之类的设置等。
选择更好的硬件设备作为slave。
把一台从服务器当度作为备份使用， 而不提供查询， 那边他的负载下来了， 执行relay log 里面的SQL效率自然就高了。
增加从服务器喽，这个目的还是分散读的压力，从而降低服务器负载。

17. 简述MySQL主从不一致问题处理方案 ？

  正确回答通过率：45.0% 

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 高难

【1】手动执行同步+忽略错误(在业务不保证数据强一致性的情况下，可以选择忽略)

1）先进入主库，进行锁表，防止数据写入
mysql> flush tables with read lock;
mysql> show master status
2）数据导出备份然后倒入从库
mysqldump -uroot -p --lock-all-tables --flush-logs db_name > /data/master.sql
3）登录从库停止slave从节点
stop slave;
4）倒入数据
mysql -u root -p db_name < /temp/master.sql
或mysql> source /temp/master.sql
5）配置重新主从同步

5.7及之后版本
mysql> update mysql.user set authentication_string = password (‘Password4’) where user = ‘testuser’ and host = ‘%’;
Query OK, 1 row affected, 1 warning (0.06 sec)
Rows matched: 1 Changed: 1 Warnings: 1

mysql> flush privileges;
Query OK, 0 rows affected (0.01 sec)
#5.6及之前版本
update mysql.user set password=password(‘新密码’) where user=‘用户名’ and host=‘host’;

mysql> change master to master_host=‘172.18.1.20’, master_port=3306, master_user=‘repl’,master_password=‘123456’, master_log_file=‘mysql-bin.000031’,master_log_pos=932;
6）开启slave
start slave;
7）查看slave状态
show slave status\G //正常输出如下
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
……
Seconds_Behind_Master:0
8）如果一段时间后，出现了报错，停止slave：
set global sql_slave_skip_counter =1; #这个参数只是针对传统复制有效，针对GTID复制只能使用gtid_next.
9）start slave再次验证，重复几次，把所有错误忽略掉；

【2】手动执行同步+手动更正

前7步同上；
通过第7步的报错位置，在主库执行：
mysqlbinlog -v --stop-position=xxx ./data/master-bin.xxx > ./binlog.update
cat ./binlog.update |awk ‘/end_log_pos xxx/ {print NR}’
根据上面的NR行数，查看附近的行，定位数据不一致的地方，后续手动补全
cat ./binlog.update |awk ‘NRxxx-50,NRxxx+50’|grep -i update -A 200|grep xxxx -B 200|less
找到数据位置，@1表第一个字段值；其中@1 @2 @3…分别对应表的列名
或：
比如，报错位置 end_log_pos 440267874。可利用mysqlbinlog工具找出440267874的事件
/usr/local/mysql-5.6.30/bin/mysqlbinlog --base64-output=decode-rows -vv mysql-bin.000003 |grep -A 20 ‘440267874’
或者/usr/local/mysql-5.6.30/bin/mysqlbinlog --base64-output=decode-rows -vv mysql-bin.000003 --stop-position=440267874 | tail -20
或者usr/local/mysql-5.6.30/bin/mysqlbinlog --base64-output=decode-rows -vv mysql-bin.000003 > decode.log
主库创建临时表：
Create table xxl_job_temp like xxl_job_log_report;
将该段数据写入临时表导出导入到备库；
start slave;
show slave status\G

结果说明：
Slave_IO_Running： 该参数可作为io_thread的监控项，Yes表示io_thread的和主库连接正常并能实施复制工作，No则说明与主库通讯异常，多数情况是由主从间网络引起的问题；
Slave_SQL_Running： 该参数代表sql_thread是否正常，具体就是语句是否执行通过，常会遇到主键重复或是某个表不存在。
Seconds_Behind_Master：是通过比较sql_thread执行的event的timestamp和io_thread复制好的event的timestamp(简写为ts)进行比较，而得到的这么一个差值；NULL—表示io_thread或是sql_thread有任何一个发生故障，也就是该线程的Running状态是No，而非Yes。0 — 该值为零，是我们极为渴望看到的情况，表示主从复制良好，可以认为lag不存在。正值 — 表示主从已经出现延时，数字越大表示从库落后主库越多。负值 — 几乎很少见，我只是听一些资深的DBA说见过，其实，这是一个BUG值，该参数是不支持负值的，也就是不应该出现。

18. 是否存在第三方工具监控MySQL的异步复制过程？

 正确回答通过率：51.0% 

[ 详情 ] 推荐指数： ★★ 试题难度： 中级

Percona Toolkit是mysql运维的一组命令的集合， 是 Percona 支持人员用来执行各种 MySQL、MongoDB 和系统任务的高级命令行工具集，它们是完全独立的，不依赖与特定的库，因此安装也很简单；该工具中最主要的三个组件分别是：
项目 Value
pt-table-checksum 负责监测mysql主从数据一致性
pt-table-sync 负责当主从数据不一致时修复数据，让它们保存数据的一致性
pt-heartbeat 负责监控mysql主从同步延迟

19. 简述什么是MySQL Cluster ？

 正确回答通过率：95.0% 

[ 详情 ] 推荐指数： ★★★ 试题难度： 初级

MySQL Cluster是一个高性能、可扩展、集群化数据库产品。MySQL Cluster是一个基于NDB Cluster存储引擎的完整分布式数据库系统，采用无共享的数据存储技术，实时同步且支持快速故障切换、事务。NDB是一种in-memory的存储引擎，它具有可用性高和数据一致性好的特点。

MySQL Cluster可由多台服务器组成的、同时对外提供数据管理服务的分布式集群系统。通过合理的配置，可以将服务请求在多台物理机上分发实现负载均衡 ；同时内部实现了冗余机制，在部分服务器宕机的情况下，整个集群对外提供的服务不受影响，从而能达到99.999%以上的高可用性。

20. 请简述MySQL Cluster的整体架构 ？

  正确回答通过率：80.0% 

[ 详情 ] 推荐指数： ★★★★ 试题难度： 中级

数据节点（Data Nodes）：用于存储集群的数据。实现底层数据存储的功能，保存Cluster 的数据。每一个NDB 节点保存完整数据的一部分（或者一份完整的数据，视节点数目和配置而定），在MySQL Cluster 里面叫做一个fragment。而每一个fragment，正常情况来讲都会在其他的主机上面有一份（或者多分）完全相同的镜像存在。这些都是通过配置来完成的，所以只要配置得当，MySQL Cluster 在存储层不会出现单点的问题。数据节点是用命令ndbd启动的。

SQL节点（SQL Nodes）：向外提供一个标准的SQL语言编程接口。SQL节点负责向数据节点传送访问请求，具体集群过程以及数据库底层均对外透明。
SQL节点提供用户SQL指令请求，解析、连接管理，query优化和响、cache管理等、数据merge、sort，裁剪等功能，当SQL节点启动时，将向管理节点同步架构信息，用以数据查询路由。SQL节点作为查询入口，需要消耗大量cpu及内存资源，可使用分布式管理节点，并在SQL节点外封装一层请求分发及HA控制机制可解决单点及性能问题，其提供了线性扩展功能。SQL节点是使用命令mysqld -ndbcluster启动的，或将ndbcluster添加到“my.cnf”后使用“mysqld”启动。

管理节点（NDB Management Server）：负责整个Cluster 集群中各个节点的管理工作，包括集群的配置，启动关闭各节点，以及实施数据的备份恢复等。管理节点会获取整个Cluster 环境中各节点的状态和错误信息，并且将各Cluster 集群中各个节点的信息反馈给整个集群中其他的所有节点。通常只需配置一个管理节点；然而为了排除单点故障需要，有可能的话，尽量增加管理节点的数量。MGM节点是用命令ndb_mgm启动的。

21. MySQL Cluster 优点和缺点 ？

 正确回答通过率：70.0% 

[ 详情 ] 推荐指数： ★★★ 试题难度： 中级

其优势为：

mysql官方提供的工具，无需第三方插件。
多个主节点，没有单点故障的问题，节点故障恢复通常小于1秒。
负载均衡优秀，可同时用于读操作、写操作都都密集的应用，也可以使用SQL和NOSQL接口访问数据。
高可用性和可伸缩性
可以自动切分数据，方便数据库的水平拓展
能跨节点冗余数据（其数据集并不是存储某个特定的MySQL实例上，而是被分布在多个Data Nodes中，即一个table的数据可能被分散在多个物理节点上，任何数据都会在多个Data Nodes上冗余备份。任何一个数据变更操作，都将在一组Data Nodes上同步，以保证数据的一致性）。
其劣势为：

架构模式和原理很复杂。
只能使用存储引擎 NDB ，与平常使用的InnoDB 有很多明显的差距，可能会导致日常开发出现意外，。
表现在以下三点
事务（其事务隔离级别只支持Read Committed，即一个事务在提交前，查询不到在事务内所做的修改）
外键（虽然最新的NDB 存储引擎已经支持外键，但性能有问题，因为外键所关联的记录可能在别的分片节点）
表限制
对节点之间的内部互联网络带宽要求高
作为分布式的数据库系统，各个节点之间存在大量的数据通讯，比如所有访问都是需要经过超过一个节点（至少有一个 SQL Node和一个 NDB Node）才能完成。
对内存要求大
Data Node数据会被尽量放在内存中，对内存要求大，而且重启的时候，数据节点将数据load到内存需要很长时间。

22. 请简述MySQL Cluster的常规命令 ？

 正确回答通过率：70.0% 

[ 详情 ] 推荐指数： ★★★★ 试题难度： 初级

1.启动Cluster管理节点
bin/ndb_mgmd -f /opt/mysql-cluster/etc/config.ini --reload --configdir=/opt/mysql-cluster #修改配置文件后要加上–reload才会生效
2.启动Cluster数据节点
bin/ndbd --connect-string=“nodeid=2;host=172.16.48.204:1186” #各个数据节点的nodeid可以在管理节点上show看到
3.启动Cluster的SQL节点
bin/mysqld_safe --defaults-file=/opt/mysql-cluster/etc/my.cnf --basedir=/opt/mysql-cluster --datadir=/opt/mysql-cluster/data --user=mysql &
4.关闭Cluster的SQL节点
bin/mysqladmin -u root -p shutdown --socket=‘tmp/mysql.sock’
5.关闭管理节点（同时数据节点也会关闭）
ndb_mgm -e shutdown

23. 请简述MySQL MHA 概念 ？

 正确回答通过率：94.0% 

[ 详情 ] 推荐指数： ★★★ 试题难度： 初级

MHA（Master High Availability）是一套比较成熟的 MySQL 高可用方案，也是一款优秀的故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。MHA还支持在线快速将Master切换到其他主机，通常只需0.5－2秒。
目前MHA主要支持一主多从的架构，要搭建MHA，要求一个复制集群中必须最少有三台数据库服务器。

24. 请简述MySQL MHA 整体架构 ？

  正确回答通过率：55.0% 

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 高难

MHA由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。
MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。负责检测master是否宕机、控制故障转移、检查MySQL复制状况等。
1）MHA Node运行在每台MySQL服务器上，不管是Master角色，还是Slave角色，都称为Node，是被监控管理的对象节点，负责保存和复制master的二进制日志、识别差异的中继日志事件并将其差异的事件应用于其他的slave、清除中继日志。
2）MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master，整个故障转移过程对应用程序完全透明。

25. 简述 MHA 故障处理机制 ？

  正确回答通过率：61.0% 

[ 详情 ] 推荐指数： ★★★★ 试题难度： 中级

MAH 的目的在于维护 MySQL replication 中 master 库的高可用性，其最大的特点是可以修复多个 slave 之间的差异日志，最终使所有 slave 保持数据一致。
1）把宕机master的binlog保存下来
2）根据binlog位置点找到最新的slave
3）用最新slave的relay log修复其它slave
4）将保存下来的binlog在最新的slave上恢复
5）将最新的slave提升为master
6）将其它slave重新指向新提升的master，并开启主从复制

26. 请简单列举MHA的安装部署启动流程 ？

 正确回答通过率：62.0% 

[ 详情 ] 推荐指数： ★★★ 试题难度： 中级

MHA需要的资源
1主DB。
2-N从DB。
n+2IP地址。
监控用户。
复制用户。

MHA配置步骤
配置一主多从的复制架构。
安装centos的yum扩展源和依赖包。
配置集群内各主机的ssh免认证。
各节点安装mha_node软件。
管理节点安装mha_manager。
配置并启动mha管理进程。

27. 简述MMM 工作原理和高可用架构 ？

  正确回答通过率：44.0% 

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 高难

MMM 即 Multi-Master Replication Manager for MySQL:mysql 多主复制管理器,基于 perl 实现,关于 mysql 主主复制配置的监控、故障转移和管理的一套可伸缩的脚本套件（在任何时候只有一个节点可以被写入），MMM 也能对从服务器进行读负载均衡，所以可以用它来在一组用于复制的服务器启动虚拟 ip，除此之外，它还有实现数据备份、节点之间重新同步功能的脚本。MySQL 本身没有提供 replication failover 的解决方案，通过 MMM 方案能实现服务器的故障转移，从而实现 mysql 的高可用。MMM 不仅能提供浮动 IP 的功能，如果当前的主服务器挂掉后，会将你后端的从服务器自动转向新的主服务器进行同步复制，不用手工更改同步配置。这个方案是目前比较成熟的解决方案。

MMM主要功能由下面三个脚本提供：
mmm_mond 负责所有的监控工作的监控守护进程，决定节点的移除(mmm_mond 进程定时心跳检测，失败则将 write ip 浮动到另外一台 master)等等
mmm_agentd 运行在 mysql 服务器上的代理守护进程，通过简单远程服务集提供给监控节点
mmm_control 通过命令行管理 mmm_mond 进程
在整个监管过程中，需要在 mysql 中添加相关授权用户，授权的用户包括一个 mmm_monitor用户和一个 mmm_agent 用户，如果想使用 mmm 的备份工具则还要添加一个 mmm_tools用户。

28. 请列举Oracle的有哪些高可用集群方案 ？

  正确回答通过率：77.0% 

[ 详情 ] 推荐指数： ★★★★ 试题难度： 中级

主要有三种：

1. RAC
   RAC, Real Application Clusters
   多个Oracle服务器组成一个共享的Cache，而这些Oracle服务器共享一个基于网络的存储。这个系统可以容忍单机/或是多机失败。
   不过系统内部的多个节点需要高速网络互连，基本上也就是要全部东西放在在一个机房内，或者说一个数据中心内。如果机房出故障，比如网络不通，那就坏了。所以仅仅用RAC还是满足不了一般互联网公司的重要业务的需要，重要业务需要多机房来容忍单个机房的事故。
2. Data Guard.
   Data Guard这个方案就适合多机房的。某机房一个production的数据库，另外其他机房部署standby的数据库。Standby数据库分物理的和 逻辑的。物理的standby数据库主要用于production失败后做切换。而逻辑的standby数据库则在平时可以分担production数据 库的读负载。
3. MAA
   MAA(Maximum Availability Architecture)其实不是独立的第三种，而是前面两种的结合，来提供最高的可用性。
   每个机房内部署RAC集群，多个机房间用Data Guard同步。

29. 请阐述与Oracle RAC集群概念和原理 ？

 正确回答通过率：49.0% 

[ 详情 ] 推荐指数： ★★★★ 试题难度： 高难

ORACLE RAC原理：在一个应用环境当中，所有的服务器使用和管理同一个数据库，目的是为了分散每一台服务器的工作量，硬件上至少需要两台以上的服务器，而且还需 要一个共享存储设备。同时还需要两类软件，一个是集群软件，另外一个就是Oracle数据库中的RAC组件。同时所有服务器上的OS都应该是同一类OS, 根据负载均衡的配置策略，当一个客户端发送请求到某一台服务的listener后，这台服务器根据我们的负载均衡策略，会把请求发送给本机的RAC组件处 理也可能会发送给另外一台服务器的RAC组件处理，处理完请求后，RAC会通过集群软件来访问我们的共享存储设备。

逻辑结构上看，每一个参加集群的节点有一个独立的instance，这些instance访问同一个数据库。节点之间通过集群软件的通讯层 （communication layer）来进行通讯。同时为了减少IO的消耗，存在了一个全局缓存服务，因此每一个数据库的instance，都保留了一份相同的数据库cache。

Oracle RAC的核心是共享磁盘子系统，集群中所有节点必须能够访问所有数据、重做日志文件、控制文件和参数文件，数据磁盘必须是全局可用的，允许所有节点访问数据库，每个节点有它自己的重做日志和控制文件，但是其他节点必须能够访问它们以便在那个节点出现系统故障时能够恢复。

30. 简述Oracle RAC应用场景 ？

 正确回答通过率：76.0% 

[ 详情 ] 推荐指数： ★★★ 试题难度： 中级

Oracle RAC被广泛用于大型、高性能的企业级应用系统中，如在线交易处理、数据仓库和业务智能分析等
（1）交易处理
在交易处理系统中，Oracle RAC可以提供高可用性、负载均衡和性能优化的支持。采用Oracle RAC可以避免因单点故障而导致的系统不可用或性能下降，保障了在线交易系统的连续性和稳定性。

（2）数据仓库
在数据仓库系统中，Oracle RAC可以提供强大的查询优化功能，以满足业务对数据挖掘和商业智能分析的需求。同时，Oracle RAC还支持在线报表生成和实时数据分析，可以大大提升业务决策的速度和准确性。

（3）业务智能分析
Oracle RAC还广泛应用于业务智能分析系统中，以满足大规模数据量、复杂查询和多维分析等业务需求。通过引入Oracle RAC，可以有效提高系统的响应速度和并行处理能力，以满足业务对实时性和可靠性的需求。

31. 简述Oracle RAC的优缺点 ？

 正确回答通过率：78.0% 

[ 详情 ] 推荐指数： ★★ 试题难度： 中级

（1）优点

1 高可用性：Oracle RAC 具有高可用性，因为它可以在多个节点上运行数据库实例。如果一个节点出现故障，其他节点可以自动接管其职责，从而避免了单点故障。
2 高容错性：Oracle RAC提供故障检测和自动恢复技术，在节点故障、网络故障以及存储设备故障等情况下，自动地协调数据库实例之间的交互。Oracle RAC 具有故障转移功能，因为它可以自动将客户端请求路由到可用的节点上。这可以确保系统的连续性和可用性，从而避免了业务中断的风险。
3 可扩展性：Oracle RAC 具有可扩展性，因为它可以通过增加节点来扩展性能，以满足不断增长的业务需求。Oracle RAC提供在线扩展的功能，可在不中断服务的情况下添加或删除节点。
4 负载均衡：Oracle RAC 具有负载均衡功能，因为它可以将客户端请求路由到可用的节点上。这可以确保每个节点都能充分利用其资源，从而提高性能和可靠性。
5 数据共享：Oracle RAC 具有数据共享功能，因为它可以让多个节点共享同一个物理存储。这可以确保数据的一致性和完整性，从而避免了数据冲突和数据丢失的问题。

（2）局限性

1 成本高昂：Oracle RAC需要购买专门的硬件和软件支持，以及专业人员的维护和管理。这使得采用Oracle RAC的成本较高，对于中小型企业而言可能不划算。
2 复杂性：Oracle RAC的构建和配置比单机数据库复杂得多，需要考虑多个节点之间的数据同步、连接管理、资源管理以及故障恢复等问题。这可能需要更为复杂的系统架构、详细的设计和测试过程。
4 可扩展性有限：尽管Oracle RAC可以通过添加和删除节点来实现线性扩展，但这种可扩展性也有一定的局限性。如果要进一步提高性能，可能需要采用更为复杂的方案，如分布式数据库或云计算架构。
5 资源占用：由于Oracle RAC需要在每个节点上运行多个实例，因此它需要更多的计算资源和内存容量。这可能会影响整个系统的性能和稳定性。

32. 简述Oracle RAC架构和工作机制 ？

  正确回答通过率：58.0% 

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 高难

Oracle RAC的架构包括两个主要组件：共享存储和实例集群。

共享存储指多个节点可以访问的单个存储池，其中包括共享的磁盘或SAN设备等。所有节点都可以访问共享的存储空间，包括数据文件、控制文件、归档日志和参数文件等。这些存储资源通常由一个专门的存储阵列设备提供支持，以确保容错性和高可用性。
实例集群指运行在集群中各个节点上的多个Oracle实例，每个实例都运行在不同的服务器节点上，它们可以协同工作，共享相同的数据库存储空间。

33. 请列举Oracle RAC 的体系结构多个关键组件 ？

  正确回答通过率：45.0% 

[ 详情 ] 推荐指数： ★★★ 试题难度： 高难

（1）Oracle Database 软件
Oracle Database 软件是 Oracle RAC 的核心组成部分，它必须在每个节点上进行安装和配置，并且需要连接到共享存储设备，以确保节点之间可以相互访问数据库存储。

（2）共享存储
共享存储对于 Oracle RAC 来说是至关重要的。它由一个或多个存储设备提供支持，以确保各个节点之间可以相互访问数据库存储资源。共享存储通常采用 SAN 存储设备或 NAS 设备来实现。

（3）Oracle Clusterware
Oracle Clusterware 是 Oracle RAC 中的关键组件之一，它可以跨节点协调各个实例之间的交互，并且提供自动故障转移和恢复功能，以确保数据库始终可用。此外，Clusterware 还提供了动态资源管理功能，确保每个节点上的进程可以均衡利用系统资源。

（4）共享缓存
Oracle RAC 采用了共享内存架构的方式来实现多个实例之间的数据共享。即各个节点的实例都可以在内存中共享部分数据块（Synchronized Global Cache）。这些数据块可以被多个实例同时访问和修改，不同实例之间进行数据同步和数据冲突检测，保证数据的一致性。通过共享内存架构，Oracle RAC 可以避免访问磁盘的等待时间，从而提高系统的性能。

（5）连接管理器
连接管理器负责将客户端请求路由到可用的节点，以实现负载均衡。此外，连接管理器还提供了一些额外的功能，例如自动重试和会话故障检测等，以提高应用程序的可用性和可靠性。

（6）集群文件系统
集群文件系统用于支持 Oracle RAC 的共享存储。它可以允许多个节点同时访问同一个文件系统，同时确保文件系统的安全性和一致性。Oracle RAC 支持多种集群文件系统，包括 ASM（Automatic Storage Management）和 OCFS2（Oracle Cluster File System）等。

（7）全局资源管理器
全局资源管理器（Globally Enqueue Service）是 Oracle RAC 中实现并发控制的重要组件之一。它负责在多个节点之间协调并发事务的操作，包括锁定、解锁和排队等。同时，全局资源管理器还提供故障检测和自动恢复技术，可以动态地重新分配资源，以适应系统的变化。

34. 请大概描述如何Oracle RAC 安装步骤和流程 ？

 正确回答通过率：34.0% 

[ 详情 ] 推荐指数： ★★★★ 试题难度： 高难

Oracle RAC 的安装过程通常可以分为以下几个步骤：准备环境、安装 Oracle 软件、创建数据库、配置 RAC 组件、进行测试等。
（1）准备环境
主要包括以下方面：
硬件和操作系统要求：确保所有节点都满足 Oracle 的硬件和软件要求。
共享存储：准备好共享存储设备，并确保所有节点都可以访问该设备。
软件下载：从 Oracle 官方网站下载最新版本的 Oracle Database 软件和 Patchset。
网络配置：为每个节点配置网络接口，并确认所有节点之间的网络连接是正常的。

（2）安装 Oracle 软件
安装步骤如下：
解压下载的 Oracle Database 软件包，并将其复制到所有节点上。
运行runInstaller 脚本，启动 Oracle Database 安装程序。
“选择安装选项”页面上，选择“Install Database software only”选项，然后单击“Next”按钮。
“选择系统类别”页面上，选择“Cluster database”选项，然后单击“Next”按钮。
“选择集群配置”页面上，选择“Advanced installation”选项，然后单击“Next”按钮。
“选择集群节点”页面上，选择要安装 Oracle RAC 的所有节点，并设置每个节点的 Oracle 安装目录和共享存储位置。然后单击“Next”按钮。
“选择 Grid Infrastructure 基本目录”页面上，设置 Grid Infrastructure 软件的基本目录和组别。然后单击“Next”按钮。
“选择兼容性模式”页面上，选择需要的兼容性模式（Oracle Database 18c 或 Oracle Database 19c）。
“指定管理密码”页面上，设置 Grid Infrastructure 和数据库的管理员密码。然后单击“Next”按钮。
“审查所选配置”页面上，确认所选配置。然后单击“Install”按钮，开始安装 Oracle RAC。

（3）创建数据库
创建步骤如下：
在每个节点上运行 dbca 命令，启动 Oracle Database Configuration Assistant 工具。
“选择操作”页面上，选择“Create Database”选项，然后单击“Next”按钮。
“选择模板”页面上，选择“General Purpose or Transaction Processing”选项，然后单击“Next”按钮。
“定义数据库标识符”页面上，设置数据库名称、实例名称和 SID 等参数。然后单击“Next”按钮。
“配置数据库选项”页面上，设置数据库字符集、语言等选项。然后单击“Next”按钮。
“指定数据库文件位置”页面上，设置数据库的数据文件、控制文件和归档日志文件等位置。通常情况下，这些文件应该存储在共享存储中。然后单击“Next”按钮。
“指定数据库管理选项”页面上，设置管理员密码、监听器端口等选项。然后单击“Next”按钮。
“选择配置选项”页面上，选择需要的配置选项，例如是否启用 ASM 等。然后单击“Next”按钮。
“审查所选配置”页面上，确认所选配置。然后单击“Finish”按钮，开始创建数据库。

（4）配置 RAC 组件
在创建数据库后，需要配置 Oracle RAC 的各个组件，包括监听器、OCR（Oracle Cluster Registry）和 ASM（Automatic Storage Management）等。配置步骤如下：
配置监听器：在每个节点上运行 netca 命令，启动网络配置助手，然后创建一个新的监听器。
配置 OCR：使用 crsctl 命令管理 OCR，可以将 OCR 备份到共享存储中，以实现故障恢复和高可用性。
配置 ASM：在每个节点上运行 asmca 命令，启动 ASM 配置助手，然后创建 ASM 实例，并将数据库文件存储在 ASM 中。

（5）进行测试
在完成 Oracle RAC 的配置后，需要进行一些测试来验证系统是否正常运行。可以通过以下方式进行测试：
使用 SRVCTL 命令管理集群组件，例如启动、停止数据库实例和 ASM 实例等。
使用 SQLPLUS 工具连接到数据库，并执行一些 SQL 查询语句，以验证数据库是否正常工作

35. 请简述RAC软件存储原理 ？

  正确回答通过率：74.0% 

[ 详情 ] 推荐指数： ★★★★ 试题难度： 中级

Oracle10g的RAC安装分为两个阶段。第一阶段是安装CRS，其次是安装带有RAC组件的Database软件并创建Cluster数据库。CRS软件使用的Oracle home必须不同于RAC软件使用的home。尽管可以将Cluster中CRS和RAC软件通过使用Cluster文件系统共享存储，但是软件总是按一定规则安装在每个节点的本地文件系统中。这支持在线补丁的升级，并消除了单节点软件造成的失败。另外有两个必须存储在共享的存储设备中：

• voting file：其本质上是用于Cluster synchronization Services守护进程进行节点信息的监控。大小约为20MB。

• Oracle Cluster Registry(OCR)文件：也是CRS关键的组成部分。用于维护在Cluster中高可用性组件的信息。例如，Cluster节点列表，Cluster数据库Instance到节点的映射和CRS应用资源的列表(如Services、虚拟内部链接协议地址等)。此文件是通过SRVCTL类似的管理工具自动维护的。其大小约100MB。

voting file和OCR file是不能被存储在ASM中的，因为它们必须在任何Oracle Instance启动前就可以被访问。并且，两者必须是在冗余的、可靠的存储设备中存放，如RAID。推荐最好的做法是将这些文件放在裸磁盘上。

36. 请简述RAC Database存储原理 ？

  正确回答通过率：75.0% 

[ 详情 ] 推荐指数： ★★★ 试题难度： 中级

与single-Instance Oracle的存储方式最主要的不同之处在于RAC存储必须将所有RAC中数据文件存放在共享设备中(裸设备或是Cluster文件系统)以便于访问相同Database的Instance能够共享。必须为每个Instance创建至少两个redo log组，并且所有的redo log组必须也存储在共享设备中，从而为了crash恢复的目的。每个Instance的在线redo log groups被称作一个Instance的在线redo 线程。

此外，必须为每个Instance创建一个共享的undo表空间用于Oracle推荐的undo自动管理特点。每个undo表空间必须是对所有Instance共享的，主要用于恢复的目的。

归档日志不能被存放在裸设备上，因为其命名是自动产生的，并且每个是不一致的。因此需要存储在一个文件系统中。如果使用Cluster file system(CFS)，则可以在任何时间在任何node上访问这些归档文件。如果没有使用CFS，就不得不使其他Cluster成员在恢复时那些归档日志是可用的，例如通过网络文件系统(NFS)来实现。如果使用推荐的flash recovery area特性，则其必须被存储在共享目录下，以便于所有的Instance能够访问。(共享目录可以是一个ASM磁盘组，或是一个CFS)。

37. 请叙述RAC和共享存储技术 ？

 正确回答通过率：55.0% 

[ 详情 ] 推荐指数： ★★★ 试题难度： 高难

存储是网格技术中的关键组成部分。传统上，存储都直接依附在每个Server(directly attached to each individual Server DAS)上。在过去的几年来，更灵活的存储出现并得到应用，主要是通过存储空间网络或是正规的以太网来实现访问。这些新的存储方式使得多个Servers访问相同的磁盘集合成为可能，在分布式环境中，可以获得简单的存取。
storage area network(SAN)代表了数据存储技术在这一点的演进。传统上，C/S系统中，数据被存储在Server内部或是依附它的设备中。随后，进入了network attached storage(NAS)阶段，这使得存储设备与Server和直接连接它们的网络向分离。它在SAN遵循的原则进一步允许存储设备存在于各自的网络中，并直接通过高速的媒介进行交换。用户可以通过Server系统对存储设备的数据进行访问，Server 系统与本地网络(LAN)和SAN相互连接。
文件系统的选择是RAC的关键。传统的文件系统不支持多系统的并行挂载。因此，必须将文件存储在没有任何文件系统的裸卷标或是支持多系统并发访问的文件系统中。
因此，三个主要的方法用于RAC的共享存储有：

• 裸卷标：既是一些直接附加的裸设备，需要用于存储，并以block模式进程操作。
• Cluster file system：也需要以block模式进程存取。一个或多个Cluster file 系统可以被用于存储所有的RAC文件。
• 自动存储管理(ASM)：对于Oracle Database files，ASM是一个轻便的、专用的、最佳化的Cluster file system。

38. 解释什么是Oracle Cluster file system ？

  正确回答通过率：70.0% 

[ 详情 ] 推荐指数： ★★★★ 试题难度： 中级

Oracle Cluster file system(OCFS)是一个共享文件系统，专门为Oracle RAC设计。OCFS排除了Oracle Database files被连接到逻辑磁盘上的需要，并使得所有的节点共享一个ORACLE Home，而不需每个node在本地有一个副本。OCFS卷标可以横跨一个或多共享disks，用于冗余和性能的增强。
下面时可放入OCFS中的文件类表：

• Oracle software的安装文件：在10g中，此设置只在windows 2000中支持。说是后面的版本会提供在Linux中的支持，但我还没具体看。
• Oracle 文件(控制文件、数据文件、redo logs文件，bfiles等)
• 共享配置文件(spfile)
• 在Oracle运行期间，由Oracle创建的文件。
• voting和OCR文件
  Oracle Cluster file system对开发人员和用户时免费的。可从官方网站下载

39. 解释RAC安装过程中选择RAW或CFS ？

 正确回答通过率：71.0% 

[ 详情 ] 推荐指数： ★★★★ 试题难度： 中级

• CFS的优点：对于RAC的安装和管理非常简单；对RAC使用Oracle managed files(OMF)；single Oracle软件安装；在Oracle data files上可以自动扩展；当物理节点失败时，对归档日志的统一访问。

• 裸设备的使用：一般会用于CFS不可用或是不被Oracle支持的情况下；它提供了最好的性能，不需要在Oracle和磁盘之间的中间层；如果空间被耗尽，裸设备上的自动扩展将失败；ASM、逻辑存储管理器或是逻辑卷标管理其可以简化裸设备的工作，它们也允许加载空间到在线的裸设备上，可为裸设备创建名字，从而便于管理。

40. 请叙述Oracle RAC的典型Cluster栈 ？

 正确回答通过率：40.0% 

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 高难

在Cluster中的每个节点都需要一个被支持的相互连接的软件协议来支持内部Instance的交互，同时需要TCP/IP支持CRS的轮询。所有的UNIX平台在千兆以太网上使用user datagram protocol(UDP)作为主要的协议并进行RAC内部Instance 的IPC交互。其他支持的特有协议包括用于SCI和Sunfire的连接交互的远程共享内存协议和超文本协议，用于超光纤交互。在任何情况下，交互必须能被平台的Oracle所辨识。

使用Oracle clusterware，可以降低安装并支持并发症。但如果用户使用非以太交互，或开发了依赖clusterware的应用程序在RAC上，可能需要vendor clusterware。

同交互连接一样，共享存储方案必须被当前平台的Oracle所辨识。如果在目标平台上，CFS可用，Database area和flash recovery area都可以被创建到CFS或ASM上。如果在目标平台上，CFS不可用，则Database area可以创建在ASM或是裸设备上(需要卷标管理器)并且flash recovery area必须被创建在ASM中。

41. 请说明什么是RAC certification Matrix ？

 正确回答通过率：41.0% 

[ 详情 ] 推荐指数： ★★★★ 试题难度： 高难

RAC certification Matrix：它设计用于处理任何认证问题。可以使用matrix回答任何RAC相关的认证问题。具体使用步骤如下：

• 连接并登陆 http://metalink.oracle.com
• 点击菜单栏的“certify and availability”按钮
• 点击“view certifications by product”连接
• 选择RAC
• 选择正确的平台

42. 当RAC和Instance/crash recovery的处理关系 ？

  正确回答通过率：31.0% 

[ 详情 ] 推荐指数： ★★★ 试题难度： 高难

1)当一个Instance失败，当该失败被其他Instance检测到，第二个Instance将会执行下面的恢复操作：
①在恢复的第一阶段，GES重新灌入队列
②GCS也重新灌入其资源。GCS进程只重新灌入那些失去其控制的资源。在这期间，所有的GCS资源请求和写请求都临时被挂起。然而，事务可以继续修改data blocks，只要这些事务已经获得了必要的资源。
③当队列被重新配置后，一个活动的Instance可以获得占有该Instance恢复队列。因此，当GCS资源被重新灌入的同时，SMON确定需要被恢复的blocks的集合。这个集合被称作恢复集。因为，使用cache 融合算法，一个Instance传送这些blocks的内容到请求的Instance，而不需要将这些blocks写入磁盘。这些blocks在磁盘上的版本可能不包含其他Instance进程的data的修改操作的blocks。这意味着SMON需要合并所有失败的Instance的redo logs来确定恢复集。这是因为一个失败的线程可能导致一个在redo 中的hole(洞)需要用指定的block填补。所以失败的Instance的redo 线程不能被连续的应用。同时，活动的Instances的redo 线程不需恢复，因为SMON可以使用过去和当前的通信缓冲的镜像。
④用于恢复的缓冲空间被分配，并且那些之前读取redo logs被辨识的资源被声明为恢复资源。这避免了其他Instance访问这些资源。
⑤所有在随后的恢复操作中需要的资源被获得，并且GRD当前是不冻结的。任何不需恢复的data block现在可以被访问。所以当前系统时部分可用的。此时，假设有过去或当前的blocks镜像需要被恢复，而其在cluster Database中的其他caches中，对于这些特殊的blocks，最近的镜像是开始恢复点。如果对于要恢复的block，过去镜像和当前镜像缓冲都不在活动的Instance的caches中，则SMON将写入一个log，表明合并失败。SMON会对第三步中辨识的每个block进行恢复和写入，在恢复之后会马上释放资源，从而使更多的资源在恢复时可以被使用。
当所有的block被恢复，占用的恢复资源被释放，则系统再次可用。
note：在恢复中，log合并的开支和失败的Instances的数目是成比例的，并且与每个Instance的redo logs的大小有关。

2)Instance recovery和Database availability
在进行Instance恢复时，每一步执行时数据库的可用程度：
A. RAC运行在多节点上
B. 有节点失败被检测到
C. GRD的队列部分被重新设置；资源管理被重新分配到活动的nodes。此操作的执行比较快
D. GRD的缓冲部分被重新设置，SMON读取失败Instance的redo logs辨识那些需要恢复的blocks的集合
E. SMON向GRD发起请求，获得所有在需要恢复的blocks集合中的Database blocks。当请求结束，所有的其他的blocks都可被访问了
F. Oracle执行滚动的向前恢复。失败线程的redo logs被应用到Database，并且那些被完全恢复的blocks将马上可以被访问
G. Oracle执行滚回恢复。对于尚未提交的事务，undo blocks被应用到Database中
H. Instance的恢复完成，所有的data可以被访问

43. 请叙述RAC的是否需要额外的内存需求 ？

  正确回答通过率：36.0% 

[ 详情 ] 推荐指数： ★★★ 试题难度： 高难

RAC特有的内存多数是在SGA创建时从shared pool中分配的。因为blocks可能跨越Instances被缓冲，必须要求更大的缓冲区。因此，当将single Instance的Database迁移到RAC中时，保持每个Instance的请求工作量都能通single-instance时的情况，则需要对运行RAC的Instance增大10%的buffer cache和15%的shared pool。这些值只是基于RAC大小的经验，一个初始的尝试值。一般会大于此值。
如果正在使用推荐的自动内存管理特性，可以通过修改SGA_TARGET初始参数来设置。但考虑到同样数量的user访问被分散到多个nodes中，每个Instance的内存需求可以被降低。
实际资源的使用可以通过查询每个Instance中的GCS和GES实体中的视图V$RESOURC{E}_{L}IMIT视图CURREN{T}_{U}TILIZATION和MA{X}_{U}TILIZATION字段，具体语句为：SELECTresourc{e}_{n}ame,curren{t}_{u}tilization,ma{x}_{u}tilizationFROMv$resource_limit WHERE resource_name like ‘g%s_%’;

44. 请说明什么是RAC全局动态性能视图 ？

 正确回答通过率：69.0% 

[ 详情 ] 推荐指数： ★★★★ 试题难度： 中级

全局动态性能视图显示所有开启并访问RAC Database的Instances相关的信息。而标准动态性能视图只显示了本地Instance的相关信息。

对于所有V$类型的视图，都会对应一个GV$视图，除了几个别的特殊情况。除了V$视图中的columns，GV$视图中包含了一个名为INST_ID的额外的column，显示了RAC中的Instance number。可以在任何开启的Instance上访问GV$。

为了查询GV$视图，每个Instance上的初始PARALLE{L}_{M}A{X}_{S}ERVERS初始化参数至少设置为1。这是由于对GV$的查询使用了特殊的并发执行。并发执行的协调者运行在客户端连接的Instance上，并且每个Instance上分配一个slave用于查询其潜在的V$视图。如果有一个Instance上的PARALLEL_MAX_SERVERS被设置为0，则无法获得该node的信息，同理，如果所有的并发servers非常忙，则也无法获得结果。在以上两种情况下，不会获得提示或错误信息

45. 简述虚拟IP地址如何应用到RAC环境 ？

  正确回答通过率：68.0% 

[ 详情 ] 推荐指数： ★★★★ 试题难度： 中级

当一个node完全失败，虚拟IP地址(VIP)是关于所有有效应用的。当一个节点失败，其相关的VIP自动的分派到cluster中的其他node上。当这种情况出现时：

• crs在另外一个node的网卡的MAC地址上绑定这个ip,对用户来说是透明的。对于直接连接的客户端，会显示errors。
• 随后发往VIP的数据包都将转向新的节点，它将给客户端发送error RST返回包。从而使客户端快速的获得errors信息，进行对其他节点的连接重试。
  如果不使用VIP，则一个node失败后，发往该节点的连接将等待10分钟的TCP过期时间。

46. 简述PostgreSQL的主从复制的机制 ？

  正确回答通过率：33.0% 

[ 详情 ] 推荐指数： ★★★★ 试题难度： 高难

postgresql主从复制是一种高可用解决方案，可以实现读写分离。postgresql主从复制是基于xlog来实现的，主库开启日志功能，从库根据主库xlog来完成数据的同步。
主从复需要注意的地方：
启动从库之前，不能执行初始化。
启动从库之前，需要通过base_backup从主服务器上同步配置与数据。
启动从库之前，需要对同步之后的配置文件进行修改。
启动从库之前，需要设置一个恢复的配置文件。
从库只能读，不能写。

47. 简述PostgreSQL的主从配置过程和基本流程 ？

 正确回答通过率：80.0% 

[ 详情 ] 推荐指数： ★★★★★ 试题难度： 中级

主从复制的实现，这里以两台虚拟机为例，主节点IP是192.168.56.201，从节点IP是192.168.56.202，这里两台机器都是通过源码编译安装的方式安装的postgresql，版本是11.4。编译安装指定的前缀是/usr/local，因此安装完成，可执行程序会在/usr/local/bin目录下。
首先需要在主库上初始化数据库，并启动数据库服务。
启动的时候，不能以root用户来启动。
编译安装不会创建postgres用户，因此我们需要先创建postgres用户和用户组。 我们会将postgresql数据存储路径设置在/home/postgres/data下。
groupadd postgres
useradd -g postgres postgres
切换用户，然后初始化数据库。
初始化成功之后，会有个提示，如何启动数据库，按照提示命令，我们启动数据库。
/usr/local/bin/pg_ctl -D /home/postgres/data -l logfile start
这里启动数据库之后，我们登陆数据库，做两件事情：准备一些数据，将来从节点同步之后，用来做数据验证。创建一个admin/123456的用户，用来做主从复制。
这样在主库上的操作就完成了，接下来就是修改配置文件，然后重启主库。
修改pg_hba.conf，增加刚才创建的用户到文件末尾，method指定为md5，表示密码开启md5验证。
修改postgresql.conf，开启注释，并修改以下配置：
listen_addresses=”*”
wal_level=hot_standby
max_wal_senders=2
wal_keep_segments=64
max_connections=100
重启主库，至此，完成主库的所有准备工作：
/\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
下面就是配置和启动从库了，前面注意事项里面提到，不能初始化从库，因为我们需要首先从主库备份数据，备份之后，从库的/home/postgres/data里面的数据和配置信息就和主库一致了。
首先从库也需要postgres/postgres用户组和用户，先创建：
groupadd postgres
useradd -g postgres postgres
之后，切换到postgres用户，进行数据备份和启动操作。
首先是利用base_backup命令进行备份：
/usr/local/bin/pg_basebackup -h 192.168.56.201 -p 5432 -U admin -F p -P -D /home/postgres/data
因为是从库访问，而且是用的admin用户，因此需要输入密码。这里显示备份成功。
因为配置postgresql.conf是从主库同步过来的，这里需要修改一些配置，改为从库的配置：
#wal_level=hot_standby #从库不需要这个配置
#max_wal_senders=2 #同上
#wal_keep_segments=64 #同上
hot_standby=on #开启hot_standby模式
max_standby_streaming_delay=30s #可选，流复制最大延迟
wal_receiver_status_interval=10s #可选，向主库报告状态的最大间隔时间
hot_standby_feedback=on #可选，查询冲突时向主库反馈
max_connections=1000 #最大连接数一般大于主库就行
还需要准备一个恢复配置文件，这个文件在安装postgresql时，会生成到/usr/local/share/postgresql目录下，名字是recovery.conf.sample。我们复制并修改名称为recovery.conf并放置在/home/postgres/data目录下，修改配置：
recovery_target_timeline = ‘latest’
standby_mode = on
primary_conninfo = ‘host=192.168.56.201 port=5432 user=admin password=123456’
这三个配置很直观，recovery_target_timeline=’latest’表示恢复最新的数据，standby_mode表示从节点的角色是备选，primay_conninfo表示主库连接信息。
至此，从库的配置工作准备完成，接着就可以启动数据库了。
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
主从复制到此就配置完成了，接下来就是验证阶段：
1、从主从机器运行的进程验证：
主节点服务器会增加一个walsender进程
从节点服务器增加一个walreceiver进程
2、从数据上验证：
主库在首次启动的时候，没有做主从配置之前，就插入了4条记录在test数据库xx_user表中。如今再次插入一条数据，也显示成功，查询会显示5条记录。
从库在首次启动之后，数据是从主库备份过来的，第一次进入查找就有4条记录。等主库插入一条记录之后，再次查看是5条记录，从库数据均同步成功，表示主从复制配置正确。
最后我们在从库中做插入操作，显示操作失败，因为从库是只读的，不能做增删改的写操作，只能查询。
3、这里可以从/usr/local/bin/pg_controldata /home/postgres/data命令的结果状态中可以验证，主从关系，主库的集群状态是in production，从库是in archive recovery，当我们的主库崩溃，我们可以切换从库为主库。这时候主库状态是shut down，而从库是in production。这里我们模拟停掉主库。
pg_ctl stop -m fast
马上在从库上切换从库为主库：
pg_ctl promote
这里显示了从库的状态由in archive recovery 变为in production的截图：
正常从库的状态：
主库shutdown，从库执行切换主库操作之后：