一、binlog原理？

第一阶段：InnoDB prepare， write/sync redo log；binlog不作任何操作；

第二阶段：包含两步，1> write/sync Binlog； 2> InnoDB commit (commit in memory)；

当然在5.6之后引入了组提交的概念，可以在IO性能上进行一些提升，但总体的执行顺序不会改变。

当第二阶段的第1步执行完成之后，binlog已经写入，MySQL会认为事务已经提交并持久化了(在这一步binlog就已经ready并且可以发送给订阅者了)。在这个时刻，就算数据库发生了崩溃，那么重启MySQL之后依然能正确恢复该事务。在这一步之前包含这一步任何操作的失败都会引起事务的rollback。

第二阶段的第2步大部分都是内存操作，比如释放锁，释放mvcc相关的read view等等。MySQL认为这一步不会发生任何错误，一旦发生了错误那就是数据库的崩溃，MySQL自身无法处理。这个阶段没有任何导致事务rollback的逻辑。在程序运行层面，只有这一步完成之后，事务导致变更才能通过API或者客户端查询体现出来。

二、mysql怎么启用binlog？

它是逻辑备份,优点可以备份各种存储引擎1.备份所有的数据库#mysqldump-uroot-p--all-database>all.sql2.备份指定的数据库#mysqldump-uroot-ptest>test.sql3.备份指定数据库中的表#mysqldump-uroot-ptests>test_s.sql备份完全恢复实例(1)上午9点备份数据库#mysqldump-uroot-p-l-Fstudent>student.dmp-l给所有表加读锁-F生成一个新的日志文件此时s表数据如下:mysql>select*froms;+------+-------+------+-----------+|sno|sname|sex|address|+------+-------+------+-----------+|0901|Jim|1|shanghai||0902|helun|2|beijing||0903|sam|1|sichuan||0904|keke|1|xizang||0905|gugu|1|suzhou||0906|tang|2|guangdong|+------+-------+------+-----------+6rowsinset(0.00sec)备份完毕等到了student.dmp文件,还有mysql-bin.000012(2)9点半备份完毕,然后插入新的数据mysql>insertintosvalues('0907','liu','1','jiangxi');QueryOK,1rowaffected(0.00sec)mysql>insertintosvalues('0908','wang','2','wuxi');QueryOK,1rowaffected(0.00sec)(3)10点,数据库突然故障,数据无法访问.需要恢复备份:#mysql-uroot-pstudent<student.dmp恢复后的数据:mysql>select*froms;+------+-------+------+-----------+|sno|sname|sex|address|+------+-------+------+-----------+|0901|Jim|1|shanghai||0902|helun|2|beijing||0903|sam|1|sichuan||0904|keke|1|xizang||0905|gugu|1|suzhou||0906|tang|2|guangdong|+------+-------+------+-----------+6rowsinset(0.00sec)(4)使用mysqlbinlog恢复mysqldump备份以来的BINLOG#mysqlbinlogmysql-bin.000012|mysql-uroot-pstudent查询完全恢复后的数据:mysql>select*froms;+------+-------+------+-----------+|sno|sname|sex|address|+------+-------+------+-----------+|0901|Jim|1|shanghai||0902|helun|2|beijing||0903|sam|1|sichuan||0904|keke|1|xizang||0905|gugu|1|suzhou||0906|tang|2|guangdong||0907|liu|1|jiangxi||0908|wang|2|wuxi|+------+-------+------+-----------+8rowsinset(0.00sec)恢复完成!基于时间点的恢复(不完全恢复)由于误操作,比如删除了一张表,使用完全恢复是没有用的,我们需要的是恢复到误操作之前的状态,然后跳过误操作语句,再恢复后面执行的语句,完成恢复;例:(1)上午10点发生误操作,可以用如下语句备份和BINLOG将数据恢复到故障前#mysqlbinlog--stop-date="2010-10-319:59:59"/usr/local/mysql/var/mysql-bin.000013|mysql-uroot-p(2)跳过故障时间点,继续执行后面的BINLOG,完成恢复#mysqlbinlog--start-date="2010-10-3110:01:00"/usr/local/mysql/var/mysql-bin.000013|mysql-uroot-p基于位置恢复(不完全恢复)和基于时间点恢复类是,但是更加精确.因为同一时间点可能有多条SQL语句执行;例:#mysqlbinlog--start-date="2010-10-319:55:00"--stop-date="2010-10-3110:05:00"/usr/local/mysql/var/mysql-bin.000013>/tmp/mysql_restore.sql该命令将在/tmp/目录下创建小的文件,编辑它找到错误语句前后的位置号,例如前后位置号分别是368312和368315(2)恢复了以前的备份文件后,输入#mysqlbinlog--stop-position="368312"/usr/local/mysql/var/mysql-bin.000013|mysql-uroot-p#mysqlbinlog--start-position="368315"/usr/local/mysql/var/mysql-bin.000013|mysql-uroot-p

三、如何使用MySQL Binlog进行数据库恢复

