00:00
好,那么关于这一章呢,咱们最后呢,再给大家讲一个呢,叫做中继日志啊relay log,这个中继日志的话呢,咱们在前面讲到这个日志概述的时候呢,其实也谈到过它的一个作用,哎,就是在咱们这个主从架构当中呢去使用的啊,那为了说清楚这个事儿的话呢,咱们在这空讲的话呢,反而大家觉得很抽象啊,不妨呢,咱们就先看一看咱下一章呢,诶要讲的这里边儿的一个图。好,那我们比如说就看这个图吧。这呢是我们的这个主服务器master,这呢是我们这个从服务器啊,这就是主从的一个架构,最简单的一主一从模式,那我们这个主服务器当中啊,现应在这个表是吧?然后呢,我们有相关的一些事物,那针对于这些表的,呃,这个更改行为,我们是不是都记录到这个b log这个文件里了,对吧?都记录到这里了,然后呢,我们这个从服务器呢,一开始的这个表数据呢,跟你一样,然后你主服务器呢,诶写入数据呢,做了这个增删改了,那我们这个从服务器呢,是不是要保证跟它的一致性啊,怎么办呀?从服务器呢,通过网络的方式呢,去读取我们主服务器上的b log,呃,这个日志文件,然后把数据读过来之后呢,它是不是要存储在他自己的这个磁盘上啊。
01:02
诶,它会保存在它自己磁盘上的一个本地文件里边,那么这个本地文件呢,就称为呢叫类log啊,也就是我们说的叫中继日志,然后的话呢,我们再去读取啊这个终极日志,然后呢,把这个里边呢,你看你到底有哪些增删改啊,或者DDL的行为呢,是不是在我们现在表上去体现一下,这样的话呢,是不是就实现了我们主机上的表跟我们从机上这个表是不是数据库的这个一致性啊。哎,那么这里边儿呢,终极人志它所处的位置和它的作用,哎,我们这儿呢,就诶说清楚了,好,那么这个说清楚以后呢,回过来大家再看这些话的话呢,就非常的清晰啊,比如说中级人士呢,它只在主从服务器架构当中,这个从服务器上呢,是存在的,没问题是吧?然后呢,这个呃,中间这个过程呢,就是我刚才解释的这个过程,它的价值的话呢,就是为了完成我们主从服务器的啊,实现一个数据的同步,达到呢主从务器数据的一个一致性。是吧,哎,这样一说呢,大家都能明白啊啊下边呢,就提到了说这个中介日志它存放的一个位置,默认的话呢,是在这个从服务器的这个数据目录下啊,数据目录下这个咱们现在谈到这个日志呢,基本上啊,咱们看的都是诶放在这个数据目录下,这样是一种默认的一个格式啊,但是咱们前面提到这个二级日志的时候呢,也提到了,建议大家呢,是不是不要把它放在这个数据目录下。
02:14
是吧,因为你这个数据库表如果挂了的话呢,呃,放在同个目录下,有可能你这个文件也都损坏了啊,相当于这个恢复的话呢,也没东西了是吧。呃,这个错误日的话呢,咱们讲的时候呢,它应该默认的话呢,不在我们这个数据目录下,你看是吧,它默认是在这个路径下啊,这个稍微注意一下。好,这个我们再再拉回来啊,然后呢,这个呃,中继日志啊,下边这块呢,跟我们的二级日志呢有点像,它在这个从服务器上的话呢,它也会出现这个呃序号啊,00001啊0002啊这样一个方式,然后呢,也会给我们啊提供一个具体的叫index这样的一个文件啊,相当于是我们这些啊,这个终极日志的一个索引文件了啊这样的一个情况。好,然后的话呢,这个中继日志的话呢,它的格式呢,跟我们二级日志呢,也是一样的,那就意味着呢,我们要想查看的话呢,也得需要借助于相关的工具是吧?我们在这讲的话呢,有两种工具,其中一个呢叫myql blog,哎,我们可以通过它呢进行查看啊是吧?查看哎,你看到这个呢,是不是比较熟悉,我们讲这个二进制日志的时候呢,是不是也出现过这个信息是吧。
03:13
哎,像这里边呢,记录了一些点啊,你比如说我们呢,是哪个数据库的什么表啊,呃,哪一行的数据啊,我们这块呢,是要干什么事儿啊,你看他要删除一个行为是吧?诶基本上也能看到其中的一些场景啊就可以了。行,这个呢就过了啊,咱们下一章的时候呢,到时候再谈这个主动架构的时候呢,呃,再去提一下这个二级日志和这个中级日志的一个搭配使用。好,那么这块呢,有一个点需要大家注意的,就是典型的我们在这个进行数据的一个来恢复的时候啊,就是我们这块呢,从服务器呢,假设宕机了,我们呢,要重启以后呢,是不是需要从这里边恢复数据是吧,那假设这个宕机行为呢,比较严重,我们呢,重装了一下这个系统。啊,重装一下系统之后呢,我们借助于这个终极日呢,做这个数据的一个恢复,那这里边儿呢,有可能会出现一个问题,就是大家呢,你发现这个数据呢,恢复以后呢,并没有达到一致性啊或者呢,读取这个文件呢,就出现了很多的异常信息,那我们首先想到的就是这个文件呢,可能损毁了。
04:07
对吧,这是一种场景啊啊,那其实的话呢,有可能不是文件损毁了,而是什么呢?我们新装的这样的一个系统啊,跟我们原来的这个服务器呢,它这个名啊不一样了。啊,有可能是默认的一个名是吧,名不一样了啊,名不一样的话呢,这时候导致你再去写入的时候,我们说呢,在这个终极日志里边,它记录了这个从服务器的名,那你现在这个名跟原来名不一样,诶所以它写入的话呢,就会有问题。啊,那么修改呢,也非常简单啊,就是呃,你把这个现在这个服务器的名呢,你改成原来的这个名就可以了啊,但是这个事儿的话呢,大家可能经常忽略啊,这是一个小细节啊,这个要注意一下。好,那么这样的话呢,咱们这一章啊,关于整体的这个日志呢,咱们就告一段落。好,同学们,咱们接着来看这个第18章叫做主从复制,咱们在讲这个第17章blog日志的时候呢,其实隐晦的也好,直接的也好,实际上呢,我们就已经提到了这个主从复制啊,因为呢,在我们这个主从复制当中,咱们要用到这个blog日志啊,包括呢我们说的中继日志,好那么这块呢,咱们就正式的来讲解一下这个主从复制这一章啊,主存复制啊,主机从机啊,涉及到我们就多台MYSQL数据库服务器了啊,你也可以理解成就MYSQL的集群的一个配置。
05:16
好,那么首先的话呢,我们来说明一个问题啊,说呢如何呢,去提升数据库的一个并发能力。啊,那这儿呢,我们就看到一个真实的企业中的一个场景说呢,用户的这个请求过来之后呢,我们呢,可以考虑呢优先啊把这个请求呢,分配在这个内存中,我们去做一个判断,是不是呢,这个数据已经缓存在我们的rise里边了,那如果是的话呢,直接呢,把这个诶用户呢请求的数据呢,就反回给用户就可以了,那如果不是的话呢,或者我们这个re中没有,咱们呢,相当于再去查询这个数据库,对吧?诶那查询完数据库以后呢,一方面呢,我们把这个数据呢,返回给客户,另外一方面的话呢,我把这个数据呢,是不是在保存在我们的当中,便于呢,你下次再请求的时候呢,是不是就直接呢从内存中去读了,对吧?好,那么这样的一个涉及的好处是什么呢?诶,我们说好处的话呢,至少应该有两个点,第一个点的话呢,你想想我们数据的话呢,用户请求过来了,这个数据呢,直接从内存中就找到了,而没有呢,去查数据库啊,那内存呢,它的访问速度是不是也要远快于我们这个持久化层的这个,呃,磁盘的是吧?那显然的话呢,给用户的体验呢,就是查询的速度比较快啊,这是其中的第一个点,那么第二点的话呢,就是呃,原本要没有缓存数据库的话呢,我们所有的这个请求都要呢,去并发的访问我们的MYSQL服务器了,那现在的话呢,相当于一部分呢,是不是请求就分给我们red了,哎,然后呢,到我们这个MYSQL这块呢,就少一些了啊,那么这样的话呢,相当于是缓解了我们MYSQ的一个访问压力。
06:40
啊,所以说呢,从这个角度上来讲的话呢,说red这个缓存架构呢,是我们麦高并发架构中的一个重要的一个环节啊,帮我们挡枪了是吧,诶这样的情况啊。好,那么从这个实际应用上来讲的话呢,我们说针对于数据库的操作呢,通常都是叫读多写少的啊,就是增删改比较少,查询是比较多的啊,其实大家你也想想,咱们作为一个普通的用户啊,你每天呢,打开这个应用,其实你会发现呢,你绝大部分的场景呢,都是在做查询是吧?增删改的机会呢,相对来说要少一些,那么面对这种场景的话呢,我们就可以考虑有一个思路呢,就是首先呢,为了解决我们服务器的啊,数据库服务器的压力,我们可以使用叫MYSQL集群啊,就是多台服务器了,那多台服务器的话呢,我们怎么去分配这些读写行为呢?诶,那我们呢,是不是就分配比较多的这种服务器呢,都作为这种读的服务器出现是吧,那这时候呢,读和写呢,要保证数据的一致性啊,这也是我们非常重要的要解决的一个问题啊,要解决一个问题。
07:37
好,那这呢,其实我们读和写呢,用不同的这个主机呢去实现啊,其实对应的就是读写分离的这样一个场景,哎,通过这样的这个操作呢,我们去提升咱们数据库的一个并发处理能力。哎,并发处理能力啊行,那提到这块的话呢,其实大家啊,应该能够跟我们前面这个章节呢,能够联系起来,就是咱们在这个第12章呢,是整个第二个小的篇章,谈到索引和数据库调入的时候呢,诶,我们这儿呢,相当于做了一个系统的总结啊在这个总结当中,我们就提到了整个调优的一个维度和步骤,是吧?啊,那其中的话呢,我们最后一个维度。
08:11
啊,包括这块我们也提到这个red了是吧,最后一个维度的话呢,就提到这个库这个优化,诶我们可以叫诶主从复制啊,在这个基础上呢,实现读写分离啊,然后呢,这块诶可以有一主一从的模式啊,当然你这个集群比较多的话呢,双主双从啊,当然这个呢,其实就互为背肌了啊,然后这呢,就是这个从击。然后呢,具体的话呢,还可以实现呢,叫分库分表,然后把这个数据呢,我们分配在不同的这个,诶比如说这个服务器上是吧,诶这个呢,就是很多这个细节问题了啊OK,行,那我们这块呢还拉回来,所以这里边儿呢,相当于我们这个进行这个嗯,主从架构啊,读写分离这样的方式呢,也是我们数据库调约的一大方向。那既然提到这样一个方向了,那这块呢,针对我们前面提到的一个SQ优化呀,索引呀,缓存呀等等,那么这些呢,它选择的一个先后顺序是什么呢?诶这块呢,其实咱们还是一个复习,前面呢在第九章当中我们已经讲到了,所以这样呢,咱们把这个前后内容啊,都能给它串在一起啊,诶你看咱当时呢,是不是画了一个这个图是吧?从这个成本角度来考虑的话呢,诶下边这个成本呢,是最低的啊,最高的这个成本呢,就是我们搭建一个服务器的集群了。
09:18
这个花钱是吧,诶这个成本最高,那那另外一个角度呢,从这个效果上来讲的话呢,反而下边这个效果呢,会更好啊,那特别好是吧,我们就希望看到这样的场景,那么结论什么呢?我们再去做调优和优化的时候呢,你是不是优先要考虑它呀,因为它成本最低,而且呢,这个效果还最好,那肯定要优先考虑它,然后就相当于是这样的一个方式去选择呗。啊诶,那也就是呢,我们考虑到说这个,诶我们并发访问呢,或者我们这个服务器的压力比较大呀,或者用户呢,感觉这个呃吞吐量比较低啊呃延迟比较长啊怎么办呀?哎,这时候你先别一上来就考虑说搭一个集群,哎面试的时候也是这样啊。大家不能面试的时候呢,面试官如果问到说我们现在这个用户的体验呢,就感觉比较差一点啊,延迟比较长是吧,这个吞吐量呢,也稍微的差一些,那我们该如何呢去处理呢?哎,这时候你别一上来说是我们搭个集群啊,你说对吗?诶也对,但是这肯定不是你最先考虑的事。
10:13
啊,这是不是得按照这样的一个顺序往上去走啊,啊,这一定要注意啊行。嗯,OK啊,这个我们就说到这儿啊,然后每次说这个三角的时候呢,其实我都会想起来一个类似的这样个场景啊,经常上课的时候呢,也会跟同学们做一个分享啊,就是大家呢,在这个找工作的时候呢,诶经常我们会有这样的一个思,就是我们会去这样想,诶怎么着想呢,就对应的有这样几层哈,哎,你比如说呢,咱们要找工作的话呢,你想怎么就能找着工作呢?诶我们可能最先考虑的就是最下边这一层啊,这个基数呢,也是最大的,就是我们去这个智联招聘呀,Boss直聘啊,拉勾啊,诶是不是就投简历。对吧,哎,这是呢,我们能想到的,或者最先想到的啊,所有人基本上也都是先想到的是这一点。好,那么再往上的话呢,就有可能会是一些这个特殊的一些途径,那比如说你要是在校的这个学生啊,你们学校的话呢,可能有这个专门的就业工作啊,就业指导中心,然后通过这样的一些场景和平台呢,我们去找到工作的啊这呢是一种途径,然后还有一种途径呢,诶非常重要的,我们叫做这个内推。
11:14
啊,大家如果找工作的话呢,可能尤其作为这个呃,新手来讲,你很难呢去想到内推,而且呢,你可能也没有资源呢,啊这个去实现这个内推是吧?哎,就是你可能优先想到的是这样个思路,但是呢,从这个公司招聘的呃,效果上来看,或者靠不靠谱上来看的话呢,从上往下呢,反而是越往上呢是越靠谱的。啊,就是公司呢,要做这个招聘呢,他其实优先考虑的其实就是内推啊,因为内推呢,就是自己的同事呢,对诶公司需求这个岗位的这个情况呢,是最了解的,而且呢,大家都在同行里边嘛,是吧,诶你肯定呢也了解相关的一些资源,这呢是最靠谱的,越往下呢越不靠谱。啊,你比如说这一个公司呢,他可能这个发出一个职位之后呢,这个有2000人这个应聘啊,这已经算是很夸张的了是吧?啊2000人里边呢,这个HR呢,一个个去联系啊,这个联系一圈之后呢,当然有好多这简历起来可能就有问题的,联系都联系不上的是吧?哎,可能这个有比如说这个哎500人。
12:06
啊,说确定了能过来啊,进一步的交流啊,500人可能都说多了啊啊有的人呢,可能都不知道投过这个简历啊,莫名其妙的这个人家就收着了啊,然后一问的话呢,说说诶我们没透过你们公司,那就白扯了是吧,这500人可能都多了啊,然后呢,邀约完以后的话,能过来呢,可能比如说这有100人啊,当然这100人可能少点啊,比如说300来过来了,然后呢,呃,这个开始跟HR聊,HR聊完以后呢,可能这个不靠谱的就已经是筛掉一半了。啊,或者100多剩100人,然后技术面试的话呢,有可能聊完之后呢,就剩十个到50个了啊,然后呢,最后谈薪资的时候呢,呃,这个可能谈的挺好,人也不一定来,最后呢,可能就留几个啊,有可能的话呢,一个也不靠谱啊,你要是着急的话呢,人家可能说得这个几个月之后呢才能入职啊,那甚至说呢,你这块呢,需要去分公司,人家可能也不乐意啊,最后结果呢,就是有可能白忙活一场。所以对于公司来讲的话,这个内推呢是最靠谱的啊,诶你包括咱们上午的这个讲师也是一样啊,都是属于稀缺资源,这个呢,诶咱们一直贯彻的政策就是说,诶自己的老师呢,你可以去推荐以前的朋友啊,或者诶原来的一些认识的一些讲师资源是吧?诶如果呢,一旦推荐成功啊,过了试用期,咱们至少呢,就会送当年的最新款的iPhone手机啊,配置呢你也随便挑。
13:18
啊,就是你可以选这个最高配的那个也是OK的啊,你要说就想要最低配的,那那也没问题是吧,哎,不给你补差价啊好,那就是这样啊,扯两句。好拉回来,那么通过我们刚才这样的一个说明的话呢,诶大家明确一下啊,就是呢,呃,一方面知道我们这个主从复制它的一个作用啊,就是提高我们这个并发能力的啊,另外一方面呢,把它呢,再融入到我们整个数据库调优的这样一个大的背景下的其中的一个环节当中啊就可以了,好,那我们接着往下讲啊,那么这个主从复制的一个作用是什么啊,这里边提到了说呢,能够提高吞吐量啊,毫无疑问,你多加一台机呢,肯定是能增加这个吞吐量的,不能白加呀,是吧?那除了这个提高吞吐量之外呢,我们说诶从三个角度呢,我们可以进一步的刻画,比如第一个啊叫读写分离。
14:04
啊,这个第二的话呢,就是数据备份,第三呢就具有高可用性,好我们分别呢来解读一下。啊实际上呢,都比较好理解啊,这个读写分离,那我们呢,就是呃,把这个服务器呢,集群搭建起来以后呢,我们可以啊针对这种读多写少的场景呢,我们让其中的一台啊机器呢充当这个写库啊负责呢写数写入数据的啊就是增删改是吧,DDL这样的一些操作,那我们把它呢为叫master啊叫写库,然后呢,其他的这些这个服务器呢,我们让它呢充当这个叫从库,叫做slave。啊叫做slave他们呢,主要是负责读的啊,因为呢写的场景少,读的场景多,所以呢,我们这个从基呢是可以多一些的啊,读库或者叫从基啊都可以。行啊,那这呢,就实现这个这个读写分离了是吧,但是这里边你要注意一个主要的场景,就是我们写入啊,这个相应这个表中这个数据呢,是不是一定要同步到我们这个统一上啊,这是一定要做的这个操作啊,那我们这个过程当中蕴含的问题啊,呃,也是在这个块儿啊,你同步的时候呢,能不能保证数据的这个一致性问题啊,诶这是我们要重点讨论的啊。
15:12
好呃,这个呢,就是我们说的这个读写分离啊,这样的一个场景,那么这样的设计完以后的话呢,可以使我们的这个什么呀,使这个从库的话呢,更加的顺畅。啊呃,其实这里边儿呢,我们要细的去说的话呢,应该是这样的哈,首先的话呢,我们读和写分离了,是不是分散了我们这个master的一个压力。对吧,诶读呢不用你管了,你光写就行,分散他的压力了,然后对于这个从库来讲的话呢,我们也可以呢,是不是设置多个从库,然后分散这个读的压力是吧,就进一步的去分散了啊,那么分散以后的话呢,就使得我们这个读呢就比较顺畅,那读这个顺畅的话呢,从另外一个角度来讲啊,不只是我们机器多了啊,另外一个原因呢,是因为我们减少了这个锁表的这种影响。你像原来呢,大家多个事物过来都去,诶诶多个这个事过来以后呢,都去访问我们这样的一台这个呃主机是吧?哎,那你这时候呢,大家就可能出现这种锁的场景,那现在你要是分散开以后啊,这时候呢,相当于是一个并行执行了是吧?哎这个时候呢,他就没有这个锁的行为了,这时候呢给用户的体验呢,不就会更好一些嘛啊所以这就读取呢,就更加的顺畅啊。
16:16
然后第二个作用呢,叫数据的一个备份。诶毫无疑问哈,你看我们这个主机呢,它把这个数据同步到我们统计上了,相当于统计上的是不是这个数据,咱们目前来理解啊,你也别考虑中间这个时间差了哈,诶相当于主机上的数据呢,从机上是不是全都有一份啊,这个时候我们就认为呢,诶很好的实现了一个数据的备份啊,还是一种热备份的一种机制啊。嗯,这是我们说的第二点,说第三个话呢,它的作用呢,叫具备高可用性啊,高可用呢,就ha啊这个害vilability是吧,高可用性呃,那么说数据备份呀,它实际上呢,是一种冗余的机制,诶通过这种冗余呢,我们来换取这种叫高可用性。啊,这个还是我们讲的说任何事物呢,都有利有弊是吧,你想获得他的好处,那你这块呢,就要付出一定的代价啊,你找一个女朋友啊,这个或者找一个媳妇儿啊,长得特别漂亮,身材也好,这个也温柔也体贴啊,什么都好啊,那你的代价是什么呢?呃,代价的话,最起码你自己呢,是不是也得配得上人家,否则的话呢,你是不是这个安全感特别没有。
17:15
啊,那别人呢,是不是都盯着啊,这个什么僧多肉少狼多肉少的是吧。不是僧多肉少了,僧多粥少哈哎,僧人不能吃肉哈哎,就是这样的场景,就是任何事物它都有利有弊啊,我们生活当中这种冗易的场景呢,其实也挺多的啊,咱们写程序写多了吧,一看到这个冗余呢,就觉得深恶痛绝,但是其实话呢,我们说很多场景下是一定要存在冗余的啊,生活当中你想机场的话呢,他不会说机场里边一个飞机都没有,全飞出去了。啊,火车站的话呢,你不能说这个轨道呢,一共是五个轨道全跑了,火车呢啊万一呢,中间有一条轨道出问题了,然后呢,会导致呃来回呢,有有有拥堵了,那不行是吧,总会有一些冗余的场景啊。好,呃,那么这里的话呢,我们说呃,它是一种冗余,然后的话呢,如果我们的这个主机啊,比如说它出现一些故障了啊,一些问题了,由于呢,我们这个数据呢,是不是都有备份啊,哎,我们可以呢,是不是把这个从基或者我们叫被记吧啊其实这里边提到这个叫从基,还有一个呢概念叫做被记啊嗯,这个从积的话呢,跟备机呢,其实你也可以泛泛的理解成是一样的啊,那你要说不一样的话呢,呃,有时候我们会把这个,诶这是一个主机哈,主机宕机以后的话呢,能够呃让剩下这些机器里边谁能立马顶上充当这个血的功能,我们就把它称为呢叫背脊了。
18:30
啊,从机的话呢,我们可以理解成呢,就是专门负责读的啊,你可以这样来去理解,好,那就相当于的话呢,如果我们这个服务器主机啊,这个写库它宕机以后啊,我们呢,立马呢,可以切换到我们这叫从服务器上啊,我们叫飞机上保证服务的一个正常运行啊,这就保证这种高可用性啊。那我们在这个高可用性这方面呢,可以用一个指标来衡量,比如呢,全年当中啊,全年这个时间当中,你正常用的时间啊,除以这个全年时间,然后呢,如果说比例达到99.999%。
19:00
啊,那这呢,意味着什么呢。我们这样核算一下是吧,诶最后呢,就意味着相当于你有5.256这样的时间啊分钟用户呢,是访问不到你的这个后台的啊,那这里面呢,就包含了系统崩溃的时间,也包括了你日常维护呢导致的这个停机的时间。啊,当然了,哎,从用户这个角度来看的话呢,他可能会啊,一访问,比如访问京东没访问上,他可能会以为他自己的网不好,是吧?啊一会儿一问又好了啊哎就是这样的场景,所以呢,有很多时候呢,可能他不认为呢,是服务器的问题了啊用户呢,可能认为他自己网的问题啊呃,总共呢,反正是占那么多时间啊好这呢,就我们说的这个事。行,然后的话呢,我们再说一下这个主从复制的一个原理啊,主从复制的原理呢,就是我们slave呢,从这个master里边去读取这个blog呢,进行数据的一个同步。啊,进行数据的同步,这里边儿呢,就出现我们这个blog了,哎,这也是他非常重要的一个角色和使用场景。哎,首先的话呢,我们这里边啊,剖析这个原理,哎,我们提到了有三个线程啊这块大家看这个图呢,可能有点懵,这个图的话呢,应该是网上比较经典的。
20:06
啊,但是这个图网上经典的那个呢,感觉不好看啊,这块又重绘了一下啊,哎,就是这样的图。好,那么这个图里边呢,还稍微的简洁一些,咱们先来简单的说一下啊,在我们这个master叫做这个主机啊,或者叫这个主库啊,写库啊都行,在这个机器里边呢,我们有一个叫啊blog日志文件是吧,然后在我们这个从库啊从集里呢,它有一个呢叫relog,那我们叫中继日志,或者你也可以呢,给它称为一个叫中转日志也行啊,有的呢,就也这样去叫啊。行,那么在这两个机器上啊,这呢,咱就算叫易主易从了哈,哎中间呢,是如何交互的呢?哎,就是我们把这个数据呢写到这儿,然后呢,这块呢,呃去读,读到我们这个这个从级上,从级上读完以后的话呢,哎,他再写到我们这个中级日志上,然后呢这个诶另外一个线程呢,再从中级日上把这个数据呢,读到他自己这个表里边做做同步,哎泛泛一讲就是这样个过程。
21:00
啊,就是这样个情况是吧,那么我们具体要说呢,这里边儿涉及到是哪三个线程呢。哎,有这样的三个线程,第一个线程的话呢,在我们这里边,哎,你这个呃,Slave啊,你这个从集是不是要把这个呃bary,就我们叫嗯二进制的日志文件呢,这个数据你是不是要这个读过来啊啊那这呢,我们两端是不是大家都得各自有一个线程啊啊然后呢,这个你要请求我了,我这块得把数据发给你,这就是我们这个主机上的这样的一个线程。啊,我们这个主库上的是吧?诶主机上这样一个线程叫二进制日志的转储线程,他呢负责呢把这个数据呢给它发出去啊,然后呢,在我们这个从集上的话呢,你得有个线程是不是专门专门来接收这个数据吧?啊这个呢,就我们从库的一个叫IO线程啊,它来接收的,它接收完以后的话呢,紧接着就把它写出到我们这个叫终极日志当中了。啊,读进来写出去啊,这个呢,就是我们呃第二个线程它的一个角色啊,然后第三个线程的话呢,我们叫circle thread啊circle thread它呢,就主要负责呢,从我们这个中继日志当中,把这些事件啊,咱们说了每一个更改的这个语句是不是都是一个事件了啊然后呢,我们这个呃。
22:12
从这个中心日志当中啊,把这些事件呢都读进来,然后呢,去做个执行啊,更新一下你这个从机上的这个数据库中的这个表中的数据啊,实现一个主从它的一个同步。啊,就这样一个过程,好,那么这个过程的话呢,如果我们画成这样个图的话呢,诶就是这样子的,你看就我刚才说的是吧,哎,当然这呢不是就是写入我们这个blog的,这是别的线程啊,跟我们现在说的这三个线程没关系了。啊,写入到这儿,然后呢,我们这个呢叫诶这个b log damp这个thread是吧,然后呢,他呢负责发,然后这块呢来负责接,接完以后呢,来写入到我们这个log当中,然后这是第二个线程啊第三个线程的话呢,从这里边取完之后呢,再诶更新一下我们的这个数据库,哎就这样个过程。好,那么在这个过程当中,我们提到呢,就是这块呢,再去读这个blog日志数据的时候呢,它会有一个加锁的操作啊,这个大家应该能理解是吧?啊因为这块呢去读,然后呢,还要再去写入呢,就会出现一个并发的问题哈,哎,我们有个枷锁的行为,然后呢,发送完之后呢,你再把这个锁释放掉啊就可以了。
23:14
好,别的这块没啥可说的哈。呃,然后这里边呢,要强调一个点啊,就是呃,咱们这个冰烙日志的话呢,需要注意一下,你要实现这个主从复制的话呢,一定要记得我们这个日志呢,它得是个开启的状态啊,前提呢,记得去检验一下啊,那我们一会儿呢,做一个配置的时候呢,其实自动的也就做了一个检验啊,OK,然后的话呢,我们说呢,如果没有特殊的这个情况的话呢,咱们默认情况下呢,就都会把这个主机上的呃,这个b log日志文件中的所有的事件呢,就都发给我们这个统计了。啊,就是默认情况下就都发了,相当于我们就实现的是一个同步啊,你也可以呢,通过这种特殊的配置呢,你让他去只是执行这种指定的这种事件啊,也是OK的啊行。啊,这是这个事儿,然后下边这个呢,叫复制的三步骤啊,其实这呢,咱们刚才已经都讲过了啊呃,大家呢,只不过呢,是在这个面试当中呢,你可以把这个归结成绩叫三个步骤啊第一步呢,就是诶master呢,写入到这个呃,这个二进制日文件的一个过程,第二步的话呢,就是我们这块呢,从呃slave呢,从我master里边呢,把这个事件呢,拷贝到他自己这个终极日志的一个过程。
24:15
然后第三步呢,就是呃,读这个终极日证的这个事件啊,然后呢,把它呢,应用到自己的数据库当中啊,就是做一个数据的同步,实际上呢,这块呢,对应的也就理解成是我们的三个县城做的事儿是吧。好,下面呢,提到说这个复制的一个最大问题,最大的问题呢,就是一个延时的问题。啊,延时的问题啊,你比如说啊,我们现在的话呢,呃,有一个update的一个行为,这个update的行为呢,是不是就记录到我们这个blog里边了,然后呢,我们这块呢,把这个事件呢,就COMMIT1提交,诶一提交,然后这时候的话呢,我们就写入到blog里边了,然后紧接着呢,它就走这个事儿写入到这儿这块呢,再同步到我们这个表里边,假设呢,从我们提交这个事件,当你整个呢,在我们的这个从库当中啊,从积当中,这个库当中体现出来。啊,整个一步过来,同步以后,假设呢,我们需要呢,500毫秒。
25:04
能理解是吧,诶这块呢,通过一个网络的方式呢,这不是传输嘛,假设呢,需要500毫秒,好,那么假设呢,这个用户呢,你看啊,他这个做一个update的操作,他一提交,然后呢,马上呢,他做一个select的查询啊,你看啊,我们写的话呢,是写到这儿,我要查询的话呢,是不是就要从这查了啊,那么假设呢,这个提交完以后呢,他的查询呢,咱们夸张点啊,需要200毫秒。啊,那么这时候呢,大家你会发现是不是有问题了啊,我们写到这儿的数据,哎,500毫秒才能到这儿,而我们在二秒毫秒的时候呢,我就去读了,那这时候你读到这个数据呢,跟你当初写的这个呢,肯定是就出现不一致的问题了。对吧,哎,那我们后边呢,是不是就是解决这种不一致的,哎,不一致性的这个问题该怎么去做是吧,或者我们先去看待怎么会出现这种不一致的问题啊,然后呢,我们尽可能的啊去做相关的一些设置,让他先尽量的这个时间的缩短是吧?啊比如说你这个统计的配置啊等等这些都是一些问题啊,啊然后的话呢,我们再从这个具体的算法层面上去控制它啊,尽量的是保证一致性。
26:05
OK啊。好,这个呢是大家啊重点要关注的,然后呢,这里边儿这个复制的原则是什么呢?说每个slave呢,只能有一个master。啊,每个slave相当于呢,你这个从机的话呢,它是要从我们这个主机上来进行这个数据的获取和同步的,你不能整俩主机,那到底听谁的呀?不乱套了嘛,是吧,还说只能有一个啊,然后每个slave呢,只能有一个唯一的服务器ID啊,不管它这个主机的话呢,我们也得一个唯一的这个服务器ID啊,说每个master呢,可以有多个slave啊,一主多从嘛,啊就是这样一个场景。好,那这块呢,就是一些基本点啊,我们就先说清楚,然后下面的话呢,我们就给大家呢,通过代码层面呢,去搭建一个啊一主一从。
我来说两句