mysql数据库主从备份
近期实验室总是不给通知的就停电,导致我们在不停的恢复服务。在某一个断电的过程中,发现我们的项目管理工具redmine的硬盘挂掉了。。因为是部署在虚拟机上的,也没做冗余,数据就丢了。。于是反思,我们的mysql也是部署在虚拟机上,如果这次坏掉的是我们的mysql怎么办?
然后,然后就有了这篇文章。
数据的备份一般分为三种:
- 热备
- 冷备
- 温备
热备顾名思义,是在不停机的时候备份数据库。冷备是在数据库停止的情况下备份数据库,这种备份最为简单,一般只需要复制相关的数据库物理文件即可。温备同样是数据库运行中进行的,但是会对当前数据库的操作有所影响。
按照备份后文件的内容,备份可以分为:
- 逻辑备份
- 裸文件备份
逻辑备份是指备份出的文件是可读的,一般是文本文件。内容一般是一条条SQL语句。如使用mysqldump和SELECT*INTO OUTFILE。这种方式好处就是可见呗,坏处就是由于是sql语句,同时执行大量的sql语句恢复的时间可想而知。。。裸文件备份是指复制数据库的物理文件。
按照备份数据库的内容来分的话,备份又可以分为:
- 完全备份
- 增量备份
- 日志备份
对于mysql来说,官方并没有提供真正增量备份的方法,大部分是通过二进制日志完成增量备份的工作。
我们这里就选用的是日志备份来实现主从分离的。
这里需要一个主mysql和至少一个从mysql。如下图所示:
复制的原理就是分了三部而已:
1.master把数据更改纪录到二进制日志(binlog)中。[mysql启动时候需要加入相关参数;binlog二进制文件纪录了对Mysql数据库执行更改的所有操作,但一般不包括select和show这类操作]
2.slave把主服务器的二进制文件复制到自己的中继(relay log)中。
3.slave重做中继日志中的日志,把更改应用到自己的数据库上。
具体的过程其实也并不复杂:
在 Master 与 Slave 之间的实现整个复制过程主要由三个线程来完成,其中两个线程(Sql线程和IO线程)在 Slave 端,另外一个线程(IO线程)在 Master 端。
1. Slave 上面的IO线程连接上 Master,并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容;
2. Master 接收到来自 Slave 的 IO 线程的请求后,通过负责复制的 IO 线程根据请求信息读取指定日志指定位置之后的日志信息,返回给 Slave 端的 IO 线程。返回信息中除了日志所包含的信息之外,还包括本次返回的信息在 Master 端的 Binary Log 文件的名称以及在 Binary Log 中的位置;
3. Slave 的 IO 线程接收到信息后,将接收到的日志内容依次写入到 Slave 端的Relay Log文件的最末端,并将读取到的Master端的bin-log的文件名和位置记录到master- info文件中,以便在下一次读取的时候能够清楚的高速Master“我需要从某个bin-log的哪个位置开始往后的日志内容,请发给我”
4. Slave 的 SQL 线程检测到 Relay Log 中新增加了内容后,会马上解析该 Log 文件中的内容成为在 Master 端真实执行时候的那些可执行的 Query 语句,并在自身执行这些 Query。这样,实际上就是在 Master 端和 Slave 端执行了同样的 Query,所以两端的数据是完全一样的
需要注意的一点是,这里的同步其实还是异步的。所以并不是完全实时的,还是存在 Slave 数据延时以及数据丢失的可能性的。
怎么解决这个问题,貌似实要用cluster来解决,等有时间再研究吧。