MySQL是一个常用的关系型数据库管理系统，而Binlog是MySQL中用于记录数据库更改的日志文件，可以用于数据恢复。在数据库运维中，有时候会遇到意外删除数据或者误操作需要回滚数据的情况，这时候使用MySQL Binlog就非常重要。

什么是MySQL Binlog

MySQL的Binlog（Binary Log）是MySQL数据库的二进制日志，用于记录对数据库进行更改的所有操作，包括数据库表的增删改以及数据的增删改。通过对Binlog的分析，可以将数据库恢复到某个指定的时间点，或者对特定的操作进行回滚。

如何使用MySQL Binlog进行数据库恢复

要使用MySQL Binlog进行数据库恢复，首先需要确保MySQL服务器已经开启了Binlog功能，之后可以按照以下步骤进行：

1. 查看Binlog文件 使用命令SHOW BINARY LOGS;来查看当前的Binlog文件列表，找到需要恢复的时间点对应的Binlog文件名。
2. 创建临时目录 在MySQL服务器上创建一个临时目录，用于存放恢复时需要的Binlog文件和恢复出来的SQL文件。
3. 使用mysqlbinlog工具解析Binlog 使用mysqlbinlog命令来解析Binlog文件，该命令会生成一系列的SQL语句，用于恢复数据库。
4. 恢复数据库 将生成的SQL文件应用到MySQL数据库中，恢复数据到指定的时间点。

注意事项

在使用MySQL Binlog进行数据库恢复时，有一些需要注意的事项：

• 确保备份当前的数据库，以防恢复操作出现意外。
• 谨慎选择恢复的时间点，需要保证恢复时的Binlog文件是完整的，否则可能会导致恢复失败。
• 恢复操作需要谨慎，可以在测试环境中进行验证后再应用到生产环境。

通过以上步骤，可以使用MySQL Binlog来进行数据库的恢复，帮助数据库管理员应对意外删除或误操作的情况，保障数据的安全性和完整性。

感谢您阅读本文，希望对您了解如何使用MySQL Binlog进行数据库恢复有所帮助。

四、mysql开启binlog日志

MySQL开启binlog日志的重要性和步骤

在数据库管理中，binlog日志是一项关键功能。它记录了MySQL数据库中的所有操作，包括对于储存的数据进行的更改、删除或插入操作。开启binlog日志对于数据库的可靠性、备份恢复以及数据一致性都起着至关重要的作用。本篇博文将为您介绍MySQL开启binlog日志的重要性以及相应的步骤。

binlog日志的重要性

binlog日志是MySQL主从复制的基础，它是实现数据备份、数据还原和故障恢复的重要工具。

首先，binlog日志能够记录所有的数据更改操作，包括UPDATE、INSERT、DELETE等操作。通过这些记录，我们可以追踪到每个数据库对象的修改历史，保证了数据库的安全性和可靠性。

其次，通过binlog日志，我们可以轻松实现数据库的备份和还原。通过备份binlog日志，我们可以恢复数据库到指定的时间点，避免数据丢失和数据不一致的情况。

最重要的是，binlog日志对于数据库主从复制具有至关重要的作用。在主从复制中，主数据库会将自己的binlog日志发送给从数据库，从数据库根据binlog日志进行数据的同步操作。这个过程能够实现数据库的高可用性和数据的分布式访问。

开启binlog日志的步骤

下面，我们来介绍一下开启binlog日志的具体步骤：

1. 使用root用户登录MySQL数据库。
2. 编辑MySQL的配置文件my.cnf，一般位于/etc/mysql/或者/etc目录下。
3. 在my.cnf文件中找到[mysqld]段，如果不存在则创建。
4. 在[mysqld]段中添加如下配置项：

log-bin = mysql-bin binlog-format = ROW server-id = 1

log-bin：指定binlog日志的名称，mysql-bin是一个示例名称，您可以根据自己的需求进行修改。

binlog-format：指定binlog日志的格式，ROW表示记录每一行的变更。

server-id：每个MySQL实例的唯一标识，用于主从复制中的数据传输。

保存并关闭my.cnf文件。

5. 重启MySQL数据库，使配置生效。
6. 验证是否成功开启binlog日志。可以使用如下命令查看：

      
        SHOW VARIABLES LIKE 'log_bin';
      
    

如果显示log_bin的值为ON，则表示开启binlog日志成功。

注意事项

在开启binlog日志之前，需要注意以下几点：

• 开启binlog日志会对数据库的性能产生一定的影响，因为需要进行额外的日志记录和操作。在高负载的生产环境中，需要谨慎开启。
• 定期备份binlog日志，并设置合适的保留时间，以避免数据丢失。
• 请确保MySQL的版本支持binlog日志。
• 在配置binlog日志的时候，建议参考MySQL官方文档，了解每个配置项的含义和影响。

总结

开启MySQL的binlog日志对于数据库的稳定性、可靠性以及数据备份恢复都至关重要。它能够记录所有的数据更改操作，保证数据库的安全性和一致性。通过binlog日志，我们可以轻松实现数据库的备份和恢复，以及数据库的主从复制。在开启binlog日志之前，需要谨慎考虑数据库的负载以及设置合适的保留时间。

