为了防止数据库崩溃使数据丢失的解决方案

基础知识

数据库日志的分类

1.二进制日志

2.错误日志

3.一般查询日志

4.中继日志

5.慢查询日志

二进制日志的格式:

statement:基于语句

row:基于行

mixed:混合方式

mysql的隔离级别:

readuncommitted:读未提交

readcommitted:读提交

repeatableread:可重读

serializable:可串行

二进制日志,默认放在数据库,名称为mysql-bin.xxxxx,当日志文件达到上限时,会不停的滚动,可以使用如下命令:

刷新日志

mysql>flush logs;

查看当前正在使用的二进制日志

mysql>show master status;

查看二进制日志的内容

mysql>show binarylogs;

二进制日志的用途:

二进制日志可以用来做即时点还原,因为里面记录了此前可以改变数据库的各种操作,这样,若数据库损坏,可以用二进制日志文件重新执行一遍

mysql的复制

A服务器把可能改变数据改变的操作,保存于二进制日志文件,A服务器把二进制日志文件的内容的事件随时通过本地服务器发送到B服务器,B服务器把事件保存至中继日志,通过读取中继日志的事件在B服务器执行操作,结果保存于数据库,同时会产生二进制日志,mysql的复制,这个流程就是mysql的复制,其中的A服务器就是主服务器,B服务器就称之为从服务器

主从服务器数据的传输方式

异步传输。因为从服务器的数据是从主服务器复制得到,所以从服务器的数据会比主服务器得到数据的速度要慢,从种种角度来讲从服务器比主服务器慢,所以主从服务器传输数据的方式是异步传输

传输方式:

异步传输:只要主服务器本地执行成功,就宣告执行成功,不管从服务器是否收到数据

半同步传输:对于主服务器来讲,只要最近一台的节点传输成功,就宣告成功

规定主从服务器的读写操作

从服务器是不允许写操作的,因为若从服务器写入数据,而又不能同步到主服务器,会导致主从服务器数据的不一致,会造成数据库崩溃,所以对于非主服务器的服务器都不允许写操作,就导致了主服务器允许读写操作,而从服务器只能允许读操作

从服务器有必要有二进制日志文件吗?

答案是:有,虽说从服务器无非就是同步主服务器的数据而已,多了二进制日志文件反而会降低存储速度,但是这个从服务器可以是别的从服务器的主服务器,可称为多级日志,中继日志是不能拿来发给别人的,所以就有了二进制日志存在的必要啦......那么为什么要用多级复制呢?如果主服务器忽然宕机,可以让这个从服务器做些简单修复,成为主服务器,这同时也就达到了服务器的高可用

复制数据的特点:(1)辅助实现备份。(2)高可用。(3)异地容灾

读写分离:

若规定各个服务器的操作,会出现负载不均衡现象,所以就在mysql服务器的前端出现了代理服务器,若是读操作,就发送至从服务器,若是写操作,就发送至主服务器。由于读操作较多与写操作。所以在众多可读的从服务器前端增加调度器,同时对主服务器、调度服务器、代理服务器做高可用.

mysql缓存服务器的好处:

若每次操作都到服务器上执行时,会发现速度很慢,所以建立共享式缓存(memcache),若下次访问memcache,若有所要查询的结果,就把结果返回至客户端,减少传输时间.

主从架构中,不使用mysql代理服务器,怎么实现数据同步?

使用双主模型,两个服务器都可以读写操作,A服务器的写操作的结果存储到二进制日志文件,将二进制日志文件发送至B服务器,存放于B服务器的中继日志,进行各种操作,保存二进制日志。B服务器执行各种操作,保存于二进制日志,传送至A服务器,保存于中继日志,执行各种操作,保存于二进制日志,但这样就称为了死循环,所以给各个服务器赋予server id,根据不同的server id来识别哪些内容是本地日志,同时对本地日志不进行操作,只操作非本地的日志,就完成了数据的同步

时间: 2024-09-09 06:32:17

为了防止数据库崩溃使数据丢失的解决方案的相关文章

android 数据库崩溃问题

