需求描述: 今天在研究mysql数据库的备份和恢复,用到了flush logs这个SQL语句. 所以,在此进行测试,并且记录该SQL语句的作用. 概念描述: 在mysql数据库,如果数据库启动的时候,启用了log-bin选项,那么, 所有对于数据库的修改都会记录在binary log中,binary log可以用于数据库的恢复(基于时间点的恢复) 操作过程: 1.查看my.cnf中配置的log-bin参数 [mysql@redhat6 ~]$ grep "log-bin" /etc/m

flush logs时做的操作:  对于一般查询日志和慢日志,先关闭文件再打开  对于binlog,关闭当前的,开始用下一个新的  用错误日志文件的话,先关闭再打开flush logs可以对一般查询日志,慢日志,错误日志 进行改名备份后重新生成文件(还是原来的名字)

FLUSH语法 FLUSH [LOCAL | NO_WRITE_TO_BINLOG] flush_option [, flush_option] ... 如果您想要清除MySQL使用的部分内部缓存,您应该使用FLUSH语句.要执行FLUSH,您必须拥有RELOAD权限. flush_option HOSTS 用于清空主机缓存表.如果有的主机更改了IP号或如果您得到了错误信息Host host_name is blocked,则您应该刷新主机表.当在连接到MySQL服务器时,如果对于一个给定的主机

五一前,一个DBA同事反馈,在日常环境中删除一个大的slow log文件(假设文件大小10G以上吧),然后在MySQL中执行flush slow logs,会发现mysqld hang住. 今天尝试着重现了此问题,这里简要分析下原因. 重现步骤: 1. 构造slow log (将long_query_time设成了0): 2. 观察删rm slow log瞬间,tps/qps变化: 3. 观察执行flush slow logs瞬间,tps/qps变化: 4. 记录flush slow logs执

日志记录存储方式 #日志记录存储方式 mysql> show variables like 'log_output'; mysql> set global log_output='FILE,TABLE'; 1.错误日志 #.错误日志 mysql> show variables like 'log_error'; +---------------+----------------------------------+ | Variable_name | Value | +---------

情景 MySQL数据库主从复制在默认情况下从库的relay logs会在SQL线程执行完毕后被自动删除.但是:在relay_log_purge = 0和MHA集群下,不会被自动删除,需要手动删除.如何安全的删除relay logs就比较关键了! 主要有两种方式: 方式一: 通过MHA中自带的工具 purge_relay_logs 工具来删除. 步骤: 创建工作目录 目的为了提高性能,这个工作目录必须跟mysql在同一个磁盘分区 mkdir -p /data/mha_tmp purge relay

1. 如何修改Mysql的用户密码 mysql> update mysql.user set password=password('hello') where user='root'; mysql> flush privileges; 2. 关于分区数量的限制 Prior , the maximum possible . Beginning , this limit partitions. Regardless of the MySQL Server version, this maximum

0. 关键概念 关键概念 Concepts Function Topic 用于划分Message的逻辑概念,一个Topic可以分布在多个Broker上. Partition 是Kafka中横向扩展和一切并行化的基础,每个Topic都至少被切分为1个Partition. Offset 消息在Partition中的编号,编号顺序不跨Partition(在Partition内有序). Consumer 用于从Broker中取出/消费Message. Producer 用于往Broker中发送/生产Me

我的MYSQL学习心得(十五) 日志 我的MYSQL学习心得(一) 简单语法 我的MYSQL学习心得(二) 数据类型宽度 我的MYSQL学习心得(三) 查看字段长度 我的MYSQL学习心得(四) 数据类型 我的MYSQL学习心得(五) 运算符 我的MYSQL学习心得(六) 函数 我的MYSQL学习心得(七) 查询 我的MYSQL学习心得(八) 插入 更新 删除 我的MYSQL学习心得(九) 索引 我的MYSQL学习心得(十) 自定义存储过程和函数 我的MYSQL学习心得(十一) 视图 我的MYS

上文分析的二进制日志实际上是基于STATEMENT格式的,下面我们来看看基于ROW格式的二进制日志,毕竟,两者对应的binlog事件类型也不一样,同时,很多童鞋反映基于ROW格式的二进制日志无法查到原生的DML语句,关于这个问题,其实官方也给出了解决方案,下面,将一一揭晓. 首先,来几条测试数据 mysql> set binlog_format=row; Query OK, rows affected (0.00 sec) mysql> flush logs; Query OK, rows a

