oradbm的博客

由于服务器生成的二进制日志文件以二进制格式保存，所以如果想要检查这些文件的文本格式，就会用到mysqlbinlog日志管理工具。mysqlbinlog的具体用法如下：option有很多选项，常用的选项如下。-d, --database=name：指定数据库名称，只列出指定的数据库相关操作。-o, --offset=#：忽略掉日志中的前 n行命令。-r, --result-file=name：将输出的文本格式日志输出到指定文件。

以下为测试mysql数据库备份脚本，包括增量备份。

如果innodb_flush_log_at_trx_commit设置为 0：log buffer将每秒一次地写入log file中，并且log file的flush(刷到磁盘)操作同时进行.该模式下，在事务提交的时候，不会主动触发写入磁盘的操作;innodb_flush_log_at_trx_commit 是 innodb 引擎的配置，sync_binlog 是 MySQL 引擎上层的配置，都是控制磁盘写入策略。sync_binlog：binlog 的刷盘策略，默认为0。binlog 写内存。

xtrabackup特性：1、支持热备份2、支持对InnoDB、MyISAM,xtradb存储引擎的备份3、备份过程快速、可靠4、备份过程不会打断正在执行的事务5、能够基于压缩等功能节约磁盘空间和流量6、自动实现备份检验7、还原速度快1.XtraBackup复制InnoDB数据文件，这会导致内部不一致的数据，但是它会对文件执行崩溃恢复，以使其再次成为一个一致的可用数据库2.这样做的可行性是因为InnoDB维护一个REDO日志，也称为事务日志。

当redolog设置commit发生异常时，并不会回滚事务，它会执行上图框住的逻辑，虽然redo log是处于prepare阶段，但是能通过事务id找到对应的binlog日志，所以MySQL认为是完整的，就会提交事务恢复数据。因此，之后用binlog日志恢复数据时，就会少这一次更新，恢复出来的这一行c值是o，而原库因为redo log日志恢复，这一行c值是1，最终数据不一致。在这种情况下，就可能导致你恢复从服务器的时候，无法从宕机前的中继日志里读取数据，以为是日志文件损坏了，其实是名称不对了。

MySQL使用表空间文件来存储和管理数据。在MySQL中，表空间是指用于存储表和索引数据的文件集合。每个MySQL数据库可以包含一个或多个表空间，每个表空间可以包含一个或多个数据文件。数据文件的类型可以是InnoDB的独立表空间文件（.ibd），或者MyISAM的表文件（.MYD和.MYI）。在InnoDB存储引擎中，每个InnoDB表都有一个独立的表空间文件。这种表空间文件包含了表的数据和索引信息。

mysql可使用 into outfile 参数把表中数据导出到csv，例如可用以下命令把user表的数据导出到user.csv执行后，user表的数据会导出到/tmp/user.csv。参数说明：into outfile ‘导出的目录和文件名’指定导出的目录和文件名fields terminated by ‘字段间分隔符’定义字段间的分隔符optionally enclosed by ‘字段包围符’定义包围字段的字符（数值型字段无效）

01、从5.1.26开始，默认MySQL不启用federated存储引擎，所以需要在my.cnf中加入federated选项02、或是在命令行用–federated选项启动mysqld。

Mysql日志包括二进欧制日志，错误日志，通用查询日志和慢查询日志，redo log和undo log还有relay log等类型，以下实验内容如何启动 查看删除各类日志，以及如何使用二进制日志恢复数据库。

上面只是展示了对不同引擎来讲加的参数只是为了让数据保持一致性，但在备份中业务并没有停止，时刻可能有新的数据进行写入，为了让我们知道备份时是备份了哪些数据，或者截止到那个指针（二进制日志），我们可以再加入 --master-data参数，备份好的sql文件就会记录从备份截至到哪个指针，指针之后的数据更新我们可以通过二进制日志进行恢复。②、导出单个库：加--lock-tables参数，这会在备份开始的时候锁该库的所有表，其他session可以读但不能更新该库的所有表，该库的数据一致；

当主库发生故障宕机后，binlog其实已经都复制到从库并写入成relay log了。当然了，为避免误操作，建议先备份relay log。之后，从库就会继续应用relay log，待到全部应用完毕后，完成必要的数据校验，即可提成成为新的主库，对外提供服务了。TA想问：在这样的场景下，还有办法让B库尽快跑完这7200秒延迟数据吗，或者正确的办法是什么呢？# 关闭SLAVE服务，修改MASTER_DELAY，再启动SLAVE服务。事实上，只要正确理解，一键命令就搞定了。# 主库宕机后，查看SLAVE状态。

undo日志用于记录事务开始前的状态，用于事务失败时的回滚操作；例如某一事务的事务序号为T1，其对数据X进行修改，设X的原值是5，修改后的值为15，那么Undo日志为，Redo日志为。因为data buffer中的数据会在合适的时间 由存储引擎写入到data file，如果在写入之前，数据库宕机了，根据落盘的redo日志，完全可以将事务更改的数据恢复。磁盘上的日志文件称为log file，是顺序追加的，性能非常高，注：磁盘的顺序写性能比内存的写性能差不了多少。

redo log又称重做日志文件，用于记录事务操作的变化，记录的是数据修改之后的值，不管事务是否提交都会记录下来。在实例和介质失败（media failure）时，redo log文件就能派上用场，如数据库掉电，InnoDB存储引擎会使用redo log恢复到掉电前的时刻，以此来保证数据的完整性。1.1 redo日志文件名每个InnoDB存储引擎至少有1个重做日志文件组（group），每个文件组至少有2个重做日志文件，如默认的ib_logfile0和ib_logfile1。

使用mysqldump --all--databases的备份进行恢复。

mysql数据库中二进制日志文件用来记录所有用户对数据库操作，当数据库发生意外，可以通过查询此文件，查询在一定时间内用户的所做操作，结合数据库备份可再现用户操作，使数据库恢复。

软件概述 相较于rhel6/centos6 下的HA配置，rhel7下使用pcs 取代了原先的ccs和luci ，本文就结合pcs+pacemaker+corosyn+oracle做一个oracle的HA配置，并迁移数据共享平台数据库。使用corosync作为集群消息事务层（Massage Layer），pacemaker作为集群资源管理器（Cluster Resource Managem...