备份恢复时间最长的是

是Oracle的备份策略。采用Oracle建议的备份策略，最长的恢复时间可达48小时。Oracle不仅提供性能卓越且具有杰出成本效益的数据库和先进的多模型融合数据库管理系统，还提供内存中数据库、NoSQL数据库和MySQL数据库。

1 如何安装MySQL事务数据库

MySQL数据库分二种类型，一种是传统的数据表格式，一种是支持事务处理的数据表格式（InnoDB,BDB，其中以InnoDB为主），下面我介绍一下关于MySQL事务处理数据库的安装及使用方法 你先要去下载一下Mysql max版的安装程序，下载地址： 按常规的方法进行安装 安装完成后，启动mysqlbinWinMySQLadmin 再退出 运行 mysqlbinmydqld-nt --remove mysqlbinmysqld-max-nt --install 以上二行是去掉不支持事务处理的mysql服务，改成支持mysql事务处理的服务 然后在c：下建一个ibdata目录及iblogs目录，当然名字可以不一样，记住这二个名字及盘符，以后要用到，你也可以不建在C盘，然后，打开c:winnt或c:windows目录下的my。

ini，在最后添加：[code] innodb_data_file_path = ibdata1:2000M;ibdata2:2000M innodb_data_home_dir = c:ibdata set-variable = innodb_mirrored_log_groups=1 innodb_log_group_home_dir = c:iblogs set-variable = innodb_log_files_in_group=3 set-variable = innodb_log_file_size=30M set-variable = innodb_log_buffer_size=8M innodb_flush_log_at_trx_mit=1 innodb_log_arch_dir = c:iblogs innodb_log_archive=0 set-variable = innodb_buffer_pool_size=80M set-variable = innodb_additional_mem_pool_size=10M set-variable = innodb_file_io_threads=4 set-variable = innodb_lock_wait_timeout=50 [/code] 其中 innodb_data_file_path = ibdata1:2000M;ibdata2:2000M 这一行中的2000M可以自己改成200m，看你盘的容量大小，mysql推荐10G及以上的硬盘空间最好用这样的设置； 以下这一行 innodb_data_home_dir = c:ibdata 也可以改成你自己起的目录，主要是看你自己在刚才建的目录在哪里啦 按照以上的方法，你已经安装好了mysql的事务数据库，不过你要是按照mysql手册上的方法安装，把上面的一段配制放到my。 f是去的话，可是会出错哦 好了，现在让我们试试看是不是安装完成了，启动apache，或iis，在服务里启动mysql的服务，打开myadmin，输入：SHOW variables like "have_%" 你要是看到下面的结果，那说明你安装成功了。

2 Windows下MySQL策略有哪些

本次活动将重点关注世界上最流行的开源数据库最新版本MySQL 5。

5，其在Windows上运行时能提供高达1500%的性能优势。 此次活动还将详细介绍，利用全新升级的MySQL企业版，Oracle如何超过Microsoft SQL Server，节省高达90%总体拥有成本，该企业版目前包括了建模、开发、监测、管理和基于Windows 的MySQL应用程序备份等的一整套可视化工具。

论坛将详细介绍对Windows用户和独立软件开发商的益处 利用在Windows平台上运行的MySQL企业版，甲骨文使客户能够大幅降低其在开发网络应用、部门级的应用和嵌入式应用软件的总体拥有成本。同时，借助甲骨文公司世界一流的24x7全天候服务支持，客户能实现更高的MySQL性能，跨平台的灵活性和提高管理。

首届MySQL on Windows在线论坛将阐述： 为什么MySQL on Windows既受企业用户也受嵌入式独立软件供应商的热烈欢迎。 MySQL为什么非常适合Windows环境，未来将会有什么样的里程碑以实现MySQL在Microsoft平台上更好运行。

哪些可视化工具可用来有效地开发、部署和管理MySQL on Windows的应用程序。 如何推出基于Windows平台上的MySQL高可用关键业务应用程序。

安全解决方案供应商SonicWall公司为何选择MySQL而没有选择Microsoft SQL Server，以及他们如何成功地提供基于MySQL的解决方案。 甲骨文公司工程设计副总裁Tomas Ulin表示：“通过选择MySQL on Windows，客户能极大地降低成本和提高对跨平台的支持。

甲骨文已经推出了MySQL 5。5 和 MySQL 企业版的主要增强功能，这些功能将为客户带来巨大的益处。

对于正在创建和部署关键网络业务和嵌入式应用软件的独立软件开发商和企业用户来说，MySQL是替代Microsoft SQL Server的一个极具吸引力的选择。” SonicWall产品管理总监Jan Sijp说：“把MySQL嵌入到我们的安全产品中已被证明是明智选择，通过与我们的自身专业相结合，MySQL能够帮助我们为客户提供高度可靠的关键解决方案，客户将能从集成、方便使用的解决方案中受益，而不必安装一个单独的数据库。

除了为客户减少复杂度之外，我们也降低了内部开发、测试和支持的成本。”。

3 MYsql和sql到底是不是一个东西

MYsql和sql不同，为了表达的更科学更准确，我介绍你看比较权威的文章，大家一起学习，声明，下面不是我的作品，请注意尊重版权。

文章来源：数据库联盟网 发布时间：2005-03-25 07:30:55 对于程序开发人员而言，目前使用最流行的两种后台数据库即为MySQL and SQL Server。 这两者最基本的相似之处在于数据存储和属于查询系统。

