BLACKHOLE的BINLOG服务实现

BlackHole ：黑洞引擎，写入的任何数据都会消失，用于记录binlog做复制的中继存储！

是否支持BLACKHOLE引擎，通过查看SHOW ENGINES进行查看。

BlackHole的用途:

  • 用于binlog的备份

线上MySQL的binlog一般会保留3-5天，但是对比较重要的业务，binlog可能需要保留一个月甚至半年。线上服务器可没有这么大的空间，最多保留10天就会被purge掉。此时blackhole就有了用武之地。blackhole从库+xtrabackup的定期热备+binlogflashback，可以让你的数据库恢复到任意时刻。

  • 充当binlog     API，为其他程序提供数据源

可作为其他程序提供数据源的接口，如在BLACKHOLE获取BINLOG分析把对应的数据插入到redis中。这种情况下blackhole从库充当了天然的binlog API。

  • 跨IDC部署场景下，节省带宽

如果一个主库拖着20个从库，主库可能不堪重负，此时可以考虑给主库增加一个blackhole从库作为中继，虽然这种方案有诸多不靠谱的地方，但是如果这个主库在北京，20个从库在广州，这种方案就有意义了：在广州增加一个blackhole，让blackhole下挂20个从库，此时就可节省大量北京到广州的带宽。

。。。。。。

应用场景：

主服务器的操作写入二进制日志,伪mysqld进程作为从服务器，在伪mysqld进程上配置replicate-do和replicate-ignore规则，并且写一个新的，被过滤的二进制日志。这个已过滤日志被提供给其他真正的从服务器。因为伪进程不存储任何数据，只消耗很小的额外的mysqld进程资源。这个类型的建立可以用额外复制从服务器来重复。

当然如果配置一主多从的话，多个从服务器会在主服务器上分别开启自己相对应的线程，执行binlog dump命令而且多个此类进程并不是共享的。为了避免因多个从服务器同时请求同样的事件而导致主机资源耗尽，可以单独建立一个伪的从服务器或者叫分发服务器：

测试环境：


SERVER
IP
ROLE
Data_format

MASTER
192.168.15.2
主库
RBR

BLACKHOLE
192.168.15.13
分发服务器
RBR

SLAVE
192.168.15.104
分发服务器的从库
RBR

搭建过程：

1、在master 添加一个帐号作为BLACKHOLE同步BINLOG使用

2、在BLACKHOLET添加一个帐号作为SLAVE同步BINLOG使用

3、可以指定需要同步的库表或者忽略某些表（replicate-do和replicate-ignore规则）

4、新环境搭建主从过程：

1、实例启动后对master执行show masterstatus 获取到的BINLOG FIEL 和POS作为BLACKHOLE的连接使用

2、实例启动后对BLACKHOLE执行show masterstatus 获取到的BINLOG FIEL 和POS作为SLAVE的连接使用

3、在主库添加DDL的时候，不要再次指定ENGINE，根据实例配置走即可，若再次指定引擎，到BLACKHOLE，同步的BINLOG的中的DDL语句没法使用BLACKHOLE引擎，不符合黑洞引擎，写入的任何数据都会消失这一说法，虽然也能同步，感觉为线性级联方式同步

注意：在BLACKHOLE需要开启log_slave_updates和BINLOG服务器才能作为SLAVE的同步数据源

5、对于旧环境添加BLACKHOLE服务器：

1、如果在DDL指定ENGINE话，到BLACKHOLE服务器存储的表和主库一致，不符合黑洞引擎，写入的任何数据都会消失这一说法

2、在导入旧数据的时候，需要修改导入数据表的引擎为BLACKHOLE

3、在BLACKHOLE连接着SLAVE时候，需要把SLAVE引擎改为和主库一致

4、备份的数据不需要DDL语句，只要数据，在主库导入即可，后期写入的数据，即可通过BLACKHOLE同步快速同步到不同的SLAVE上

最终结果图：

主库上的DDL：

BLACKHOLE的DDL:

SLAVE上的DDL

实验现象：

在测试1000W数据写入的时候，BLACKHOLE同步MASTER的速度很快，

SLAVE的IO线程同步BLACKHOLE的BINLOG日志速度也快，但SLAVE的SQL_THREAD线程的速度跟不上（MySQL版本为5.6，或用5.7的多个线程可提高效率）.数据获取多次展示：

master binlog event File:mysql-bin.000006

