基本概念
数据的复制指的是通过网络链接的多台机器保留相同的副本
- 为什么要进行数据的复制
- 使得用户和数据在地理上比较接近,因为大数据要求我们将计算安排在数据存放的位置和我们基本的内存模型不是很一样 ,比如磁盘调入内存之类的。
- 即使系统的一部分机器出现了故障,系统也能正常工作,这个指的是如果一个节点出现宕机,应该怎么处理才能使系统正常工作。
- 扩展可以接收读请求机器的数量,如果有很多个机器进行读,如果只有一个副本的话,那么系统就会发生崩溃,有点类似于DNS泛洪攻击的原理。
领导者和追随者的复制
我们这里假设的情景是基于领导者的复制或者是说主从库的复制。
- 副本的概念:
当有多个副本的时候我们会思考几个问题,当存储多个副本的时候如何确保所有的数据落到所有的副本上,就类似于通知从教学秘书下放到计算学部大群, 我们到底是采用让所有的同学向教学秘书确认他收到消息了才算下放完成,还是说让辅导员老师通知班长下放消息 然后反馈给教学秘书我已经全通知完了。 - 同步和异步的优劣
同步的好处是可靠性很高 但是缺点是消耗资源,异步的优点
我们发现follower1的复制是同步的 但是2的复制是异步的 - 半同步
实际上 数据库大多是采用半同步复制的策略,也就是上面的图展示的样子,指定一个主库,并且从中指定一个从库使得主库和从库的复制是同步的,主库和其他从库的复制是异步的。这样的好处是如果一个主库发生的宕机,那么我们指定好了一个新的主库之后就把这个同步的从库的内容直接复制过去就行了。 - 半同步背景下,节点的加入节点的宕机复制日志的实现细节
我们采用比较多的是半同步复制,那么我们不妨看下底层的具体是如何实现的
由于大数据具有实时性的特点,任何时候都可能发生数据的更新,所以我们从库拉取的数据也未必是最新的数据,我们的数据库需要进行如下处理:首先拉取主库的一致性快照,快照复制到新的从库节点,然后将这些快照复制到新的从库节点,之后从库连接主库,并拉取复制快照之后的所有变更,这样新的节点就赶上主库了。
系统中任何的节点都可能宕机:包括主库 从库1 从库n也就是大老板 小老板 打工人都有可能出现故障,如果是从库发生故障 那么解决的方法非常简单,就是和新加入的节点的方法类似,首先修好之后,从库连接主库,并拉取宕机之后的日志,完成追赶。。主库发生故障这个问题是非常棘手的,首先我们需要考虑选谁充当主库,这个可以通过选举产生,也就是统计相同副本数量的个数来选举其次有可能出现两个或者多个从库同时充当主库的情况(类似于汉高祖失去权力之后 各路诸侯纷争)这个时候就会出现一个脑裂的情况,解决方法很粗暴如果两个的话随机关闭一个。还有一个问题就是可能会存在冲突的写入,老领导回来之后可能会产生冲突的写入,避免冲突写入的方法就是忽略老节点的写入,但是这样会破坏数据的持久性写入的原则。
- 日志的复制:
- 基于语句的复制:主库想要写入什么内容,比如情景是关系数据库update或者是delete之类的语句,但是这样可能会产生一想不到的后果,比如我让你们寝室的人都去老师那签到,本来老师以为是239的人是小明和小方,但是这两个人串寝室了,所有结果是小红和小绿去老师那报道了,所以除非有特别确定的结果,基于语句的复制是不好的。
- 传输预写日志
- 逻辑日志的复制
- 基于触发器的复制