你可以使用SQL来访问这两种数据库的数据，因为它们都支持ANSI-SQL。还有，这两种数据库系统都支持二进制关键词和关键索引，这就大大地加快了查询速度。

同时，二者也都提供支持XML的各种格式。 除了在显而易见的软件价格上的区别之外，这两个产品还有什么明显的区别吗？在这二者之间你是如何选择的？让我们看看这两个产品的主要的不同之处，包括发行费用，性能以及它们的安全性。

根本的区别是它们遵循的基本原则 二者所遵循的基本原则是它们的主要区别：开放vs保守。 SQL服务器的狭隘的，保守的存储引擎与MySQL服务器的可扩展，开放的存储引擎绝然不同。

虽然你可以使用SQL服务器的Sybase引擎，但MySQL能够提供更多种的选择，如MyISAM, Heap, InnoDB, and Berkeley DB。 MySQL不完全支持陌生的关键词，所以它比SQL服务器要少一些相关的数据库。

同时，MySQL也缺乏一些存储程序的功能，比如MyISAM引擎联支持交换功能。 发行费用：MySQL不全是免费，但很便宜 当提及发行的费用，这两个产品采用两种绝然不同的决策。

对于SQL服务器，获取一个免费的开发费用最常的方式是购买微软的Office或者Visual Studio的费用。但是，如果你想用于商业产品的开发，你必须还要购买SQL Server Standard Edition。

学校或非赢利的企业可以不考虑这一附加的费用。 性能：先进的MySQL 纯粹就性能而言，MySQL是相当出色的，因为它包含一个缺省桌面格式MyISAM。

MyISAM 数据库与磁盘非常地兼容而不占用过多的CPU和内存。MySQL可以运行于Windows系统而不会发生冲突，在UNIX或类似UNIX系统上运行则更好。

你还可以通过使用64位处理器来获取额外的一些性能。因为MySQL在内部里很多时候都使用64位的整数处理。

Yahoo！商业网站就使用MySQL作为后台数据库。 当提及软件的性能，SQL服务器的稳定性要比它的竞争对手强很多。

但是，这些特性也要付出代价的。 比如，必须增加额外复杂 *** 作，磁盘存储，内存损耗等等。

如果你的硬件和软件不能充分支持SQL服务器，我建议你最好选择其他如DBMS数据库，因为这样你会得到更好的结果。 安全功能 MySQL有一个用于改变数据的二进制日志。

因为它是二进制，这一日志能够快速地从主机上复制数据到客户机上。 即使服务器崩溃，这一二进制日志也会保持完整，而且复制的部分也不会受到损坏。

在SQL服务器中，你也可以记录SQL的有关查询，但这需要付出很高的代价。 安全性 这两个产品都有自己完整的安全机制。

只要你遵循这些安全机制，一般程序都不会出现什么问题。 这两者都使用缺省的IP端口，但是有时候很不幸，这些IP也会被一些黑客闯入。

当然，你也可以自己设置这些IP端口。 恢复性：先进的SQL服务器 恢复性也是MySQL的一个特点，这主要表现在MyISAM配置中。

这种方式有它固有的缺欠，如果你不慎损坏数据库，结果可能会导致所有的数据丢失。 然而，对于SQL服务器而言就表现得很稳键。

SQL服务器能够时刻监测数据交换点并能够把数据库损坏的过程保存下来。 根据需要决定你的选择 对于这两种数据库，如果非要让我说出到底哪一种更加出色，也许我会让你失望。

以我的观点，任一对你的工作有帮助的数据库都是很好的数据库，没有哪一个数据库是绝对的出色，也没有哪一个数据库是绝对的差劲。 我想要告诉你的是你应该多从你自己的需要出发，即你要完成什么样的任务？而不要单纯地从软件的功能出发。

如果你想建立一个。服务器体系，这一体系可以从多个不同平台访问数据，参与数据库的管理，那么你可以选用SQL服务器。

如果你想建立一个第三方站点，这一站点可以从一些客户端读取数据，那么MySQL将是最好的选择。 这两者数据库都能够在。

或J2EE下运行正常，同样，都能够利用RAID。 。

4 mysql中事务和存储过程的区别

存储过程是：

通过一系列的SQL语句， 根据传入的参数（也可以没有）， 通过简单的调用，

完成比单个SQL语句更复杂的功能， 存储在数据库服务器端，只需要编译过一次之后再次使用都不需要再进行编译。主要对存储的过程进行控制。

事务是一系列的数据更改 *** 作组成的一个整体。一旦事务中包含的某 *** 作失败或用户中止，用户可以控制将事务体中所有 *** 作撤消，返回事务开始前的状态。

事务中的 *** 作是一个整体，要么整体完成，要么全部不做。从而保证了数据的完整性。

Mysql中，MyISAM存储引擎不支持事务，InnoDB支持。

两者都是数据库中非常重要的知识。

5 有关数据库最基本最基础知识

一 事务处理介绍 事务是这样一种机制，它确保多个SQL语句被当作单个工作单 元来处理。

事务具有以下的作用： 一致性：同时进行的查询和更新彼此不会发生冲突，其他 用户不会看到发生了变化但尚未提交的数据。 可恢复性：一旦系统故障，数据库会自动地完全恢复未完 成的事务。

