00:00
各位同学大家好。接下来给大家介绍一下RDB的优缺点以及后续的相关知识。好,通过前面的讲解,我们已经明白了RDB的自动触发、手动触发如何进行我们数据的保存,那既然RDB这么好的话,它有哪些缺点和随之而来的一些不完美的地方呢?如果RDB一切都是OK的,那么不会出现第二种持久化方式。所以按照官网的理论要求,我们给大家介绍一下RDB的优点和RDB的缺点来。第一个我们呢,严格按照官网理论知识走下来,首先RDB呢,它非常好的一个地方的,是非常紧凑的单文件时间点表示,那么非常适合什么。整体的备份,比如说设置24小时以内或者30天内每天保存一个RDB的快照,这样就可以在发生灾难的时候轻松的恢复不同版本的数据集。前面说过。
01:02
废物自动触发对吧,多少时间以内修改频,修改频次是多少,然后进行相关的保存,第二个灾难恢复。说实话,我们刚才说过,请不要把RDB文件和主机运行环境放在同一台机器上,它可以传输到远程数据中心或者是我们的亚马逊这些云服务器上面。那么第三一点,RDB最大限度的提高的red性能。因为负进程为了持久化而需要做的唯一工作就是派生一个将完成所有其余工作的一个子进程,那么负进程永远不会执行磁盘L类的相关操作,我们是不是说过它默认是用BGC,那么与A相比,它呢?允许大数据机更快的重启在副本上,RDB支持重启故障转移后的部分重新同步。好,那么这是我们前面所说过的它相关的优点。那下面我们来看一下小总结。
02:00
一句话,RDB有什么好处?适合大规模的数据恢复,按照业务定时备份,对数据完整性和一致性要求不是特别高诶。这什么意思?你不说他呢,一锅端吗?杨哥,你不是说了?别着急,待会我们聊劣势来,RDB文件在内存中的加载速度要比AF快很多,好,那么这个是我们RDB的优点来了,那么缺点呢?一样的啊,官网说明主要是两块,第一个如果你需要在red停止工作的时候,比如说断电啊,将数据丢失的可能性降低到最低,那么RDB并不好,那么大家请看啊,这个呢。不是我们所说的r DB is not good OK,所以呢,什么概念,也就是说啊。RDB,它有时候是。在没有正确关闭的情况下停止工作了啊,你要。有一种心理准备,丢失最新分钟的数据,也就是说RDB,如果啊,按照我们的频次假设随便设啊。
03:08
一分钟有十次修改。或者十分钟以内有50次以上的修改,随便。刚刚好啊。这个时间段以内。他呢,只进行了30次的修改,突然淡期了,刚好他也要写进来一些东西,那对不起,还没有达到保存的条件,超过了这个时间段,那他是是不是就会丢失最近一次的修改啊。这是第一个,它呢会有这个率缺点。第二个RDB经常需要fork,以便使用紫禁程在磁盘上持久化。如果数据集很大,Folk可能会很耗时,因为我们前面说过,这个主进程不停,Fork是起了一个一模一样的副本,能够去写一个临时文件,那么如果这个情况下这个复合出来的东东很大,那它是不是要占据一部分的空间和内存?
04:01
这样的话会导致。停止为客户端服务几毫秒甚至是一秒钟,那么这个时候如果获荷很频繁很大,也会加倍的占用我们的内存,OK,所以呢,我们可以总结一下,第一个,在一定的间隔时间作一次备份的话,如果抓服务器意外的死机了,宕机了,那么就会丢失从当前至最近一次快照期间的数据,就是还没来得及保存进去的,那么快照之间的这个数据链就会断掉,一部分数据会丢失。第二个,内存数据的全量同步,如果数据量太大,会导致IO严重影响服务器性能,因为。各位亲,如果你一次备份啊,比如说你干的比较狠,我们一天。24小时,那么超过1万次以上的修改。拷贝进去一个那一天以内可能数据量太大,他写的过程当中,他是不是要传说,那么这段时间就像是什么把风控一样,它呢不停的要写入数据。
05:04
这个时候就会导致IO,严重影响服务器性能。第三,一个RDB依赖于主进程的fok,如果数据也特别大,那么这个时候会导致。请求瞬间就延时了。F的时候,内存中的数据被克隆了一份大致翻倍的膨胀,那么这个时候回答我是不是也会挤占IO和内存呢?所以RDB它是有这样的缺点的。OK,那么接下来我们来演示一下快照数据丢失这个缺点。首先我们呢,先正常的录入数据啊,咱们呢先说理论再说实操,第一个我们呢什么都没有,然后呢,K1。为呃,K1K2没问题,只要五秒以内有两次,马上会产生一个dump r DB文件。接下来第四步,我们只有K3了。好,现在K3完成以后,我准备写入K4啊,明白吗?但是并没有写。
06:06
这个时候请看内存里面是有K3的。听懂了吧,然后呢,这个时候我正。要干的事儿是K3写完。因为还没有满足两次,K4还没有写进去,在没有没满足两次的情况下,它不会自动。诞生弹文件,这个时候我们在这个缝隙,K3和K4之间。突然我的red服务器宕机了,那这个时候请看同学们。第四步完了以后,第五步什么概念?就是只有K3呢,还没写K4呢,107107说明dump文件根本没有保存进磁盘。听懂了吗?这个时候我的服务器死了,然后我重新连上去。大家看。刚才查的时候内存里面是有K3的,但是我恢复的时候只有。
07:00
K1K2K30个,那这就导致我们数据丢失了,最近的一次修改,也就是我们所说的快照丢失,OK好,那么同学们,我们呢,简单的给大家呢,进行一下这个案例的演示。首先啊,那么kiss星那干脆啊,我们呢,直接呢,Flash先给它清空,同学们请看一下什么都没了吧,好的,那么搁到这,我们的RM-F大强制删除,空空如也,好同学们第一个SK1V1SK2V2,五秒钟两次修改。产生了吧,现在的值是107,好,我们按照我们的数据的正常录入没问题,现在同学们set k3V3。OK,那么现在我们K星同学们请看,现在在内存里面是有K3的,能查出来,但是呢,我们呢,再来看,由于不满足两次,现在K3根本没有写进我们的RDB文件里面。
08:12
换句话说,它不在我们的磁盘上,OK好了,那么现在啊,我们杠EF竖现gra right,那么我们的服务的进程是多少?17717881,那么Q-917881。模拟我们现在red服务器宕机了,好,那么同学们现在假设啊,我呢,Kiss心,哎呀,他直接告诉你报错了,我是不是把它杀掉了?好那么现在刚才我们是有内存里面是有K3的,但是我们并没有写K4啊,也就是五秒以内的两次操作,我只进行了一次,根本就没有存进我们的什么dampmp文件里面,你看还是107听懂了吧,所以呢,此时register serve my register7启动register client连上来,那么这个时候同学们老爷,Get k1,有没有get k2,有没有get k3,那听懂了吧?所以说在这个时间间隔以内,本来K3是在内存里面的,正常情况下你是应该写进RDB文件的,但是由于不满足我们的。
09:31
修改频率次数的要求根本没有写进去,所以刚才就会出现一个非常严重的问题,怎么着,我们write重启恢复以后,查看数据是否丢失就会发现。上一轮K3是在内存里面的,但是这一轮K3丢掉了RDB缺点,获得了证明,OK,好,那么同学们,这个就是我们RDB这样的一种配置方式的。优点和缺点就给大家介绍到这儿。
我来说两句