Position:777525175

blackhole master event File:mysql-bin.000007

Position:129152031

BLACKHOLE SYNE:

Master_Log_File:mysql-bin.000006

Read_Master_Log_Pos: 776113906

Relay_Log_File:relay-log.000010

Relay_Log_Pos: 458099520

Exec_Master_Log_Pos: 458099357

SLAVE SYNE:

Master_Log_File:mysql-bin.000007

Read_Master_Log_Pos: 129152031

Relay_Log_File:relay-log.000017

Relay_Log_Pos: 129007567

Exec_Master_Log_Pos: 129007404

master binlog event File:mysql-bin.000006

Position:844042095

blackhole master event File:mysql-bin.000007

Position:152147724

BLACKHOLE SYNE:

Master_Log_File:mysql-bin.000006

Read_Master_Log_Pos: 843124455

Relay_Log_File:relay-log.000010

Relay_Log_Pos: 481091238

Exec_Master_Log_Pos: 481091075

SLAVE SYNE:

Master_Log_File:mysql-bin.000007

Read_Master_Log_Pos: 152147724

Relay_Log_File:relay-log.000017

Relay_Log_Pos: 152147887

Exec_Master_Log_Pos: 152147724

master binlog event File:mysql-bin.000006

Position:936876579

blackhole master event File:mysql-bin.000007

Position:199585380

BLACKHOLE SYNE:

Master_Log_File:mysql-bin.000006

Read_Master_Log_Pos: 936441390

Relay_Log_File:relay-log.000010

Relay_Log_Pos: 528520694

Exec_Master_Log_Pos: 528520531

SLAVE SYNE:

Master_Log_File: mysql-bin.000007

Read_Master_Log_Pos: 199585380

Relay_Log_File:relay-log.000017

Relay_Log_Pos: 199585543

Exec_Master_Log_Pos: 199585380

master binlog event File:mysql-bin.000007

Position:131443338

blackhole master event File:mysql-bin.000007

Position:444149637

BLACKHOLE SYNE:

Master_Log_File:mysql-bin.000007

Read_Master_Log_Pos: 131044087

Relay_Log_File:relay-log.000010

Relay_Log_Pos: 773042676

Exec_Master_Log_Pos: 773042513

SLAVE SYNE:

Master_Log_File:mysql-bin.000007

Read_Master_Log_Pos: 444020772

Relay_Log_File: relay-log.000017

Relay_Log_Pos: 384708103

Exec_Master_Log_Pos: 384707940

master binlog event File:mysql-bin.000007

Position:286312080

blackhole master event File:mysql-bin.000007

Position:679313139

BLACKHOLE SYNE:

Master_Log_File:mysql-bin.000007

Read_Master_Log_Pos: 286167931

Relay_Log_File:relay-log.000010

Relay_Log_Pos: 1008165528

Exec_Master_Log_Pos: 1008165365

SLAVE SYNE:

Master_Log_File:mysql-bin.000007

Read_Master_Log_Pos: 679191406

Relay_Log_File:relay-log.000017

Relay_Log_Pos: 537578842

Exec_Master_Log_Pos: 537578679

master binlog event File:mysql-bin.000008

Position:249583172

blackhole master event File:mysql-bin.000008

Position:469748616

BLACKHOLE SYNE:

Master_Log_File:mysql-bin.000008

Read_Master_Log_Pos: 249368601

Relay_Log_File:relay-log.000013

Relay_Log_Pos: 798058721

Exec_Master_Log_Pos: 798058558

SLAVE SYNE:

Master_Log_File:mysql-bin.000008

Read_Master_Log_Pos: 469654916

Relay_Log_File:relay-log.000020

Relay_Log_Pos: 333076264

Exec_Master_Log_Pos: 333076101

由此看出，在1000W 写入的时候，MASTER与BLACKHOLE的IO_THREAD延迟不是很大，取决于BLACKHOLE的SQL_THREAD。需要注意的是，在主库的添加DDL不能指定引擎名字，让数据库实例自行为DDL添加引擎即可，否则在BLACKHOLE中也会和M一样的引擎名字，这样的结果是否能够一样的提高效率，有待验证。

时间： 2024-10-11 11:17:08

BLACKHOLE的BINLOG服务实现的相关文章

企业生产MySQL主从同步配置