二 事务与一致性 事务是完整性的单位，一个事务的执行是把数据库从一个一 致的状态转换成另一个一致的状态。因此，如果事务孤立执行时 是正确的，但如果多个事务并发交错地执行，就可能相互干扰， 造成数据库状态的不一致。

在多用户环境中，数据库必须避免同 时进行的查询和更新发生冲突。这一点是很重要的，如果正在被 处理的数据能够在该处理正在运行时被另一用户的修改所改变， 那么该处理结果是不明确的。

不加控制的并发存取会产生以下几种错误： 1 丢失修改（lost updates） 当多个事务并发修改一个数据时，不加控制会得出错误的结 果，一个修改会覆盖掉另一个修改。 2 读的不可重复性 当多个事务按某种时间顺序存取若干数据时，如果对并发存 取不加控制，也会产生错误。

3 脏读（DIRDY DATA），读的不一致性 4 光标带来的当前值的混乱 事务在执行过程中它在某个表上的当前查找位置是由光标表 示的。光标指向当前正处理的记录。

当处理完该条记录后，则指 向下一条记录。在多个事务并发执行时，某一事务的修改可能产 生负作用，使与这些光标有关的事务出错。

5 未释放修改造成连锁退出 一个事务在进行修改 *** 作的过程中可能会发生故障，这时需 要将已做的修改回退（Rollback）。如果在已进行过或已发现错 误尚未复原之前允许其它事务读已做过修改（脏读），则会导致 连锁退出。

6 一事务在对一表更新时，另外的事务却修改或删除此表的 定义。 数据库会为每个事务自动地设置适当级别的锁定。

对于前面 讲述的问题：脏读、未释放修改造成的连锁退出、一事务在对一 表更新时另外的事务却修改或删除此表的定义，数据库都会自动 解决。而另外的三个问题则需要在编程过程中人为地定义事务或 加锁来解决。

三 事务和恢复 数据库本身肩负着管理事务的责任。事务是最小的逻辑工作 单元，在这个工作单元中，对数据库的所有更新工作，要么必须 全部成功，要么必须全部失败（回退）。

只要应用程序指定了某 段程序为一个事务并做了相应的处理（提交或回退），数据库系 统会自动维护事务本身的特性。 四 ORACLE数据库的事务定义 ORACLE事务从MIT、ROLLBACK、连接到数据库或开始第一 条可执行的SQL语句时开始，到一条MIT、ROLLBACK语句或退出 数据库时结束。

如果在一个事务中包含DDL语句，则在DDL语句的 前后都会隐含地执行MIT语句，从而开始或结束一个事务。 如果一个事务由于某些故障或者由于用户改变主意而必须在 提交前取消它，则数据库被恢复到这些语句和过程执行之前的状 态。

利用ROLLBACK语句可以在MIT命令前随时撤消或回退一个 事务。可以回退整个事务，也可以会退部分事务，但是不能回退 一个已经被提交的事务。

回退部分事务的ROLLBACK命令为： ROLLBACK to savepoint 存储点名 存储点是用户放入事务中的标记，用来表示一个可被回退的 位置。存储点通过在事务中放入一个SAVEPOINT命令而 入。

该 命令的语法是： SAVEPOINT 存储点名 如果在ROLLBACK语句中没有给出存储点名，则整个事务被回 退。 五 SYBASE数据库的事务定义 SYBASE通过使用BEGIN TRANsaction和MIT TRANsaction命令指 示SQL将任意数目的语句作为一个单元来处理。

ROLLBACK TRANsaction 命令则允许用户恢复到事务的开始，或恢复到事务内部已经被用SAVE TRANsaction命令定义的存储点上。 BEGIN TRANsaction和MIT TRANsaction能够包含任意数目的SQL 语句和存储过程，方法很简单： BEGIN TRANsaction [事务名称] MIT TRANsaction 如果一个事务由于某些故障或者由于用户改变主意而必须在提交 前取消它，则数据库被恢复到这些语句和过程执行之前的状态。

利用ROLLBACK TRANsaction命令可以在MIT TRANsaction命令 前随时回退一个事务。可以回退整个事务，也可以回退部分事务，但 是不能回退一个已经被提交的事务。

ROLLBACK TRANsaction命令为： ROLLBACK TRANsaction [事务名|存储点名] 存储点名是用户放入事务中的标记，用来表示一个可以被回退的 位置。存储点名通过在事务中放入一个SAVE TRANsaction命令而 入。

该命令的句法是： SAVE TRANsaction 存储点名 如果在ROLLBACK TRANsaction中没有给出存储点名或事务名，则 事务被回退到批处理中的第一个BEGIN TRANsaction语句处。

MySQL在互联网应用中已经遍地开花，但是在银行系统中，还在生根发芽的阶段。本文记录的是根据某生产系统实际需求，对数据库高可用方案从需求、各高可用技术特点对比、实施、测试等过程进行整理，完善Mysql高可用方案，同时为后续开展分布式数据库相关测试做相应准备。

存储复制技术： 传统IOE架构下，常用高可用方案，靠存储底层复制技术实现数据的一致性，优点数据安全性有保障，限制在于是依赖存储硬件，实施成本较高。

keepalived+双主复制： 两台MySQL互为主从关系，即双主模式，通过Keepalived配置虚拟IP，实现当其中的一台数据库故障时，自动切换VIP到另外一台MySQL数据库，备机快速接管业务来保证数据库的高可用。

