MySQL丢数据及主从数据不一致的场景-lunique
MySQL丢数据及主从数据不一致的场景
1.相关知识点：
innodb_flush_log_at_trx_commit
innodb_flush_log_at_timeout
sync_binlog
relay log、relay log info、master info：
master-info-repository
relay-log-info-repository
sync_relay_log
sync_master_info
sync_relay_log_info
原文地址：https://www.sodocs.net/doc/c213466031.html,/25704976/viewspace-1318714/
随着对MySQL的学习，发现了MySQL的很多问题，最重要的就是丢数据的问题。对于丢数据问题，我们应该了解丢数据的场景，这样在以后的学习中多考虑如何去避免及解决这些问题。
2.MySQL数据库层丢数据场景
本节我们主要介绍一下在存储引擎层上是如何会丢数据的。
2.1.InnoDB丢数据
InnoDB支持事务，同Oracle类似，事务提交需要写redo、undo。采用日志先行的策略，将数据的变更在内存中完成，并且将事务记录成redo，顺序的写入redo日志中，即表示该事务已经完成，就可以返回给客户已提交的信息。但是实际上被更改的数据还在内存中，并没有刷新到磁盘，即还没有落地，当达到一定的条件，会触发checkpoint，将内存中的数据（page）合并写入到磁盘，这样就减少了离散写、IOPS，提高性能。
在这个过程中，如果服务器宕机了，内存中的数据丢失，当重启后，会通过redo日志进行recovery重做。确保不会丢失数据。因此只要redo能够实时的写入到磁盘，InnoDB 就不会丢数据。
先来看一下innodb_flush_log_at_trx_commit这个参数：
= 0 ：每秒 write cache & flush disk
= 1 ：每次commit都 write cache & flush disk
= 2 ：每次commit都 write cache，然后根据innodb_flush_log_at_timeout（默认为1s）时间 flush disk
从这三个配置来看，显然innodb_flush_log_at_trx_commit=1最为安全，因为每次commit都保证redo写入了disk。但是这种方式性能对DML性能来说比较低，在我们的测试中发现，如果设置为2，DML性能要比设置为1高10倍左右。
为什么oracle的实时写要比innodb的实时写性能更好？线程与进程？后面还需要研究
大家可以考虑一下0与2的区别？
在某些DML操作频繁的场景下，库的innodb_flush_log_at_trx_commit需要设置为2，这样就存在丢数据的风险：当服务器出现宕机，重启后进行crash recovery则会丢失innodb_flush_log_at_timeout秒内的数据。
PS:当开启了内部XA事务（默认开启），且开启binlog，情况稍有不一样，后面会进行介绍。
2.2.MyISAM丢数据
MyISAM存储引擎在我们的生产中用的并不多，但是系统的数据字典表元数据等都是存储在MyISAM引擎下。
MyISAM不支持事务，且没有data cache，所有DML操作只写到OS cache中，flush disk 操作均由OS来完成，因此如果服务器宕机，则这部分数据肯定会丢失。
2.3.主从复制不一致
主从复制原理：MySQL主库在事务提交时写binlog，并通过sync_binlog参数来控制binlog刷新到磁盘“落地”，而备库通过IO线程从主库读取binlog，并记录到本地的relay log中，由本地的SQL线程再将relay log的数据应用到本地数据库，如下图所示：
从上图我们可以看到，在主从环境中，增加了binlog，这就增加了环境的复杂性，因此也增加了丢数据以及数据不一致可能。
在分析这些丢数据的可能性之前，我们先了解一下binlog的刷新机制以及MySQL的内部XA 事务是如何保证binlog与redo的一致性的。
2.3.1.b inlog刷新机制
master写binlog与innodb引擎写redo类似，也有参数控制：sync_binlog = 0 ：表示MySQL不控制binlog的刷新，由文件系统自己控制它的缓存的刷新
> 0 ：表示每sync_binlog次事务提交，MySQL调用文件系统的刷新操作将缓存刷下去
其中最安全的就是=1，表示每次事务提交，MySQL都会把binlog缓存刷下去，这样在掉电等情况下，系统才有可能丢失1个事务的数据。当sync_binlog设置为1，对系统的IO消耗也是非常大的。
2.3.2.内部XA事务原理
MySQL的存储引擎与MySQL服务层之间，或者存储引擎与存储引擎之间的分布式事务，称之为内部XA事务。最为常见的内部XA事务存在与binlog与InnoDB存储引擎之间。在事务提交时，先写二进制日志，再写InnoDB存储引起的redo日志。对于这个操作要求必须是原子的，即需要保证两者同时写入，内部XA事务机制就是保证两者的同时写入。
XA事务的大致流程：
1.事务提交后，InnoDB存储引擎会先做一个PREPARE操作，将事务的XID写入到redo日
志中。
2.写binlog日志
3.再将该事务的commit信息写到redo log中
如果在步骤1和步骤2失败的情况下，整个事务会回滚，如果在步骤3失败的情况下，MySQL数据库在重启后会先检查准备的UXID事务是否已经提交，若没有，则在存储引擎层再进行一次提交操作。这样就保证了redo与binlog的一致性，防止丢数据。
2.3.3.m aster库写redo、binlog不实时丢数据的场景
上面我们介绍了MySQL的内部XA事务流程，但是这个流程并不是天衣无缝的，redo 的ib_logfile与binlog日志如果被设置非实时flush，就有可能存在丢数据的情况。
1.redo的trx_prepare未写入，但binlog写入，造成从库数据量比主库多。
2.redo的trx_prepare与commit都写入了，但是binlog未写入，造成从库数据量比主库少。
从目前来看，只能牺牲性能去换取数据的安全性，必须要设置redo和binlog为实时刷盘，如果对性能要求很高，则考虑使用SSD
2.3.4.s lave库写redo、binlog不实时丢数据的场景
master正常，但是slave出现异常的情况下宕机，这个时候会出现什么样的情况呢？如果数据丢失，slave的SQL线程还会重新应用吗？这个我们需要先了解SQL线程的机制。
slave读取master的binlog日志后，需要落地3个文件：relay log、relay log info、master info：
relay log：即读取过来的master的binlog，内容与格式与master的binlog 一致
relay log info：记录SQL Thread应用的relay log的位置、文件号等信息
master info：记录IO Thread读取master的binlog的位置、文件号、延迟等信息
因此如果当这3个文件如果不及时落地，则主机crash后会导致数据的不一致。
在MySQL 5.6.2之前，slave记录的master信息以及slave应用binlog的信息存放在文件中，即https://www.sodocs.net/doc/c213466031.html,与https://www.sodocs.net/doc/c213466031.html,。在5.6.2版本之后，允许记录到table中，参数设置如下：
master-info-repository = TABLE
relay-log-info-repository= TABLE
对应的表分别为mysql.slave_master_info与mysql.slave_relay_log_info，且这两个表均为innodb引擎表。
master info与relay info还有3个参数控制刷新：
sync_relay_log：默认为10000，即每10000次sync_relay_log事件会刷新到磁盘。为0则表示不刷新，交由OS的cache控制。
sync_master_info:若master-info-repository为FILE，当设置为0，则每次sync_master_info事件都会刷新到磁盘，默认为10000次刷新到磁盘；若master-info-repository为TABLE，当设置为0，则表不做任何更新，设置为1，则每次事件会更新表 #默认为10000
sync_relay_log_info：若relay_log_info_repository为FILE，当设置为0，交由OS刷新磁盘，默认为10000次刷新到磁盘；若relay_log_info_repository为TABLE，且为INNODB 存储，则无论为任何值，则都每次evnet都会更新表。
建议参数设置如下：
sync_relay_log=1
sync_master_info=1
sync_relay_log_info=1
master-info-repository = TABLE
relay-log-info-repository= TABLE
当这样设置，导致调用fsync()/fdatasync()随着master的事务的增加而增加，且若slave 的binlog和redo也实时刷新的话，会带来很严重的IO性能瓶颈。
2.3.5.m aster宕机后无法及时恢复造成的数据丢失
当master出现故障后，binlog未及时传到slave，或者各个slave收到的binlog不一致。且master无法在第一时间恢复，这个时候怎么办？
如果master不切换，则整个数据库只能只读，影响应用的运行。
如果将别的slave提升为新的master，那么原master未来得及传到slave的binlog 的数据则会丢失，并且还涉及到下面2个问题。
1.各个slave之间接收到的binlog不一致，如果强制拉起一个slave，则slave 之间数据会不一致。
2.原master恢复正常后，由于新的master日志丢弃了部分原master的binlog 日志，这些多出来的binlog日志怎么处理，重新搭建环境？
对于上面出现的问题，一种方法是确保binlog传到从库，或者说保证主库的binlog有多个拷贝。第二种方法就是允许数据丢失，制定一定的策略，保证最小化丢失数据。
1.确保binlog全部传到从库
方案一：使用semi sync（半同步）方式，事务提交后，必须要传到slave，事务才能算结束。对性能影响很大，依赖网络适合小tps系统。
方案二：双写binlog，通过DBDR OS层的文件系统复制到备机，或者使用共享盘保存binlog日志。
方案三：在数据层做文章，比如保证数据库写成功后，再异步队列的方式写一份，部分业务可以借助设计和数据流解决。
2.保证数据最小化丢失
上面的方案设计及架构比较复杂，如果能容忍数据的丢失，可以考虑使用淘宝的TMHA 复制管理工具。
当master宕机后，TMHA会选择一个binlog接收最大的slave作为master。当原master宕机恢复后，通过binlog的逆向应用，把原master上多执行的事务回退掉。
3.总结
通过上面的总结分析，MySQL丢数据的场景是五花八门，涉及到单库的丢数据场景、主从的丢数据场景以及MySQL内部XA事务原理等，相对还比较复杂，有点难以理解。
只有当我们了解了这些丢数据的场景，才能更好的去学习，并解决这些问题。
根据分布式领域的CAP理论（Consistency、Availability、Partition tolerance），任何的分布式系统只能同时满足2点，没办法三者兼顾。MySQL的主从环境满足Availability，且主从互不干扰，因此满足Partition tolerance，但是不满足Consistency，如果需要满足Consistency，则肯定会失去Partition tolerance，因此实现100%高可用性的MySQL主从架构还是非常困难的。只能通过一些设计去牺牲部分特性去满足另外的特性。
后续会重点对MySQL高可用性的架构方案进行进一步测试和研究。
PS:关于Partition tolerance解释：
Partition tolerance is sacrificed if certain requests are forced to wait for unbounded time because of a failure. This is most often the case when a node holding a lock cannot be reached, and quorum loss is not used to break the lock.
参考文档：
1.Innodb的log写入策略及主从同步：
https://www.sodocs.net/doc/c213466031.html,/?p=870
2.MySQL数据丢失讨论
https://www.sodocs.net/doc/c213466031.html,/?p=769
MySQL数据双向同步解决方案
1.mysql数据同步实现原理 即读写操作在两台服务器上进行，每台服务器即主也是从。当其中的任何一台服务器收到操作请求时，其进行相应的数据变化，并把变化的数据复制到另一台服务器中。 2.配置服务器master 初始服务器 通过mysql工具连接服务器master后，新建两个数据库audit，idm。导入初始化数据库文件，完成数据库的初始化 给用户授权 从开始菜单中打开mysql5的命令行，输入正确的密码，进入mysql控制台命令行模式后，输入如下命令： #授权来自192.168.0.189的backup用户拥有对所有库的复制数据的权限，该用户的密码设为123456 GRANT REPLICATION SLAVE ON *.* TO 'backup'@'192.168.0.189' IDENTIFIED BY '123456'; #刷新权限设置 FLUSH PRIVILEGES ; 修改配置文件 修改主目录中的my.inf文件，在mysqld下面加入如下内容 server-id = 1 log-bin=mysql-bin binlog-do-db = audit binlog-do-db = idm binlog-ignore-db = information_schema binlog-ignore-db = mysql binlog-ignore-db = test master-host = 192.168.0.189 master-user = backup master-password = 123456 master-port = 3306
replicate-do-db = audit replicate-do-db = idm master-connect-retry = 60 3.配置服务器slave 初始服务器 通过mysql工具连接服务器ha002后，新建两个数据库audit，idm。导入初始化数据库文件，完成数据库的初始化 给用户授权 从开始菜单中打开mysql5的命令行，输入正确的密码，进入mysql控制台命令行模式后，输入如下命令： #授权来自192.168.0.188的backup用户拥有对所有库的复制数据的权限，该用户的密码设为123456 GRANT REPLICATION SLAVE ON *.* TO 'backup'@'192.168.0.188' IDENTIFIED BY '123456'; #刷新权限设置 FLUSH PRIVILEGES ; 修改配置文件 修改主目录中的my.inf文件，在mysqld下面加入如下内容 server-id = 2 master-host = 192.168.0.188 master-user = backup master-password = 123456 master-port = 3306 relicate-do-db = audit replicate-do-db = idm master-connect-retry = 60 log-bin=mysql-bin binlog-do-db = audit binlog-do-db = idm binlog-ignore-db = information_schema
MySQL主从复制、搭建、状态检查、中断排查及备库重做 实战手册
美河学习在线https://www.sodocs.net/doc/c213466031.html, MySQL主从复制 MySQL主从复制、搭建、状态检查、中断排查及备库重做 本文档主要对MySQL主从复制进行简单的介绍，包括原理简介、搭建步骤、状态检查、同步中断及排查、备库重建。
目录 一、MySQL主从复制概述 (2) 1、主从复制简介 (2) 2、主从复制原理、机制 (2) 3、主从复制原理图 (3) 二、MySQL主从复制搭建 (4) 1、Master端配置部署 (4) 2、Slave端配置部署 (4) 3、建立主从同步 (4) 三、主从复制状态检查及异常处理 (6) 1、主从复制状态检查 (6) 2、IO_thread异常 (7) 3、sql_thread异常 (8) 4、主从复制延迟 (9)
一、MySQL主从复制概述 1、主从复制简介 MySQL主从复制就是将一个MySQL实例（Master）中的数据实时复制到另一个MySQL实例(slave)中，而且这个复制是一个异步复制的过程。 实现整个复制操作主要由三个进程完成的，其中两个进程在Slave（sql_thread和IO_thread），另外一个进程在 Master（IO进程）上。 2、主从复制原理、机制 要实施复制，首先必须打开Master端的binary log（bin-log）功能，否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。 复制的基本过程如下： 1)、Slave上面的IO_thread连接上Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容； 2)、Master接收到来自Slave的IO_thread的请求后，通过负责复制的IO进程根据请求信息读取制定日志指定位置之后的日志信息，返回给Slave 的IO_thread。返回信息中除了日志所包含的信息之外，还包括本次返回的信息已经到Master端的bin-log file的以及bin-log pos； 3)、Slave的IO_thread接收到信息后，将接收到的日志内容依次添加到Slave端的relay-log文件的最末端，并将读取到的Master端的 bin-log的文件名和位置记录到master-info文件中，以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log的哪个位置开始往后的日志内容，请发给我”； 4)、Slave的Sql_thread检测到relay-log中新增加了内容后，会马上解析relay-log 的内容成为在Master端真实执行时候的那些可执行的内容，并在本数据库中执行。
(完整word版)Oracle数据库系统紧急故障处理方法
Oracle数据库系统紧急故障处理方法 Oracle物理结构故障是指构成数据库的各个物理文件损坏而导致的各种数据库故障。这些故障可能是由于硬件故障造成的，也可能是人为误操作而引起。所以我们首先要判断问题的起因，如果是硬件故障则首先要解决硬件问题。在无硬件问题的前提下我们才能按照下面的处理方发来进一步处理。 控制文件损坏： 控制文件记录了关于oracle的重要配置信息，如数据库名、字符集名字、各个数据文件、日志文件的位置等等信息。控制文件的损坏，会导致数据库异常关闭。一旦缺少控制文件，数据库也无法启动，这是一种比较严重的错误。 损坏单个控制文件： 1. 确保数据库已经关闭，如果没有用下面的命令来关闭数据库： svrmgrl>shutdown immediate; 2. 查看初始化文件$ORACLE_BASE/admin/pfile/initORCL.ora,确定所有控制文件的路径。 3. 用操作系统命令将其它正确的控制文件覆盖错误的控制文件。 4. 用下面的命令重新启动数据库： svrmgrl>startup; 5. 用适当的方法进行数据库全备份。 损坏所有的控制文件： 1. 确保数据库已经关闭，如果没有用下面的命令来关闭数据库： svrmgrl>shutdown immediate; 2. 从相应的备份结果集中恢复最近的控制文件。对于没有采用带库备份的点可以直接从磁带上将最近的控制文件备份恢复到相应目录；对于采用带库备份的点用相应的rman脚本来恢复最近的控制文件。 3. 用下面的命令来创建产生数据库控制文件的脚本：
svrmgrl>startup mount; svrmgrl>alter database backup controlfile to trace noresetlogs; 4. 修改第三步产生的trace文件，将其中关于创建控制文件的一部分语句拷贝出来并做些修改，使得它能够体现最新的数据库结构。假设产生的sql文件名字为createcontrol.sql. 注意： Trace文件的具体路径可以在执行完第3）步操作后查看 $ORACLE_BASE/admin/bdump/alert_ORCL.ora文件来确定。 5. 用下面命令重新创建控制文件： svrmgrl>shutdown abort; svrmgrl>startup nomount; svrmgrl>@createcontrol.sql; 6. 用适当的方法进行数据库全备份。 重做日志文件损坏： 数据库的所有增、删、改都会记录入重做日志。如果当前激活的重做日志文件损坏，会导致数据库异常关闭。非激活的重做日志最终也会因为日志切换变为激活的重做日志，所以损坏的非激活的重做日志最终也会导致数据库的异常终止。在ipas/mSwitch中每组重做日志只有一个成员，所以在下面的分析中只考虑重做日志组损坏的情况，而不考虑单个重做日志成员损坏的情况。 确定损坏的重做日志的位置及其状态： 1. 如果数据库处于可用状态： select * from v$logfile; svrmgrl>select * from v$log; 2. 如果数据库处于已经异常终止： svrmlgr>startup mount; svrmgrl>select * from v$logfile;
数据库维护与故障恢复
数据库维护与故障恢复
数据库维护与故障恢复 为确保数据库安全，新思维医院信息管理系统采用了多种安全和应急预防机制，并提供相关的备份、紧缩和应急修复操作，以保障数据库系统的安全、高效和连续，即便在不可预测意外导致数据库损坏时，也可使用专用修复工具，从故障中安全快速且有效地恢复数据。 本文包括： ·Microsoft Access数据库被损坏的原因 ·有效防止数据库损坏的方法 ·定期或经常性地进行数据库备份和紧缩 ·从故障中恢复(修复被损坏的Access数据库) Microsoft Access数据库被损坏的原因 Microsoft Access数据库文件(.mdb)在某些突发或不可预料事件中可能导致损坏。已知mdb文件损坏的常见原因主要有四个： ●由于写入操作被中断使数据库处于置疑/损坏状态 ●网络硬件故障 ●在另一个程序中打开和保存 mdb 文件 ●计算机病毒 原因之一：由于写入操作被中断使数据库处于置疑/损坏状态 强烈建议通过程序提供的“退出”或“关闭”来正常关闭数据库和结束程序运行。但是，如果非正常终止程序，即Access数据库不正常关闭时，数据库正处于打开状态并正在写数据，则数据库引擎就会将该文件标记为置疑/损坏。如果手动关闭计算机之前没有先关闭Windows 或者断电，也可能会出现这种情况。其它情形还包括：在打开数据库的同时，没有关闭相关程序，但仍干扰数据库引擎向磁盘写入数据。例如，当网络遇到数据冲突或者磁盘驱动器故障时，就会出现这种情况。如果发生任何此类中断，数据库引擎就会将数据库标记为可能已被破坏。 当数据库引擎(Jet)开始写操作时，将设置一个标记，并在操作完成时重新设置该标记。如果写操作被中断，标记保持不变。当您要再次打开数据库时，Jet 确定标记是否已设置并报告数据库是否被破坏。在大多数情况下，数据库中的数据实际上没有被破坏，但设置的标记提醒Jet数据库可能已被破坏。如果是这种情况，压缩和/或修复数据库通常可以还原数据库。 原因之二：网络硬件故障 在这种情况下，数据库文件损坏与数据库引擎无关；文件损坏完全是由于外
MYSQL四种备份方法总结
MYSQL四种备份方法总结 Mysql数据库备份主要有4种方法： 1、mysqldump 2、直接拷贝(cp、tar,gzip,cpio) 3、mysqlhotcopy 4、同步复制 mysqldump生成能够移植到其它机器的文本文件，缺省地，文件内容包含创建正在倾倒的表的CREATE语句和包含表中行数据的INSERT语句。也就是说，mysqldump产生的输出可在以后用作mysql的输入来重建数据库。mysqldump比直接拷贝要慢些。 使用直接拷贝，如果正在备份的表正被读写就容易导致表损坏，而且不建议对isam表使用直接拷贝的方法来备份，因为ISAM表只能在相似的硬件结构的机器上拷贝。 1、mysqldump备份: 使用方法：mysqldump [OPTIONS] database [tables] 输出文件的开头看起来象这样： # MySQL Dump 6.0 # # Host: localhost Database: samp_db #--------------------------------------- # Server version 3.23.2-alpha-log # # Table structure for table 'absence' # CREATE TABLE absence( student_id int(10) unsigned DEFAULT '0' NOT NULL, date date DEFAULT '0000-00-00' NOT NULL, PRIMARY KEY (student_id,date) ); # # Dumping data for table 'absence' # INSERT INTO absence VALUES (3,'1999-09-03'); INSERT INTO absence VALUES (5,'1999-09-03'); INSERT INTO absence VALUES (10,'1999-09-08'); ...... 文件剩下的部分有更多的INSERT和CREATE TABLE语句组成。例： %mysqldump samp_db >/opt/mysqldatabak/samp_db.2006-5-15 %mysqldump samp_db | gzip >/usr/archives/mysql/samp_db.1999-10-02.gz #产生压缩备份 %mysqldump samp_db student score event absence >grapbook.sql #备份数据库的某些表 %mysqladmin -h https://www.sodocs.net/doc/c213466031.html, create samp_db %mysqldump samp_db | mysql -h https://www.sodocs.net/doc/c213466031.html, samp_db #直接恢复到另一个服务器上使用--add-drop-table选项告诉服务器将DROP TABLE IF EXISTS语句写入备份文件，这样当我们以后用来恢复数据库时，如果表已经存在，你
mysql主从
一、概述 MySQL从3.23.15版本以后提供数据库复制（replication）功能，利用该功能可以实现两个数据库同步、主从模式、互相备份模式的功能。本文档主要阐述了如何在linux系统中利用mysql的replication进行双机热备的配置。 二、环境 操作系统：Linux 2.6.23.1-42.fc8 # SMP（不安装XEN） Mysql版本：5.0.45-4.fc8 设备环境：PC（或者虚拟机）两台 三、配置 数据库同步复制功能的设置都在MySQL的配置文件中体现，MySQL的配置文件（一般是https://www.sodocs.net/doc/c213466031.html,f）：在本环境下为/etc/https://www.sodocs.net/doc/c213466031.html,f 。 3.1 设置环境： IP 的设置： A主机 IP：10.10.0.119 Mask：255.255.0.0 B主机 IP：10.10.8.112 Mask：255.255.0.0 在IP设置完成以后，需要确定两主机的防火墙确实已经关闭。可以使用命令service iptables status 查看防火墙状态。如果防火墙状态为仍在运行。使用service iptables stop 来停用防火墙。如果想启动关闭防火墙，可以使用setup 命令来禁用或定制。 最终以两台主机可以相互ping通为佳。 3.2 配置A主(master) B从(slave)模式 3.2.1 配置A 为master 1、增加一个用户同步使用的帐号： GRANT FILE ON *.* TO ‘backup’@'10.10.8.112' IDENTIFIED BY ‘1234’; GRANT REPLICATION SLAVE ON *.* TO ‘backup’@'10.10.8.112' IDENTIFIED BY ‘1234’; 赋予10.10.8.112也就是Slave 机器有File权限，只赋予Slave机器有File权限还不行，还要给它REPLICATION SLAVE的权限才可以。 2、增加一个数据库作为同步数据库： create database test; 3、创建一个表结构： create table mytest (username varchar(20),password varchar(20)); 4、修改配置文件： 修改A的/etc/https://www.sodocs.net/doc/c213466031.html,f 文件，在https://www.sodocs.net/doc/c213466031.html,f 配置项中加入下面配置：server-id = 1 #Server 标识 log-bin
数据库维护与故障恢复
数据库维护与故障恢复 为确保数据库安全，新思维医院信息管理系统采用了多种安全和应急预防机制，并提供相关的备份、紧缩和应急修复操作，以保障数据库系统的安全、高效和连续，即便在不可预测意外导致数据库损坏时，也可使用专用修复工具，从故障中安全快速且有效地恢复数据。 本文包括： ·Microsoft Access数据库被损坏的原因 ·有效防止数据库损坏的方法 ·定期或经常性地进行数据库备份和紧缩 ·从故障中恢复(修复被损坏的Access数据库) Microsoft Access数据库被损坏的原因 Microsoft Access数据库文件(.mdb)在某些突发或不可预料事件中可能导致损坏。已知mdb文件损坏的常见原因主要有四个： ●由于写入操作被中断使数据库处于置疑/损坏状态 ●网络硬件故障 ●在另一个程序中打开和保存mdb 文件 ●计算机病毒 原因之一：由于写入操作被中断使数据库处于置疑/损坏状态 强烈建议通过程序提供的“退出”或“关闭”来正常关闭数据库和结束程序运行。但是，如果非正常终止程序，即Access数据库不正常关闭时，数据库正处于打开状态并正在写数据，则数据库引擎就会将该文件标记为置疑/损坏。如果手动关闭计算机之前没有先关闭Windows 或者断电，也可能会出现这种情况。其它情形还包括：在打开数据库的同时，没有关闭相关程序，但仍干扰数据库引擎向磁盘写入数据。例如，当网络遇到数据冲突或者磁盘驱动器故障时，就会出现这种情况。如果发生任何此类中断，数据库引擎就会将数据库标记为可能已被破坏。 当数据库引擎(Jet)开始写操作时，将设置一个标记，并在操作完成时重新设置该标记。如果写操作被中断，标记保持不变。当您要再次打开数据库时，Jet确定标记是否已设置并报告数据库是否被破坏。在大多数情况下，数据库中的数据实际上没有被破坏，但设置的标记提醒Jet数据库可能已被破坏。如果是这种情况，压缩和/或修复数据库通常可以还原数据库。 原因之二：网络硬件故障
mysql数据库同步跳过临时错误
mysql数据库同步跳过临时错误 slave stop; set GLOBAL SQL_SLAVE_SKIP_COUNTER=1; slave start; 几个跟热备有关的mysql命令:(需要在mysql命令行界面或query ） stop slave #停止同步 start slave #开始同步，从日志终止的位置开始更新。 show slave status #查看同步状态 SET SQL_LOG_BIN=0|1 #主机端运行，需要super权限，用来开停日志，随意开停，会造成主机从机数据不一致，造成错误 SET GLOBAL SQL_SLAVE_SKIP_COUNTER=n # 客户端运行，用来跳过几个事件，只有当同步进程出现错误而停止的时候才可以执行。 RESET MASTER #主机端运行,清除所有的日志，这条命令就是原来的FLUSH MASTER RESET SLAVE #从机运行，清除日志同步位置标志，并重新生成https://www.sodocs.net/doc/c213466031.html, 虽然重新生成了https://www.sodocs.net/doc/c213466031.html,,但是并不起用，最好，将从机的mysql进程重启一下，LOAD TABLE tblname FROM MASTER #从机运行，从主机端重读指定的表的数据，每次只能读取一个，受timeout时间限制，需要调整timeout时间。执行这个命令需要同步账号有 reload 和super权限。以及对相应的库有select权限。如果表比较大，要增加net_read_timeout 和 net_write_timeout的值 LOAD DATA FROM MASTER #从机执行，从主机端重新读入所有的数据。执行这个命令需要同步账号有reload和super权限。以及对相应的库有select权限。如果表比较大，要增加net_read_timeout 和 net_write_timeout的值 CHANGE MASTER TO master_def_list #在线改变一些主机设置，多个用逗号间隔,比如CHANGE MASTER TO MASTER_HOST='https://www.sodocs.net/doc/c213466031.html,', MASTER_USER='replication', MASTER_PASSWORD='bigs3cret' MASTER_POS_WAIT() #从机运行 SHOW MASTER STATUS #主机运行，看日志导出信息 SHOW SLAVE HOSTS #主机运行，看连入的从机的情况。 SHOW SLAVE STATUS (slave) SHOW MASTER LOGS (master) SHOW BINLOG EVENTS [ IN 'logname' ] [ FROM pos ] [ LIMIT [offset,] rows ] PURGE [MASTER] LOGS TO 'logname' ; PURGE [MASTER] LOGS BEFORE 'date'
MySQL主从、主主复制及高可用性要点
一：MySQL复制： MySQL复制简介： 将master服务器中主数据库的ddl和dml操作通过二进制日志传到slaves服务器上，然后在master服务器上将这些日志文件重新执行，从而使得slave服务器和master服务器上的数据信息保持同步。 Mysql复制的原理： 将数据分布到多个系统上去，是通过将Mysql的某一台master主机的数据复制到其它（slave）主机上，并重新执行一遍来实现的； 复制过程中一个服务器充当master服务器，而一台或多台其它服务器充当slave服务器。master服务器将更新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。 这些日志可以记录发送到slave服务器的更新。当一个slaves服务器连接master服务器时，它通知master服务器从服务器在日志中读取的最后一次成功更新的位置。slave服务器接收从那时起发生的任何更新，然后封锁并等待master服务器通知新的更新。 mysql复制的优点： 在slave服务器上执行查询操作，降低master服务器的访问压力 当master服务器上出现了问题可以切换到slave服务器上，不会造成访问中断等问题 在slave服务器上进行备份，以避免备份期间影响master服务器的服务使用及日常访问
Mysql自身的复制功能：是构建大型、高性能应用程序的基础。 mysql支持的复制类型： 基于语句的复制：在主服务器上执行的SQL语句，在从服务器上执行同样的语句。MySQL默认采用基于语句的复制，效率比较高。一旦发现没法精确复制时，会自动选着基于行的复制。 基于行的复制：把改变的内容复制过去，而不是把命令在从服务器上执行一遍. 从mysql5.0开始支持 混合类型的复制:：默认采用基于语句的复制，一旦发现基于语句的无法精确的复制时，就会采用基于行的复制。 MySQL复制技术的特点： 数据分布(Data distribution ) 备份(Backups) 负载平衡(load balancing) 高可用性和容错性High availability and failover 复制的工作过程： master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events）； slave将master的binary log events拷贝到它的中继日志(relay log)； slave重做中继日志中的事件，将改变反映它自己的数据。
Mysql数据库安装及生产环境下主从库同步配置
Mysql数据库安装及生产环境下主从库同步配置
目录 1安装M YSQL数据库...................................................................................................................................... 2生产环境下M Y SQL数据库主从同步配置................................................................................................. 2.1 主数据库配置 (5) 2.2 从数据库配置 (5) 3监控服务器............................................................................................................................................... 3.1 监控主数据库服务器 (6) 3.2 监控从数据库服务器 (6)
1安装Mysql数据库 安装环境： 系统：CentOS-6.6-x86_64 数据库：MySQL-server-5.5.42-1.el6.x86_64；MySQL-client-5.5.42-1.el6.x86_64 1.SSH方式登录到MySQL服务器 2.创建存放安装文件的目录 [root@localhost /]# mkdir -p /sw/mysql55 3.上传安装文件到上一步创建的目录 4.检查是否已安装过MySQL [root@localhost /]# rpm -qa | grep -i mysql MySQL-client-5.5.42-1.el6.x86_64 MySQL-server-5.5.42-1.el6.x86_64 5.如果已安装则移除，否则请跳过此步 [root@localhost /]# yum -y remove MySQL-server-5.5.42-1.el6.x86_64 [root@localhost /]# yum -y remove MySQL-client-5.5.42-1.el6.x86_64 删除老版本mysql的开发头文件和库 rm -fr /usr/lib/mysql rm -fr /usr/include/mysql rm -fr /var/lib/mysql rm -f /etc/https://www.sodocs.net/doc/c213466031.html,f 6.安装MySQL [root@localhost /]# cd /sw/mysql55/ [root@localhost mysql55]# rpm -ivh MySQL-server-5.5.42-1.el6.x86_64.rpm Preparing... ########################################### [100%] 1:MySQL-client ########################################### [100%] [root@localhost mysql55]# rpm -ivh MySQL-client-5.5.42-1.el6.x86_64.rpm Preparing... ########################################### [100%] 1:MySQL-server ########################################### [100%] 7.配置MySQL [root@localhost mysql55]# cp /usr/share/mysql/https://www.sodocs.net/doc/c213466031.html,f /etc/https://www.sodocs.net/doc/c213466031.html,f [root@localhost mysql55]# vi /etc/https://www.sodocs.net/doc/c213466031.html,f [client] #password = your_password port = 8819 socket = /var/lib/mysql/mysql.sock default-character-set=utf8 [mysqld] port = 8819 socket = /var/lib/mysql/mysql.sock lower_case_table_names=1
mysql数据库主主同步方案
Mysql 数据库主主（master-master）同步方案 一、MySQL同步概述 1.MySQL数据的复制的基本介绍 目前MySQL数据库已经占去数据库市场上很大的份额，其一是由于MySQL数据的开源性和高性能，当然还有重要的一条就是免费~不过不知道还能免费多久，不容乐观的未来，但是我们还是要能熟练掌握MySQL数据的架构和安全备份等功能，毕竟现在它还算是开源界的老大吧！ MySQL数据库支持同步复制、单向、异步复制，在复制的过程中一个服务器充当主服务，而一个或多个服务器充当从服务器。主服务器将更新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新，然后封锁并等待主服务器通知新的更新。 请注意当你进行复制时，所有对复制中的表的更新必须在主服务器上进行。否则，你必须要小心，以避免用户对主服务器上的表进行的更新与对从服务器上的表所进行的更新之间的冲突。 单向复制有利于健壮性、速度和系统管理： 健壮性：主服务器/从服务器设置增加了健壮性。主服务器出现问题时，你可以切换到从服务器作为备份。
速度快：通过在主服务器和从服务器之间切分处理客户查询的负荷，可以得到更好的客户响应时间。SELECT查询可以发送到从服务器以降低主服务器的查询处理负荷。但修改数据的语句仍然应发送到主服务器，以便主服务器和从服务器保持同步。如果非更新查询为主，该负载均衡策略很有效，但一般是更新查询。 系统管理：使用复制的另一个好处是可以使用一个从服务器执行备份，而不会干扰主服务器。在备份过程中主服务器可以继续处理更新。 2.MySQL数据复制的原理 MySQL复制基于主服务器在二进制日志中跟踪所有对数据库的更改(更新、删除等等)。因此，要进行复制，必须在主服务器上启用二进制日志。 每个从服务器从主服务器接收主服务器已经记录到其二进制日志的保存的更新，以便从服务器可以对其数据拷贝执行相同的更新。 认识到二进制日志只是一个从启用二进制日志的固定时间点开始的记录非常重要。任何设置的从服务器需要主服务器上的在主服务器上启用二进制日志时的数据库拷贝。如果启动从服务器时，其数据库与主服务器上的启动二进制日志时的状态不相同，从服务器很可能失败。 将主服务器的数据拷贝到从服务器的一个途径是使用LOAD DATA FROM MASTER语句。请注意LOAD DATA FROM MASTER目前只在
mysql主从复制原理
主从复制的原理： 分为同步复制和异步复制，实际复制架构中大部分为异步复制。 复制的基本过程如下： 1)、Slave上面的IO进程连接上Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容； 2)、Master接收到来自Slave的IO进程的请求后，通过负责复制的IO进程根据请求信息读取制定日志指定位置之后的日志信息，返回给Slave 的IO进程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置； 3)、Slave的IO进程接收到信息后，将接收到的日志内容依次添加到Slave端的relay-log文件的最末端，并将读取到的Master端的bin-log的文件名和位置记录到master-info文件中，以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log的哪个位置开始往后的日志内容，请发给我”； 4)、Slave的Sql进程检测到relay-log中新增加了内容后，会马上解析relay-log的内容成为在Master端真实执行时候的那些可执行的内容，并在自身执行。 Mysql为了解决这个风险并提高复制的性能，将Slave端的复制改为两个进程来完成。提出这个改进方案的人是Y ahoo!的一位工程师“Jeremy Zawodny”。这样既解决了性能问题，又缩短了异步的延时时间，同时也减少了可能存在的数据丢失量。当然，即使是换成了现在这样两个线程处理以后，同样也还是存在slave 数据延时以及数据丢失的可能性的，毕竟这个复制是异步的。只要数据的更改不是在一个事物中，这些问题都是会存在的。如果要完全避免这些问题，就只能用mysql的cluster来解决了。不过mysql的cluster是内存数据库的解决方案，需要将所有数据都load到内存中，这样就对内存的要求就非常大了，对于一般的应用来说可实施性不是太大。 复制常用架构 Mysql复制环境90%以上都是一个Master带一个或者多个Slave的架构模式，主要用于读压力比较大的应用的数据库端廉价扩展解决方案。因为只要master和slave的压力不是太大（尤其是slave端压力）的话，异步复制的延时一般都很少很少。尤其是自slave端的复制方式改成两个进程处理之后，更是减小了slave端的延时。而带来的效益是，对于数据实时性要求不是特别的敏感度的应用，只需要通过廉价的pc server来扩展slave的数量，将读压力分散到多台slave的机器上面，即可解决数据库端的读压力瓶颈。这在很大程度上解决了目前很多中小型网站的数据库压力瓶颈问题，甚至有些大型网站也在使用类似方案解决数据库瓶颈。 Mysql主从复制配置过程： 环境：master: 192.168.0.3 Slave: 192.168.0.4 Mysql版本为5.0.67（编译安装） database: eric 1.Master服务器启动mysql， a)#mysql –uroot –proot b)创建一个有复制权限的用户，只限slave远程连接访问. i. mysql>grant replication slave on *.* to replication@192.168.0.4
数据库出现故障恢复方法
文件库出现故障恢复方法 文件库一般是电脑用户存储很多文件的地方，也是用户最怕出现问题的地方，因为一旦文件丢失，带来的麻烦一般都不小。小编查询资料后为大家总结了几种文件库故障的表现及故障原因，并为大家推荐一种评价最高的文件库恢复方法。 文件库出现故障一般是： 一，附加文件库文件MDF及日志文件LDF时，报“823”错误。 二，通过之前备份的文件库进行文件库还原时，出现“内部一致性错误”。这通常也是文件库管理人员最大的梦魇了，明明是做了备份，却在还原时发现备份文件是损坏的。这意味着文件库的丢失，后果是非常严重的。 出现故障的原因是: 一、sql823报错的故障出现原因： (1)在文件库读写过程中突然死机或者断电。 (2)服务器重启，重启后文件库出现“置疑”状态。 (3)磁盘I/O错误 在以上可能的三种突发故障下，由于缓冲文件丢失，文件库无法写入正确的文件，导致文件结构紊乱，重启后文件库无法正常附加。 二、sql报错的故障出现原因： (1)备份文件和文件库放在同一个物理硬盘上，硬盘出故障，备份也损坏。 (2)备份介质损坏;或者做的是网络备份，文件在网络传输中发生了损坏。 (3)文件库在做完整备份、文件备份或者文件组备份的时候，里面的内容就已经有了损坏。这是因为SQL Server在做文件备份的时候为了节省时间，基本只是很简单地把文件页面拷贝下来，不会做一致性检查的。但是在恢复的时候，需要将文件库恢复(Recover)到事务一致的一个时间点。如果备份中的损坏妨碍了SQL Server的前滚后滚(Redo和Undo)，恢复动作就会遇到错误。 (4)在备份文件库时由于磁盘中有坏道，备份出来的MDF文件不完整时也会出现这种错误。
MYSQL主从数据库介绍__主库__从库
如上图所示，整个数据层有Group1，Group2，Group3三个集群组成，这三个集群就是数据水平切分的结果，当然这三个集群也就组成了一个包含完整数据的DB。每一个Group包括1个Master（当然Master也可以是多个）和N个Slave，这些Master和Slave的数据是一致的。比如Group1中的一个slave发生了宕机现象，那么还有两个slave是可以用的，这样的模型总是不会造成某部分数据不能访问的问题，除非整个Group里的机器全部宕掉，但是考虑到这样的事情发生的概率非常小（除非是断电了，否则不易发生吧）。 在没有引入集群以前，我们的一次查询的过程大致如下：请求数据层，并传递必要的分库区分字段（通常情况下是user_id）?数据层根据区分字段Route到具体的DB?在这个确定的DB内进行数据操作。这是没有引入集群的情况，当时引入集群会是什么样子的呢？看图一即可得知，我们的路由器上规则和策略其实只能路由到具体的Group，也就是只能路由到一个虚拟的Group，这个Group并不是某个特定的物理服务器。接下来需要做的工作就是找到具体的物理的DB服务器，以进行具体的数据操作。基于这个环节的需求，我们引入了负载均衡器的概念（LB）。负载均衡器的职责就是定位到一台具体的DB服务器。具体的规则如下：负载均衡器会分析当前sql的读写特性，如果是写操作或者是要求实时性很强的操作的话，直接将查询负载分到Master，如果是读操作则通过负载均衡策略分配一个Slave。我们的负载均衡器的主要研究放向也就是负载分发策略，通常情况下负载均衡包括随机负载均衡和加权负载均衡。随机负载均衡很好理解，就是从N个Slave中随机选取一个Slave。这样的随机负载均衡是不考虑机器性能的，它默认为每台机器的性能是一样的。假如真实的情况是这样的，这样做也是无可厚非的。假如实际情况并非如此呢？每个Slave的机器物理性能和配置不一样的情况，再使用随机的不考虑性能的负载均衡，是非常不科学的，这样一来会给机器性能差的机器带来不必要的高负载，甚至带来宕机的危险，同时高性能的数据库服务器也不能充分发挥其物理性能。基于此考虑从，我们引入了加权负载均衡，也就是在我们的系统内部通过一定的接口，可以给每台DB服务器分配一个权值，然后再运行时LB根据权值在集群中的比重，分配一定比例的负载给该DB服务器。当然这样的概念的引入，无疑增大了系统的复杂性和可维护性。有得必有失，我们也没有办法逃过的。 有了分库，有了集群，有了负载均衡器，是不是就万事大吉了呢？事情远没有我们想象的那么简单。虽然有了这些东西，基本上能保证我们的数据层可以承受很大的压力，但是这样的设计并不能完全规避数据库宕机的危害。假如Group1中的slave2 宕机了，那么系统的LB并不能得知，这样的话其实是很危险的，因为LB不知道，它还会以为slave2为可用状态，所以还是会给slave2分配负载。这样一来，问题就出来了，客户端很自然的就会发生数据操作失败的错误或者异常。这样是非常不友好的！怎样解决这样的问
使用keepalived实现对mysql主从复制的主备自动切换
keepalived实现对mysql主从复制的主备自动切换使用MySQL+keepalived是一种非常好的解决方案，在MySQL-HA环境中，MySQL 互为主从关系，这样就保证了两台MySQL数据的一致性，然后用keepalived实现虚拟IP，通过keepalived自带的服务监控功能来实现MySQL故障时自动切换。 实验环境中用两台主机搭建了一个mysql主从复制的环境，两台机器分别安装了keepalived，用一个虚IP实现mysql服务器的主备自动切换功能. 模拟环境： VIP：192.168.1.197 ：虚拟IP地址 Master：192.168.1.198 ：主数据库IP地址 Slave：192.168.1.199 ：从数据库IP地址 备注：MySQL的主从同步配置不在此文档中说明（前提：主从同步已完成） 安装步骤： 1、keepalived的安装 Yum install -y keepalived Chkconfig keepalived on 2、keepalived.conf文件的配置 Master：keepalived.conf vi /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs { notification_email { kenjin@https://www.sodocs.net/doc/c213466031.html, } notification_email_from kenjin@https://www.sodocs.net/doc/c213466031.html, smtp_connect_timeout 3 smtp_server https://www.sodocs.net/doc/c213466031.html,
数据库的修复方法
恢复数据库的几种方法 广汉市雒城四小―――王春燕 内容提要：随着现代科学技术的飞跃发展，数据库系统已广泛运用各个系统中，尽管数据库系统中采取了各种保护措施来防止数据库的安全和完整性被破坏，保证并行事物的正确执行，但是计算机系统中硬件的故障，软件的错误，操作员的失误以及恶意的破坏仍是不不可避免的，这些故障轻则造成事务非常中断，影响数据库中数据的正确性，重则破坏数据库，使数据库中全部或部分数据丢失，因此数据库管理系统必须具有把数据库从错误状态中恢复到某一已知的正确状态的功能，这就需要数据库的恢复。 故障的种类 一、事务内部的故障 事物内部的故障有的是可以通过事物程序本身发现的，有的是不是预期的，不能由事物程序处理的。 例如：学生调校、系或调班事务，这个事务把一个学生从一个校、系（班）转另一个系（班）。 BEGIN TRANSACTION 读甲系（班）的余额BALANCE； BALANCE=BALANCE-AMOUNT；（AMOUNT为转校系（班）学生） IF （BLANCE小于0），THEN
{打印'人数不足，不能转班'; ROLLBACK;(撤销该事务) ELS 写回BALANCE1=BALANCE1+AMOUNT; COMMIT;} 这个例子所包括的两个更新操作要么全部不做,否则就会使数据库存处于不一致状态. 在这段程中，应用程序可以发现并让事物滚回,撤销已做的修改,恢复数据到正确状态。这类恢复员事物撤销（UNDO）。这是预期的故障。事物内部的故障很多是无预期的，是不能由应用程序处理的。 （二）、系统故障 系统故障是指系统停止运转的任何事件，使得系统要重新启动。例如，特定类型的硬件错误（CPU）故障，操作系统故障、DBMS代码错误、突然停电等，这类故障影响正在运行的所有事务，但不破坏数据库。这时所有的运行事务都非正常终止。发生系统故障时，一些尚未完成的事务结果可能已送入物理数据库，从而造成数据可能处于不正确状态。为保证一致性，需要清除这些事务对数据库的所有修改. 恢复系统必须在系统重新启动时让所有非正常终止的事务回滚，强行撤销所有未完成事务。 另一方面，系统重启后，恢复子系统除撤销所未完成事务外，还需要重做所有已提交事务，以将数据恢复到一致状态。 （三）、介质故障