数据库单节点停机

数据库单节点停机，就先停一个节点的实例

oracle用户下 srvctl stop instance -d <DATABASE NAME>-i <INSTANCE NAME>

或者直接用sqlplus / as sysdba 进去后

shutdown immediate

然后直接到grid用户下crsctl stop crs 即可，不需要再对nodeapp listner等资源进行 *** 作。

然后就可以关机换CPU了。 换完成以后启动机器，注意检查存储状态，查看共享磁盘状态有无变化。

没有问题的话，如果 CRS 是自动启动的，那么等待一定时间后，除了数据库实例以外，其他的资源应该已经启动完毕。 如果CRS不是自动启动的，就用 crsctl start crs命令启动。

用 crs_stat -t 检查资源状态都没问题后，再启动这个节点上的数据库实例

oracle用户下 srvctl start instance -d <DATABASE NAME>-i <INSTANCE NAME>

或者直接用sqlplus / as sysdba 进去后

startup

简单的说几句吧。其实这个解决方案呢，主要是要先考虑成本问题，其他的，技术问题其实都很容易解决，但是企业应用上，最大的限制就是成本。下面以ORACLE数据库为例，简单说说。希望对你有所帮助。(数据库类型并不重要，解决方案都是大同小异。)

1、基于存储层的容灾复制方案

这种技术的复制机制是通过基于SAN的存储局域网进行复制，复制针对每个IO进行，复制的数据量比较大；系统可以实现数据的同步或异步两种方式的复制。对大数据量的系统来说有很大的优势(每天日志量在60G以上),但是对主机、 *** 作系统、数据库版本等要求一致，且对络环境的要求比较高。

2、基于逻辑卷的容灾复制方案

这种技术的机制是通过基于TCP/IP的网络环境进行复制，由 *** 作系统进程捕捉逻辑卷的变化进行复制。其特点与基于存储设备的复制方案比较类似，也可以选择同步或异步两种方式，对主机的软、硬件环境的一致性要求也比较高，对大数据量的应用比较有优势。其目标系统如果要实现可读，需要创建第三方镜像。个人认为这种技术和上面提到的基于存储的复制技术比较适合于超大数据量的系统，或者是应用系统的容灾复制。

3、基于oracle redo log的逻辑复制方式

　使用这种方式的主要有一些第三方的软件，以及oracle自己的DATAGUARD 中的logical Standby。目前，国外已经有了很多比较成熟的产品及成功案例，国内也有类似的产品， 但在产品的成熟程度和成功案例上跟国外还有一定的差距。

　使用oracle以外的独立进程，捕捉redo log file 的信息，将其翻译成sql语句，再通过网络传输到目标端数据库，在目标端数据库执行同样的sql。如果其进程赶不上oracle日志切换，也可以捕捉归档日志中的内容。也有的产品在源端以事务为单位，当一个事务完成后，再把它传输到目标端。所有的产品一般都是以表为单位进行复制，同时也支持大部分DDL的复制(主要在oracle9i环境中)。

数据库的吞吐量太大时，其实据会有较大的延迟，当数据库每天的日量达到60G或更大时，这种方案的可行性交差；实施的过程可能会有一些停机时间，来进行数据的同步和配置的激活；复制环境建立起来以后，对数据库结构上的一些修改需要按照规定的 *** 作流程进行，有一定的维护成本。

加入两台mysql，以前的规则是key%2 == 0 进入库1，key%2 == 1 进入库2。在扩容方案中，可以将mysql配置信息修改为：库1的主从作为两台机器，库2同理，这样key%4 == 0 和==2进入库1，key%4 == 1或3进入库2。然后再做数据的清除工作。

---