MHA： MHA部署在每台mysql服务器上，定时探测集群中的master节点，当master出现故障时，它可以自动将最新的slave提升为新的master，然后将所有其他的slave重新指向新的master，优点在最大程度保证数据的一致性的前提下实现快速切换，最少需要3台服务器，存在数据丢失的可能性。

PXC： Percona eXtra Cluster是Percona基于galera cluster封装的集群方案。不同于普通多主复制，PXC保障强一致性和实时同步，故障切换更快。但是也需要3个节点，配置相对复杂，对性能也稍有影响。

除了上述方案外，还有MMM、Heartbeat+DRBD等高可用方案，此处不做详细介绍。

综合评估下，本次实施采用了 keepalived+mysql双主实现数据库同城双机房的高可用。MySQL版本为： 5721。 *** 作系统：Red Hat Enterprise Linux Server 73。

配置过程如下：

Mysql-master1: IP地址1 --以下简称master1

Mysql-master2: IP地址2 --以下简称master2

Mysql-vip : VIP地址 --应用连接使用

Mysql复制相关概念描述：

1、 Mysql主从复制图示：

2、 Mysql主从复制过程描述：

（1）master记录二进制日志：在每个事务更新数据完成之前，master在二进制日志记录这些改变。MySQL将事务写入二进制日志。在事务写入二进制日志完成后，master通知存储引擎提交事务。

（2）slave将master的binarylog拷贝到自己的中继日志：首先，slave开始一个工作线程——I/O线程。I/O线程在master上打开一个普通的连接，然后开始binlog dump process。Binlog dump process从master的二进制日志中读取事务，如果已经同步了master，它会睡眠并等待master产生新的事件。I/O线程将这些事务写入中继日志。

（3）SQL slave thread处理该过程的最后一步：SQL线程从中继日志读取事务，并重放其中的事务而更新slave的数据，使其与master中的数据一致。只要该线程与I/O线程保持一致，中继日志通常会位于OS的缓存中，所以中继日志的开销很小。

主主同步就是两台机器互为主的关系，在任何一台机器上写入都会同步至备端。

为了便于后续数据库服务器的扩展，且在整个复制环境中能够自动地切换，降低运维成本，引入了当前主流的基于Mysql GTID的复制特性，工作原理及优缺点简介如下。

3、 GTID工作原理简介：

（1） master更新数据时，会在事务前产生GTID，一同记录到Binlog日志中。

（2） slave的I/O线程将变更的binlog写入到本地的relay log中。

（3） slave的sql线程从relay log中获取GTID，然后对比slave端的binlog是否有记录。

（4） 如果有记录说明该GTID的事务已经执行，slave会忽略。

（5） 如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog。

（6） 在解析的过程中会判断是否有主键，如果有就用索引，如果没有就用全部扫描。

4、 GTID优点：

（1） 一个事务对应一个唯一的ID，一个GTID在一个服务器上 只会执行一次。（2） GTID是用来替代传统复制的方法，GTID复制与普通复制模式的最大不同就是不需要指定二进制文件名和位置。

（3） 减少手工干预和降低服务故障时间，当主机宕机之后会通过软件从众多的备机中提升一台备机为新的master。

5、 GTID也存在一些限制：

（1） 不支持非事务引擎。

（2） 不支持create table … select 语句复制(主库直接报错)。

（3） 不允许一个sql同时更新一个事务引擎表和非事务引擎表。

（4） 在一个复制组中，必须要求统一开启GTID或者是统一关闭GTID。

（5） 开启GTID需要重启(57版本除外)。

（6） 开启GTID后，就不再使用原理的传统复制方式。

（7） 不支持create temporary table 和 drop temporary table语句。

（8） 不支持sql_slave_skip_counter。

前置条件：

主备两个节点使用行内统一的安装部署脚本安装mysql5721介质(略)

Master1端创建应用的数据库(略)

1、 修改MySQL配置文件

参考相关配置规范，分别设置master1、master2的mycnf文件，

其中server-id参数设置为不同值;

由于后续keepalived会挂起VIP，应用通过VIP连接数据库，为了避免应用程序无法通过VIP访问，需将两个节点的bind-address参数注释掉；

2、 设置master1端自动半同步模式

Mysql的同步模式主要有如下3种：

a 主从同步复制：数据完整性好，但是性能消耗略高；

b 主从异步复制：性能消耗低，但容易出现不一致；

c 主从半自动复制：介于上述两种之间，既保持了数据的完整性，又提高了性能；

基于上述特性，建议采用半自动同步模式，由于后续要配置为双主模式，因此任一节点其角色既为master又为slave，因此相关的master/slave插件要同时配置，过程如下。

（1） 首先查看库是否支持动态加载(默认都支持)

（2） 主从库上分别安装插件

作为主库，安装插件semisync_masterso

作为从库，安装插件semisync_slaveso

（3） 安装完成后，从plugin表中能够看到刚刚安装的插件

（4） 分别打开主从库半同步复制

同时添加到各自的mycnf中，在后续数据库实例重启时自动加载该配置。

此时查看状态还没有启动

（5） 两个节点分别启动IO进程

（6） 查看半同步状态

3、 将master1设为master2的主服务器

（1）在master1主机上创建授权账户，允许在master2主机上连接

（2）将主库master1数据导出

（3）将mastersql传输到master2上并导入

（4）在master2端将master1设置为自己的主库，并开启slave功能

在master2上查看slave状态

至此master1到master2的主从复制关系已经建立完成。

