近期实验室总是不给通知的就停电，导致我们在不停的恢复服务。在某一个断电的过程中，发现我们的项目管理工具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来解决，等有时间再研究吧。