MySQL主从同步配置 前言:测试环境 一台mysql多个实例 主机IP地址 10.0.0.52 Master   3306 Salve    3307 一.主库要开启binlog服务 1. 1修改配置文件3306/my.cnf [[email protected] ~]# egrep "log-bin|server-id" /data/3306/my.cnf   log-bin = /data/3306/mysql-bin server-id = 1 1. 2查看主库有没有开启bin

MySQL数据库的灾难备份与恢复

http://xiaorenwutest.blog.51cto.com            MySQL数据库的灾难恢复与备份 数据库对于公司来说是重中之重:记录着公司的庞大数据,关系到公司的财产,以及客户的资料,如果一旦丢失将会为公司造成无法估量的损失. 但是如果做好备份工作可以避免这种情况的发生:所以说作为一名合格的DBA人员来说掌握数据库的备份和回复是必不可少的技能.另外在工作当中公司也会进行一些计划:比如说数据库的灾难与恢复的测试.今天为大家带来的就是关于MySQL的备份与恢复. 一:我

HMA基础架构规划和实施

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

mysql-5.7.10-winx64 MySQL服务无法启动，服务没有报告任何错误的解决办法

总结报错原因:在my.init文件下新增data目录(datadir = F:\mysqldata ) 最新解压版本的mysql 解压安装的时候报错D:\mysql\mysql-5.7.10-winx64\bin>net start mysqlMySQL 服务正在启动 ....MySQL 服务无法启动. 服务没有报告任何错误. 请键入 NET HELPMSG 3534 以获得更多的帮助. mysql下面是没有data文件夹的,此文件夹不需要自己建 D:\mysql\mysql-5.7.10-wi

mysql-5.7.9-winx64 MySQL服务无法启动，服务没有报告任何错误的解决办法 转自【IT精英团】：http://www.itnpc.com/news/web/144832818227054.html

最新解压版本的mysql 解压安装的时候报错D:\mysql-5.7.9-winx64\bin>net start mysqlMySQL 服务正在启动 .MySQL 服务无法启动.服务没有报告任何错误.  mysql下面是没有data文件夹的,此文件夹不需要自己建. D:\mysql-5.7.9-winx64\bin>mysqld --console2015-11-23T14:46:03.711082Z 0 [Warning] TIMESTAMP with implicit DEFAULT v

mysql-5.7.9-winx64 MySQL服务无法启动，服务没有报告任何错误 的解决办法

mysql-5.7.9-winx64 MySQL服务无法启动,服务没有报告任何错误 最新解压版本的mysql 解压安装的时候报错 D:\mysql-5.7.9-winx64\bin>net start mysql MySQL 服务正在启动 . MySQL 服务无法启动. 服务没有报告任何错误. mysql下面是没有data文件夹的,此文件夹不需要自己建. D:\mysql-5.7.9-winx64\bin>mysqld --console 2015-11-23T14:46:03.711082Z

修改CentOS6.5主机名引起MySQL5.6.35服务问题

本来是心血来潮修改CentOS6.5的主机名 /****** 修改CentOS6.5默认主机名 ******/ 1.备份系统网络配置文件 [[email protected] ~]# cp /etc/sysconfig/network /etc/sysconfig/network.`date +%Y%m%d.%H%M%S` 2.备份系统网络配置文件 [[email protected] ~]# vim /etc/sysconfig/network 修改HOSTNAME为我们想要的名字VMUest

[MySQL Reference Manual] 5 MySQL 服务管理

5. MySQL 服务管理 5. MySQL 服务管理... 1 5.1 The Mysql Server1 5.2 Mysql 服务日志... 1 5.2.1 选择General query log和slow query log 的输出方式... 1 5.2.2 Error Log. 1 5.2.3 General Query Log. 1 5.2.4 Binary Log. 1 5.2.4.1 binary log日志记录方式... 1 5.2.4.2设置binary log格式... 1

MySQL binlog日志恢复数据

我们了解了MySQL 的 binlog 日志的开启方式以及 binlog 日志的一些原理和常用操作,我们知道,binlog 有两大作用,一个是使用 binlog 恢复数据,另一个就是用来做主从复制.本篇笔记就是来记录如何使用 binlog 日志来做数据恢复.当然了,使用 binlog 日志所恢复的数据只能是部分数据,并不能够使用 binlog 日志来做数据库的备份,如果想要做数据库备份,依然要使用我们传统的备份方法,而 binlog 可以作为增量备份. 视频链接:http://www.ronco