4、 将master2设为master1的主服务器

在master1上执行

在master1上查看slave状态

1、keepalived相关概念说明：

keepalived是集群管理中保证集群高可用的一个软件解决方案，其功能类似于heartbeat，用来防止单点故障

keepalived是以VRRP协议为实现基础的，VRRP全称VirtualRouter Redundancy Protocol，即虚拟路由冗余协议。

虚拟路由冗余协议，可以认为是实现路由器高可用的协议，即将N台提供相同功能的路由器组成一个路由器组，这个组里面有一个master和多个backup，master上面有一个对外提供服务的vip，master会发组播（组播地址为2240018），当backup收不到vrrp包时就认为master宕掉了，这时就需要根据VRRP的优先级来选举一个backup当master，这样的话就可以保证路由器的高可用了。

keepalived主要有三个模块，分别是core 、check和vrrp。core模块为keepalived的核心，负责主进程的启动、维护以及全局配置文件的加载和解析。check负责 健康 检查，包括常见的各种检查方式。vrrp模块是来实现VRRP协议的。同时为了避免出现脑裂，应关闭防火墙或者开启防火墙但允许接收VRRP协议。

2、keepalived的安装配置

（1）配置本地yum源，在master1和master2两台服务器上安装keepalived的相关依赖包Kernel-devel/openssl-devel/popt-devl等

配置指向rhel-75iso的yum本地源，步骤略

注意：如不知道keepalived需要哪些依赖包，可到下载后的源码解压目录下查看INSTALL 文件内容，安装需要的依赖包，源码安装任何一个软件都要养成查看源码包文档的习惯，比如INSTALL，README,doc等文档，可以获得很多有用的信息。

（2）在两台mysql上解压缩并编译安装keepalived

（3）master1、master2上分别配置keepalivedconf

注意上图红色字体中两个节点配置相同处及差异。

说明：keepalived只有一个配置文件keepalivedconf，里面主要包括以下几个配置区域：

· global_defs：主要是配置故障发生时的通知对象以及机器标识。

· vrrp_instance：用来定义对外提供服务的VIP区域及其相关属性。

· virtual_server：虚拟服务器定义

（4）同时两个节点上都需要添加检测脚本

作用：是当mysql停止工作时自动关闭本机的keeplived服务，从而实现将故障主机踢出热备组，因每台机器上keepalived只添加了本机为realserver，所以当mysqld正常启动后，我们还需要手动启动keepalived服务。

（5）分别启动两个节点的keepalived服务

检查两个节点keepalived启动进程

检查两个节点的vip挂载情况

（6）主备机故障切换测试

停止master2的mysql服务，看keepalived 健康 检查程序是否会触发脚本，自动进行故障切换，步骤略

查看master1节点的VIP挂载情况，验证是否实现了自动切换，步骤略

说明在master2服务器的mysql服务发生故障时，触发了脚本，自动完成了切换。

（7）现在我们把master2的mysql服务开起来，并且keepalived的服务也需要启动。

即便master2的mysql服务和keepalived服务都重新开启了，master1仍然是主master了，master2未对主master的权利进行抢夺，说明设置的nopreempt参数生效了，为了保证群集的稳定性，生产环境不允许抢占配置，只有当master1的mysql服务坏掉的时候，master2才会再次成为主master，否则它永远只能当master1的备份。（注：nopreempt一般是在优先级高的mysql上设置）

Sysbench是一个模块化的、跨平台、多线程基准测试工具，可用于评估数据库负载情况，通过sysbench命令配置IP地址、端口号、用户名、密码连接到指定的数据库db1中，创建多个表，并快速插入指定条数的记录，观察主备库同步效率

(1) 下载开源工具sysbench-041214targz，放置在相应目录下并解压

(2) 使用iso配置本地yum源并安装Sysbench如下的依赖包(步骤略)：autoconf/automake/cdbs/debhelper(>=9)/docbook-xml/docbook-xsl/libmysqlclient15-dev/libtool/xsltproc

(3) 编译sysbench

编辑配置文件/etc/ldsoconf中添加mysql lib目录/mysql/app/5721/lib，并执行命令ldconfig生效

(4) 执行sysbench压测

使用sysbench工具向主节点的db1数据库中创建5张表，并且每张表分别插入10万条记录

同时观察备机同步效率

几个重要的参数说明：

B、半自动同步模式、异步模式切换测试

(1) 检查主备同步状态，及同步参数设置

rpl_semi_sync_master_enabled参数表示启用半同步模式；

rpl_semi_sync_master_timeout参数单位为毫秒，表示主库事务等待从库返回commit成功信息超过10秒就降为异步模式，不再等待从库，等探测到从库io线程恢复后，再返回为半自动同步；

rpl_semi_sync_master_wait_no_slave参数表示事务提交后需要等待从库返回确认信息；

(2) 将slave的io线程停止

(3) 使用sysbench向master写入少量的数据，本例创建一张表，并插入10条记录，命令包装在1sh测试脚本中

通过记录的时间戳发现，master在等待了slave10秒无响应，自动切换为异步模式，将数据写入本地。

(4) Slave启动io线程，数据自动追平

至此MySQL主主复制配置完成，运行在半自动同步模式，通过keepalived实现Mysql的HA高可用。

上线后应符合统一的标准监控策略，添加备份协议对数据进行周期备份并保存到带库中，以及定期的数据恢复测试。