问题描述 android 数据库崩溃问题 E/AndroidRuntime( 3752): android.database.sqlite.SQLiteException: unable to open database file (code 14) E/AndroidRuntime( 3752): at android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:181) E/AndroidRuntime(

一些 NSFetchedResultsController 使用报错解决方案

本文讲的是一些 NSFetchedResultsController 使用报错解决方案, NSFetchedResultsController 困境 NSFetchedResultsController 是关于 iOS 的 Core Data 开发的一个主要部分.自 iOS 3系统开始引入这个类之后,这个类就负责高效的管理 Core Data 实体的集合. 在过去的六年里,我使用这个控制器,并为它设置了各种类型的 Core Data 栈配置来管理我所有的项目.最近,在为 Black Pixel

当SQL Server数据库崩溃时如何恢复

server|恢复|数据|数据库 任何数据库系统都无法避免崩溃的状况,即使你使用了Clustered,双机热备--仍然无法完全根除系统中的单点故障,何况对于大部分用户来说,无法承受这样昂贵的硬件投资.所以,在系统崩溃的时候,如何恢复原有的宝贵数据就成为一个极其重要的问题了.在恢复的时候,最理想的情况就是你的数据文件和日志文件都完好无损了,这样只需要sp_attach_db,把数据文件附加到新的数据库上即可,或者在停机的时候把所有数据文件(一定要有master等)都copy到原有路径下也行,不过一

SQL Server数据库崩溃如何恢复

server|恢复|数据|数据库 任何数据库系统都无法避免崩溃的状况,即使你使用了Clustered,双机热备--仍然无法完全根除系统中的单点故障,何况对于大部分用户来说,无法承受这样昂贵的硬件投资. 所以,在系统崩溃的时候,如何恢复原有的宝贵数据就成为一个极其重要的问题了. 在恢复的时候,最理想的情况就是你的数据文件和日志文件都完好无损了,这样只需要sp_attach_db,把数据文件附加到新的数据库上即可,或者在停机的时候把所有数据文件(一定要有master等)都copy到原有路径下也行,不

当SQL Server数据库崩溃时如何恢复?

server|恢复|数据|数据库 工作告一段落,今天下午有空,写篇文章,也许会对大家有帮助:) 任何数据库系统都无法避免崩溃的状况,即使你使用了Clustered,双机热备--仍然无法完全根除系统中的单点故障,何况对于大部分用户来说,无法承受这样昂贵的硬件投资.所以,在系统崩溃的时候,如何恢复原有的宝贵数据就成为一个极其重要的问题了. 在恢复的时候,最理想的情况就是你的数据文件和日志文件都完好无损了,这样只需要sp_attach_db,把数据文件附加到新的数据库上即可,或者在停机的时候把所有数据

SQL Server数据库崩溃的方法

  任何数据库系统都无法避免崩溃的状况,即使你使用了Clustered,双机热备等等,仍然无法完全根除系统中的单点故障,何况对于大部分用户来说,无法承受这样昂贵的硬件投资.所以,在系统崩溃的时候,我们应该如何恢复原有的宝贵数据就成为一个极其重要的问题了. 在恢复的时候,最理想的情况就是你的数据文件和日志文件都完好无损了,这样只需要sp_attach_db,把数据文件附加到新的数据库上即可,或者在停机的时候把所有数据文件(一定要有master等)都copy到原有路径下也行,不过一般不推荐这样的做法

Domino数据库、邮件归档完美解决方案

问题描述 Domino数据库.邮件归档完美解决方案www.soyxer.com产品功能智能文档搜索引擎,支持多查询条件并发搜索,快速定位所需信息资源,可针对多数据库进行联合搜索.搜索模板,完美解决OA系统信息搜索难题,兼容所有NSF格式的数据库.与Domino/Notes平台一致的人员阅读权限,防止保密信息泄露,保证信息安全.可提升提高Domino/Notes平台性能70%,节约50%以上维护成本.海量数据压缩存储,节省原有40%存储费用.指定数据库归档.历史数据恢复,可指定恢复任意时间的数据到

PgSQL · 特性分析 · 数据库崩溃恢复(上)

背景 为了合并I/O提高性能,PostgreSQL数据库引入了共享缓冲区,当数据库非正常关闭,比如服务器断电时,共享缓冲区即内存中的数据就会丢失,这个时候数据库操作系统重启时就需要从非正常状态中恢复过来,继续提供服务.本文将具体分析在这种情况下,PostgreSQL数据库如何从崩溃状态中恢复. 上期月报PgSQL · 特性分析 · checkpoint机制浅析中介绍了PostgreSQL中的checkpoint机制.其中提到,当PostgreSQL数据库崩溃恢复时,会以最近的checkpoint

求指点:这种分布式数据库应用,哪种解决方案比较好

问题描述 求指点:这种分布式数据库应用,哪种解决方案比较好 有一个全局数据库(A)和多个局部数据库(B1....Bn). A有自已的局部数据,同时要有B1...Bn所产生的所有局部数据,B1...Bn都只有各自局部产生的数据. A和B1....Bn都会产生一定量的全局性数据,全局性数据集合要向全网适时发布共享,主要提供查询功能. 只在持久层解决,数据同步过程对业务层透明,最好的解决方案是什么呢? 初步考虑在A建立B1...Bn的slave库,B1...Bn向各自的slave库进行复制,在A和B1