希望通过本篇博文的介绍，您能够了解MySQL开启binlog日志的重要性和相应的步骤，并正确配置binlog日志，保证数据库的稳定运行。

五、mysql binlog事务怎么记录？

用来判断binlog中每条记录是在哪个服务器上产生的，在主主复制架构中可以防止无限复制循环。#Enteranamefortheerrorlogfile.Otherwiseadefaultnamewillbeused.log-error=err.log#Enteranameforthequerylogfile.Otherwiseadefaultnamewillbeused.#log=#Enteranamefortheslowquerylogfile.Otherwiseadefaultnamewillbeused.#log-slow-queries=#Enteranamefortheupdatelogfile.Otherwiseadefaultnamewillbeused.#log-update=#Enteranameforthebinarylog.Otherwiseadefaultnamewillbeused.#log-bin=

六、binlog三种模式的区别？

binlog模式分三种：row、statement、mixed。主要区别就是三种模式的运行方式和优缺点不同。

1.Row

日志中会记录成每一行数据被修改的形式，然后在slave端再对相同的数据进行修改，只记录要修改的数据，只有value，不会有sql多表关联的情况。

优点：在row模式下，bin-log中可以不记录执行的sql语句的上下文相关的信息，仅仅只需要记录那一条记录被修改了，修改成什么样了，所以row的日志内容会非常清楚的记录下每一行数据修改的细节，非常容易理解。而且不会出现某些特定情况下的存储过程和function，以及trigger的调用和出发无法被正确复制问题。

缺点：在row模式下，所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容。

2、statement

每一条会修改数据的sql都会记录到master的binlog中，slave在复制的时候sql进程会解析成和原来master端执行多相同的sql再执行。

优点：在statement模式下，首先就是解决了row模式的缺点，不需要记录每一行数据的变化减少了binlog日志量，节省了I/O以及存储资源，提高性能。因为他只需要记录在master上所执行的语句的细节以及执行语句的上下文信息。

缺点：在statement模式下，由于他是记录的执行语句，所以，为了让这些语句在slave端也能正确执行，那么他还必须记录每条语句在执行的时候的一些相关信息，也就是上下文信息，以保证所有语句在slave端被执行的时候能够得到和在master端执行时候相同的结果。

3、Mixed

从官方文档中看到，之前的 MySQL 一直都只有基于 statement 的复制模式，直到 5.1.5 版本的 MySQL 才开始支持 row 复制。从 5.0 开始，MySQL 的复制已经解决了大量老版本中出现的无法正确复制的问题。但是由于存储过程的出现，给 MySQL Replication 又带来了更大的新挑战。

另外，看到官方文档说，从 5.1.8 版本开始，MySQL 提供了除 Statement 和 Row 之外的第三种复制模式：Mixed，实际上就是前两种模式的结合。在 Mixed 模式下，MySQL 会根据执行的每一条具体的 SQL 语句来区分对待记录的日志形式，也就是在 statement 和 row 之间选择一种。新版本中的 statment 还是和以前一样，仅仅记录执行的语句。

而新版本的 MySQL 中对 row 模式也被做了优化，并不是所有的修改都会以 row 模式来记录，比如遇到表结构变更的时候就会以 statement 模式来记录，如果 SQL 语句确实就是 update 或者 delete 等修改数据的语句，那么还是会记录所有行的变更。

七、mysql binlog同步的三种方式？

mysql复制主要有三种方式：基于SQL语句的复制(statement-based replication, SBR)，基于行的复制(row-based replication, RBR)，混合模式复制(mixed-based replication, MBR)。对应的，binlog的格式也有三种：STATEMENT，ROW，MIXED。

八、怎么样安全删除mysql下的binlog日志？

首先，建议你在删除之前先对数据库用mysqldump做个全库备份。然后进入Mysql（用root用户）。

然后 show binary logs ，这个命令会列出当前保存的所有二进制日志。

然后用命令： purge binary/master logs to 日志名（表示到这个日志之前的日志都删除掉）/before 时间（表示到这个时间之前的日志都删除掉） 里面用“/”标明的是前后两个二选一的可选项。

执行完后，就会删除了。 如果你不想这么麻烦，可以设置日志保存时长的。

首先你要找到my.cnf配置文件，然后编辑它。在[mysqld]里面加入 expire_logs_days=想要保留的天数 然后重启Mysql服务。

这样每当你重启mysql服务，或者是做flush logs的时候，系统都会把超出设置天数之外的日志删掉。

九、mysql的binlog太大太多占用大量磁盘的解决？

今天有个同事来问我，说mysql目录下有很多1.1G的mysql-bin.00000*文件，占用了100多G，占用磁盘空间非常大，这些文件都是msyql日志文件，从几m到几个G都有可通，要解决这个问题并不难，只要修改/etc/my.cnf文件里的#log-bin=mysql-bin和#binlog_format=mixed把这二行注释掉，重启数据库就可以了！

十、如何建立数据库，利用什么软件建立数据库？

啥叫数据库？excel也可以算，access也可以算，mysql也可以算，hbase也可以算，你要数据库干啥，决定了你怎么搭建数据库。