由于是靠keepalived实现的高可用，还应将如下资源添加到监控管理平台：

1、 对每台数据库主机的3个keepalived进程进行监控；

2、 对主备节点的io线程、sql线程工作状态进行监控；

我以前备份都使用mysqldump 导成文本文件便于存放 但是速度很慢的 最快的备份方法当然是直接把数据目录copy一份了 但是一般来说 都要关闭 MySQL的服务才能做 不然在你copy的时候刚好还有人读写表那麻烦就大了 这次朋友介绍我使用mysqlhotcopy 就相当于上面 不过他可以热备份 他备份非常快 我测试一个 G的mysql他备份的时间在 分钟内完成

下面是它的介绍

mysqlhotcopy是一个Perl脚本 最初由Tim Bunce编写并提供 它使用LOCK TABLES FLUSH TABLES和cp或scp来快速备份数据库 它是备份数据库或单个表的最快的途径 但它只能运行在数据库目录所在的机器上 mysqlhotcopy只用于备份MyISAM 它运行在Unix和NetWare中

使用方法见下面的脚本 加入crotab中吧

#!/bin/sh    # Name:mysqlbackup sh    # PS:MySQL DataBase Backup Use mysqlhotcopy script     # Last Modify:     # 定义变量 请根据具体情况修改    # 定义脚本所在目录    scriptsDir=`pwd`

# 数据库的数据目录    dataDir=/var/lib/mysql

# 数据备份目录    tmpBackupDir=/tmp/mysqlblackup    backupDir=/backup/mysql

# 用来备份数据库的用户名和密码    mysqlUser=root    mysqlPWD= you password

# 如果临时备份目录存在 清空它 如果不存在则创建它    if [[ e $tmpBackupDir ]]; then      rm rf $tmpBackupDir/    else      mkdir $tmpBackupDir    fi

# 如果备份目录不存在则创建它    if [[ ! e $backupDir ]];then      mkdir $backupDir    fi

# 得到数据库备份列表 在此可以过滤不想备份的数据库    for databases in `find $dataDir type d | \      sed e s/\/var\/lib\/mysql\/// | \      sed e s/test// `; do      if [[ $databases == ]]; then        continue      else

# 备份数据库    /usr/bin/mysqlhotcopy user=$mysqlUser password=$mysqlPWD q $databases $tmpBackupDir        dateTime=`date +%Y %m %d %H:%M:%S `        echo $dateTime Database:$databases backup success! >>MySQLBackup log      fi    done

# 压缩备份文件    date=`date I`    cd $tmpBackupDir    tar czf $backupDir/mysql $date tar gz /

#End完成

加入到crontab中设置每周 运行    /backup/blackup sh

注意:恢复数据库到备份时的状态

mysqlhotcopy 备份出来的是整个数据库目录 使用时可以直接拷贝到 mysqld 指定的 datadir (在这里是 /var/lib/mysql/)目录下即可 同时要注意权限的问题 如下例

shell> cp rf db_name /var/lib/mysql/

shell> chown R mysql:mysql /var/lib/mysql/ (将 db_name 目录的属主改成 mysqld 运行用户)

本套备份策略只能恢复数据库到最后一次备份时的状态 要想在崩溃时丢失的数据尽量少应该更频繁的进行备份 要想恢复数据到崩溃时的状态请使用主从复制机制(replication)

小技巧:

不想写密码在shell中的话 可以在root的home目录下建立一个f文件 以便让mysqlhotcopy从中读取用户名/密码     [mysqlhotcopy]    user=root    password=YourPassword    然后安全起见 chmod一下     chmod ~/f

附:mysqlhotcopy常用参数

·     allowold  如果目标存在不放弃(加上一个_old后缀重新命名它)     ·     checkpoint=db_name tbl_name 在指定的db_name tbl_name插入检查点条目     ·     debug   启用调试输出     ·     dryrun n  报告动作而不执行它们     ·     flushlog  所有表锁定后刷新日志     ·     keepold   完成后不删除以前(重新命名的)的目标     ·     method=mand  复制方法(cp或scp)     ·     noindices  备份中不包括全部索引文件 这样使备份更小 更快 可以在以后用myisamc rq重新构建索引     ·     password=password p password 当连接服务器时使用的密码 请注意该选项的密码值是不可选的 不象其它MySQL程序     ·     port=port_num P port_num 当连接本地服务器时使用的TCP/IP端口号     ·     quiet q  除了出现错误时保持沉默     ·     regexp=expr  复制所有数据库名匹配给出的正则表达式的数据库     ·     socket=path S path 用于连接的Unix套接字文件     ·     suffix=str  所复制的数据库名的后缀     ·     tmpdir=path  临时目录(代替/tmp)     ·     user=user_name u user_name 当连接服务器时使用的MySQL用户名

lishixinzhi/Article/program/MySQL/201311/29401

下面我们就看一下常见的备份工具，以及目前最流行的 Percona XtraBackup 的备份流程。

MySQL 常见的备份工具主要分为三种：

这里先说一下 binlog 备份，它只是把 binlog 又复制了一份，并且需要在逻辑备份或者物理备份的基础上才能进行数据恢复，无法单独进行数据恢复。

mysqldump 备份出的文件就是 sql 文件，其核心就是对每个表执行 select ，然后转化成相应的 insert 语句。mysqldump 的备份流程大致如下：

