本文根据DBAplus社群第83期线上分享整理而成，文末还有书送哦~ 贺春 惠普金融MySQL专家
感谢大家参与我今天的分享，希望今天大家能有所收获，并能把这项新技术玩起来先。在介绍MaxScale Binlog Server前，我先把我们这边的情况大致阐述下。 公司核心数据库在我15年7月入职第二周，从最原始的MySQL5.5.30社区版全部升级到MariaDB10.0.21企业版，随后面的机房迁移，版本再次升级为MariaDB10.0.26企业版。 那为啥选用这个版本？对于金融p2p公司来说，换数据库就意味着风险，因为库里都是钱，大多都采用保守的方法。而我之前来机锋网(安卓市场)的时候，就已经使用MariaDB10.0.17社区版跑了一年半，当时PV是2000万，数据库总共8台，一主7从，前端PHP做的读写分离，后端用HaProxy做DB的负载均衡，QPS每秒在1500020000左右，TPS每秒在300500左右，至今数据库稳定的跑着，未出现一次故障。 有了成功经验，对我换金融数据库版本就有了足够的信心保障，因为金融类的公司并发都远远低于传统互联网公司，事实证明，目前业务稳定跑了1年4个月。 好，再回过头来说下，对接大数据分析部门遇到的痛点以及我们为何上了MaxScale binlog server。我们给大数据那边，是提供一台单独的从库，注意是二级从库，他们通过阿里巴巴开源的canal连接到Slave从库上，然后Slave推送binlog给canal，接收完binlog再推送给kafka消息队列，最终存入HBase里，业务部门通过Hive直接写SQL的方式来实现业务的实时分析，大体的架构就是这样。 注意刚才我提到的二级从库，因我们目前线上的从库一台是Standby仅提供故障切换用的，另一台是提供业务读写分离用的。所以我在从库的下面接了一台二级从库，提供对接canal使用。因爬虫的抓取insert写入量大，从库的SQL_THREAD线程只有commit后才会记本地的binlog里，然后再推送给二级从库。这个时候，由于我们是实时分析，延迟5秒也无法接受，被业务方喷了回来，这TMD就尴尬了。 下面进入正题，本次分享将围绕以下三部分展开：
生产环境中，大多采用的是一主多从架构，即主库推送三份binlog日志到S1/S2/S3从库上。然而，在这个架构中存在了一些问题，当主库带了过多的从库，势必会增加主库的网络IO压力。而链式复制（多级复制）通常为M---S1---S2/S3，S1是S2/S3的主，主库只需要给S1推送binlog日志即可，S1再推送binlog日志给S2/S3，在这种场景下，缓解了主库的网络IO压力，但其缺点是：S2/S3得到最新的数据，需要再经过一层的复制才到达，期间的延迟比一主多从架构要大。 业界通常的做法是在二级主库上（S1）选择黑洞引擎（BLACKHOLE）降低链式复制（多级复制）的延迟问题。写入BLACKHOLE表的数据并不会记录到磁盘上（本身不保存数据），永远为一个空表，因不会将同步的数据写回到磁盘上，速度远远比INNODB引擎快，它仅仅接收主库推送过来的binlog日志。 MaxScale对Binlog的收集采用了一个更简单的方法，其工作在主库和从库之间。它不会对binlog进行任何回放操作，自身不保存数据。它把从主库接收的binlog放入本地缓存，并将其推送给从库。这意味着从库总是获得最新的binlog事件，它们与主库写入的binlog事件具有一对一的关系。其延迟主要是添加多台MaxScale带来的额外的网络传输。 充当主库代理的MaxScale具有与主库完全相同的binlog事件，这意味着从库可以在任意一个MaxScale节点之间CHANGE MSATER TO ，无需执行任何特殊处理。MariaDB MaxScale Binlog Server接收器，工作流程类似黑洞引擎（BLACKHOLE）。
使用MaxScale作为binlog代理与使用MaxScale作为应用读写分离的代理非常相似。 基础架构为：M---MaxScale Binlog---S1/S2：
MaxScale binlog配置 # cat /etc/maxscale.cnf [maxscale] threads=24 ##根据CPU核数设置 [Replication] type=service router=binlogrouter user=repl passwd=repl # 使用主库上的repl复制账号 # 权限： # GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO 'repl'@'%' IDENTIFIED BY 'repl'; router_options=server_id=1311,heartbeat=30,binlogdir=/data/binlog,transaction_safety=1,mariadb10-compatibility=1,send_slave_heartbeat=1 # server_id设置maxscale的，记得不能与主和从库重复，要唯一 # heartbeat=30秒，意思为当maxscale在30秒内没有接收到主库推送的binlog日志，发送心跳检查 # binlogdir设置接收binlog的存放路径，目录属性chown -R maxscale.maxscale /data/binlog # transaction_safety=1此参数用于启用binlog日志中的不完整事务检测。 当MariaDB MaxScale启动时，如果当前binlog文件已损坏或找到不完整的事务，则可能会出现错误消息。 在正常工作期间，binlog事件不会分配到从库，直到事务已经提交。 默认值为off，设置transaction_safety = on以启用不完全事务检测。 # send_slave_heartbeat=1开启心跳检查 [Replication Listener] type=listener service=Replication protocol=MySQLClient port=5308 # 后端的从库CHANGE MASTER TO这个端口，默认5308 [CLI] type=service router=cli [CLI Listener] type=listener service=CLI protocol=maxscaled port=6603 # MaxScale后台管理端口 启动： # /etc/init.d/maxscale start 使用： # 连接到MaxScale binlog Server后台 # mysql -h192.168.17.131 -urepl -prepl -P5308 # 就像平常建立主从复制一样，执行下面的命令 MySQL [(none)] |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