MySQL binlog记录的所有操作实际上都有对应的事件类型的,譬如STATEMENT格式中的DML操作对应的是QUERY_EVENT类型,ROW格式下的DML操作对应的是ROWS_EVENT类型. 首先,看看源码中定义的事件类型 源码位置:mysql-5.7.14/libbinlogevents/include/binlog_event.h enum Log_event_type { /** Every time you update this enum (when you add a ty

查看MySQL二进制文件中的内容有两种方式 1.  mysqlbinlog 2.  SHOW BINLOG EVENTS [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count] 下面来测试一下,在mysql中执行如下操作 mysql> flush logs; Query OK, rows affected (0.01 sec) mysql,'a'); Query OK, row affected (0.00 sec) mysql> use

MySQL的复制是基于binlog来实现的. 流程如下 涉及到三个线程,主库的DUMP线程,从库的IO线程和SQL线程. 1. 主库将所有操作都记录到binlog中.当复制开启时,主库的DUMP线程根据从库IO线程的请求将binlog中的内容发送到从库. 2. 从库的IO线程接受到主库DUMP线程发送的binlog事件后,将其写到本地的relay-log. 3. 从库的SQL线程重放relay-log中的事件. 实际上,在MySQL 4.0之前,复制只有两个线程,master和slave端各一个

Percona TokuDB Percona TokuDB 1.     TokuDB说明 2.     TokuDB安装 3.     使用TokuDB 3.1 快速插入和富索引 3.2 聚集secondary索引 3.3 在线索引创建 3.4 在线添加,删除,扩展,重命名列 3.5            压缩细节 3.6 修改表的压缩 3.7 无io读复制 3.8 事务和ACID兼容恢复 3.9 管理Log大小 3.10 恢复 3.11 关闭写缓存 3.12 进度跟踪 3.13 迁移到Tok

18 复制 18 复制 18.1 复制配置 18.1.1 基于Binary Log的数据库复制配置 18.1.2 配置基于Binary log的复制 18.1.2.1 设置复制master的配置 18.1.2.2 创建复制要用的用户 18.1.2.3 获取复制Binary Log坐标 18.1.2.4 选择同步数据快照的方法 18.1.2.5配置Slave 18.1.2.6 为复制环境增加一个slave 18.1.3 基于全局事务标示符的复制 18.1.3.1 GTID概述 18.1.3.2 使

注: .做主从复制的两台服务器server-id不能相同 .主从的字符集要一样,不然数据导入会报错 .开启db01的log-bin功能 [root@db01 mysql]# vim /etc/my.cnf log-bin=mysql-bin [root@db01 ~]# /etc/init.d/mysqld restart Shutting down MySQL. SUCCESS! Starting MySQL.. SUCCESS! .查看log_bin是否开启 mysql> show vari

案例: 线上有一数据库,需要每周全备一次,每天差备一次[安全起见还是差备吧,不要增备,不要吝啬磁盘哦,而且差备恢复还很快] 1.每周对数据库hellodb做完全备份 crontab任务计划: * * /bin/bash /work/dump-complete-hello.sh ===>每周周一凌晨1点10分执行全备脚本/work/dump-complete-hello.sh 全备脚本/work/dump-complete-hello.sh内容如下: #!/bin/bash # 全备文件存放位置

MYSQL MHA 简介: MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于 Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件.在MySQL故障切换过程中,MHA能做到在 0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用. 该软件由两部分组成:MHA

MySQL5.6 GTID新特性实践 GTID简介 搭建 实验一:如果slave所需要事务对应的GTID在master上已经被purge了 实验二:忽略purged的部分,强行同步 本文将简单介绍基于5.6 GTID的主从复制原理的搭建.并通过几个实验介绍相关故障的处理方式 GTID简介 什么是GTID GTID(Global Transaction ID)是对于一个已提交事务的编号,并且是一个全局唯一的编号. GTID实际上是由UUID+TID组成的.其中UUID是一个MySQL实例的唯一标识

前一段时间因为误操作删除了一张表的几条数据,弄得很尴尬,正好这周有空就折腾了下数据备份的知识,现把mysql的数据备份相关实践和心得总结如下: 一.使用mysqldump命令备份数据库: 备份整个数据库(包括表结构和数据),用法如下 mysqldump -h10.38.14.143 -uroot -prootroot  weixin > weixin.sql 其中 weixin 是数据库名,可以一次备份多个数据库 (用空格隔开),默认保存在当前目录下 这个wexin.sql文件里面主要由四部分组