从上面可以看出在 mysqldump 备份期间，备份到某个数据库时，该数据库下的表都会处于只读状态，无法对表进行任何变更，直到该库下的表备份完毕，这对于线上环境一般是无法接受的。若是指定了--master-data或者 --dump-slave 则会在备份开始时加全局读锁（FLUSH TABLES WITH READ LOCK），直到备份结束。当然我们可以选一个从库进行备份，这样就不会影响线上业务。另外使用 mysqldump 备份还有一个最大的好处，因为备份出来的是 sql 语句，所以它支持跨平台和跨版本的数据迁移或者恢复，这是物理备份无法做到的。

但是也正是因为 mysqldump 备份出来的是 sql 语句，在使用时要更加注意，否则可能会酿成大祸。例如，使用 mysqldump 常见的问题有：

所以使用 mysqldump 时一定要了解各个选项的作用，以及确认备份出来的 sql 文件里会有什么 *** 作，会对现有数据造成什么影响。

Mydumper 原理与 Mysqldump 原理类似，最大的区别是引入了多线程备份，每个备份线程备份一部分表，当然并发粒度可以到行级，达到多线程备份的目的。这里不再单独介绍。

Percona XtraBackup 是 Percona 公司开发的一个用于 MySQL 数据库物理热备的备份工具，是基于 InnoDB 的崩溃恢复功能来实现的。它的基本工作原理如下：

Percona XtraBackup 在进行恢复时会应用拷贝的 redo log ，应用已提交的事务，回滚未提交的事物，将数据库恢复到一致性状态。因为 Percona XtraBackup 备份出来的是物理文件，所以在使用备份出的文件进行恢复或者迁移时，不会像 mysqldump 那样会存在很多问题。

使用 XtraBackup 备份时根据备份参数设置不同，对数据库的变更会造成不同程度的影响，具体影响会在下文分析。

通过对比发现，XtraBackup 具有对数据库影响小，且能快速恢复的优点，在日常备份中是首选；mysqldump 使用相对更加灵活，但是使用是要注意对数据库原有数据的影响。

备份策略主要有：全量备份和增量备份，再加上 binlog 备份。

目前去哪儿网数据库备份主要采用 XtraBackup 全量备份 +binlog 备份。数据库的重要级别不同，全量备份的频率不同。备份程序主要架构如下：

说明：

Percona XtraBackup 是目前备份 MySQL 使用最广泛的工具。在备份过程中，数据库可以进行正常的读写或者其他变更 *** 作，但是偶尔也会遇见备份引起的元数据锁，或提交事务时发现被 binlog lock 阻塞等情况。下面我们就看一下 Percona XtraBackup 的备份流程和加锁时机。

说明：以下对 Percona XtraBackup 的分析都是基于 2423 的版本，其他版本会略有差别，但是关键步骤基本相同。

XtraBackup 在备份开始时，会创建一个后台线程，专门用于拷贝数据库的 redo log 。首先 XtraBackup 会扫描每组 redo log 的头部，找出当前的 checkpoint lsn ，然后从该 lsn 后顺序拷贝所有的 redo log ，包括后续新产生的 redo log 。该线程会一直持续到将非事务表完全拷贝完成，才会安全退出。备份日志输出中会记录拷贝开始时的 checkpoint lsn 。日志输出如下：

在拷贝ibd文件之前，会先扫描数据库的数据文件目录，获取ibdata1，undo tablespaces及所有的ibd文件列表，并会记录相应的 space id，因为在恢复时需要这些 space id来找到对应 doublewrite buffer里页面的内容，以及对应的redo log条目。然后开始循环拷贝ibdata1，undo tablespaces及所有的ibd文件。

这里可通过设置--parallel进行多线程备份，提高物理文件的拷贝效率。不设置则默认为1。

在所有ibd文件拷贝完成后，XtraBackup开始备份非ibd文件。这一部分的逻辑比较复杂，因为备份非ibd文件前需要加锁，具体是否会加锁主要受到--no-lock 参数设置的影响。

若是设置了--no-lock为TRUE，则不会使用"FLUSH TABLES WITH READ LOCK"去加全局读锁，但是若备份过程中对non-InnoDB表执行了DDL或者DML *** 作， 这会导致备份的不一致，恢复出来的数据就会有问题。所以是不建议将--no-lock为TRUE，默认值是FALSE，也就是在不指定该选项的情况下会在备份非ibd文件前加全局读锁。

下面我们结合源码来看看判断是否加全局锁这部分的具体流程逻辑：

流程图如下：

总结来看：

1）若--no-lock为FALSE（默认值），则先施加全局读锁，然后再进行拷贝文件，另外若 --safe-slave-backup 设置为TRUE ，则会在加全局锁之前关闭SQL_THREAD线程；

2）若--no-lock为TRUE，则不会施加锁，直接进行拷贝文件。

加锁的逻辑主要由lock_tables_maybe实现,先看一下lock_tables_maybe源代码，如下：

lock_tables_maybe 函数简化处理流程如下：

1）若备份实例上已经加锁（ LOCK TABLES FOR BACKUP / FLUSH TABLES WITH READ LOCK）或者设置lock-ddl-per-table 则直接返回；

2）若支持备份锁，则执行LOCK TABLES FOR BACKUP；

3）若不支持备份锁，则执行 FLUSH TABLES WITH READ LOCK。根据相应选项设置，在执行该 *** 作前会判断是否有执行中的DDL/DML，以及等待超时时间，是否kill 对应的未结束的事务等。

