内部群炸锅了，同事又删库了...( 四 ) 最近发生了一场生产事故

备份周期可以根据业务需要来决定。如果业务对数据要求的实时性比较高，备份周期相对短一点，恢复数据时可以最大程度的避免数据丢失;反之，备份周期可以长一点，节省磁盘空间。
如果有必要，可以定期把备份文件拷贝到异地服务器，避免由于一些不可抗力因素导致的当前服务器磁盘损坏，如地震、台风等。
五、binglog日志
binlog即BinaryLog ，它是二进制文件，用来记录数据库写操作的日志。
数据库的insert、delete、update、create、alter、drop等写入操作都会被binlog记录。
因此，数据库的主从数据同步通常也是基于binlog完成的，本文只对binlog做一些简单介绍，后期会单独写一篇文章讲基于binlog的主从数据同步。
binlog日志需要配置开启，可以通过脚本查看binlog是否开启：
SHOWVARIABLESLIKE'LOG_BIN%';
文章图片
如果log_bin参数显示的是OFF说明binlog是关闭状态，需要手动开启。
开启binlog需要修改数据库的my.cnf配置文件， my.cnf文件通常在服务器的/etc目录下。
#启用binlog并设置binlog日志的存储目录log_bin=/var/lib/mysql/bin-log#设置binlog索引存储目录log_bin_index=/var/lib/mysql/mysql-bin.index#30天之前的日志自动删除expire_logs_days=30#设置binlog日志模式，共有3种模式：STATMENT、ROW、MIXEDbinlog_format=rowbinlog的日志有三种格式，分别是STATEMENT、ROW、MIXED 。
在mysql5.7.7版本之前默认使用的是STATEMENT ，之后的版本默认使用的是ROW 。
①ROW格式
ROW格式下， binlog记录的是每一条数据被修改的详细细节。
比如，执行delete语句，删除的数据有多少条， binlog中就记录有多少条伪sql：
deletefromt_userwhereage>18;
文章图片
那么row格式的日志的缺点就很明显，在发生批量操作时，日志文件中会记录大量的伪sql ，占用较多的磁盘空间。
尤其是当进行alter操作时，每条数据都发生变化，日志文件中就会有每一条的数据的日志。此时，如果表中的数据量很大的话，日志文件也会非常大。
在mysql5.6版本之后，针对ROW格式的日志，新增了binlog_row_image参数。
当binlog_row_image设置为minimal时，日志中只会记录发生改变的列，而不是全部的列，这在一定程度上能减少binlog日志的大小。
虽然记录每行数据的变化会造成日志文件过大，但这也是它的优点所在。
因为它记录了每条数据修改细节，所以在一些极端情况下也不会出现数据错乱的问题。在做数据恢复或主从同步时能很好的保证数据的真实性和一致性。
②STATEMENT格式
STATEMENT格式下，日志中记录的是真正的sql语句，就像是这样：

文章图片
日志中的sql是直接可以拿到数据库运行的， STATEMENT格式的日志的优缺点和ROW格式的正好相反，它记录的是sql语句和执行语句时的上下文环境，而不是每一条数据。
所以它的日志文件会比ROW格式的日志文件小一些，由于记录的只是sql语句和上下文的环境， STATEMENT格式的日志在进行主从数据同步时会有一些不可预估的情况出现，导致数据错乱。
比如sleep()、last_insert_id()等函数会出现问题。
③MIXED格式
MIXED格式是STATEMENT和ROW的结合， mysql会根据具体执行的sql语句，来选择合适的日志格式进行记录。
MIXED格式下，在执行普通的sql语句时会选STATEMENT来记录日志，在遇到复杂的语句或函数操作时会选择ROW来记录日志。