从上文中我们还看到一个参数--safe-slave-backup ，该参数的主要作用是：

若是在从库执行的备份 *** 作时设置了该参数，可以防止因从库同步主库 *** 作，而导致XtraBackup长时间请求不到锁而造成备份失败。

若是设置了 --safe-slave-backup 为TRUE，那么会执行"STOP SLAVE SQL_THREAD"，并等待Slave_open_temp_tables 为零才开始拷贝非 ibd 文件，Slave_open_temp_tables 为零说明SQL thread执行的事务都已经完成，这样就能保证备份的一致性。并且此时也不会有在执行的事务阻塞 XtraBackup 施加全局锁。

备份完非 ibd 文件后，将会备份 slave 和 binlog 信息。

mysql-bin000004 2004 6b7bda9f-15f0-11ec-ba14-fa163ea367a4:1-83,9841546e-15f0-11ec-9557-fa163e736db4:1

需要注意，在支持备份锁的实例上备份，指定了 --slave-info 或--binlog-info 均会先施加 binlog 备份锁（ LOCK BINLOG FOR BACKUP），这会阻塞任何会更改 binlog 位点的 *** 作。

备份完数据库的所有文件和binlog等相关信息，备份工作就基本完成了，之后主要执行的 *** 作如下：

1）执行"FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS",将所有的redo log刷盘；

2）停止redo log复制线程；

3）释放全局读锁（备份锁），binlog锁；

4）开启SQL_THREAD；

5）拷贝ib_buffer_pool和ib_lru_dump文件；

6）生成配置文件backup-mycnf；

7）打印备份信息到xtrabackup_info文件，这些信息主要包含备份时使用的参数信息，备份起止时间，binlog位点信息，以及将会回到的lsn点。

下面是xtrabackup_info记录的部分内容：

加锁对应的函数是 mdl_lock_tables ，释放锁对应的函数是 mdl_unlock_all，主要是执行COMMIT，结束 mdl_lock_tables 中开启的显式事务，来释放MDL锁。mdl_lock_tables 流程如下：

上面参数--lock-ddl和--lock-ddl-per-table是在 Percona XtraBackup 248 之后添加的，因为 MySQL 57 新增了一个叫做 Sorted Index Builds 的功能，这会导致某些 DDL *** 作不记录重做日志而导致备份失败。使用--lock-ddl或--lock-ddl-per-table 就会在备份开始时施加锁，阻止 DDL *** 作。

另外，若备份时指定了--lock-ddl或--lock-ddl-per-table，则在备份非 ibd 文件时就不是再有加锁 *** 作。

注意：LOCK TABLES FOR BACKUP和LOCK BINLOG FOR BACKUP 语句只有在支持备份锁的实例上才会执行，Percona Server for MySQL已经在 5616-640 版本开始支持这种更加轻量的备份锁。

Q1: 使用 XtraBackup 备份的文件进行恢复时，恢复到哪个时间点？ A1：恢复到执行 LOCK BINLOG FOR BACKUP 或 FLUSH TABLES WITH READ LOCK 的时间点，因为这时任何改变 binlog 位点的 *** 作都会被阻塞，redo log和binlog 是一致的。

Q2: 在开启 binlog 的情况下，MySQL 的奔溃恢复是同时依赖 binlog 和 redo log 这两种日志的，为什么XtraBackup 不用备份binlog？

A2：因为在备份中有执行LOCK BINLOG FOR BACKUP/FLUSH TABLES WITH READ LOCK，阻止了任何改变binlog位点的 *** 作，这样只需要根据redo log将有commit log 的事务提交，没有commit log的事务进行回滚即可。

Q3: 使用Percona XtraBackup备份完成后redo的位点是和binlog是一样还是比binlog多一些？

A3：通过分析备份流程可以发现备份 binlog 位点信息（加binlog锁）是发生在停止 redo 拷贝线程前，而释放锁是在停止 redo 拷贝线之后，所以 redo log 会多一些。锁住了 binlog 保证了在该 binlog 位点前已经提交的事务的 redo log 都有 commit log 的信息，未提交的事物也就没有对应的 commit log 的信息，即便在锁住 binlog 后有 Innodb 表新的 DML 产生的 redo log ，但是事务无法提交，也就没有 commit log 的信息的，最后在回放的过程中对没有 commit log 的事务进行回滚就可以了。

Q4：Percona XtraBackup什么时候会加锁，以及影响加锁时间长度的因素有哪些？

A4：上面进行了分析，加锁 *** 作只在备份非 ibd 文件时执行，加锁时长主要和非事务表的数量和大小有关，非事务表的数量越多，体积越大，拷贝文件所用的时间越长，那么加锁时间也就越长。也会和 redo log 生成的速度有关，只是 redo log 刷盘受到多个因素的影响，未及时刷盘的 redo log 一般很小。

Q5：Percona XtraBackup 和mysqldump选择哪个更好？

A5：通过上面的的解析，若是整个实例备份，首先选择 Percona XtraBackup ，因为对数据库的影响最小。若只是备份某个库表，这个就要视数据量而定，若数据量不大可以使用 mysqldump 。注意，对数据库做备份时最好选择业务连接最少的从库，因为备份也会消耗一定的资源，避免影响业务。

以上就是关于备份恢复时间最长的是全部的内容，包括:备份恢复时间最长的是、mysql关于事物的常识、基于MySQL双主的高可用解决方案理论及实践等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！