8.0MGR Subquery returns more than 1 row bug

这是一个Percona Server8.0.22下使用MGR+ProxySQL时遇到的bug

使用mydumper备份mgr时发现ProxySQL报错了

1
2
3
4
5
6
7
# cat proxysql.log | grep -i subquery
2021-04-28 15:14:22 MySQL_HostGroups_Manager.cpp:3875:update_group_replication_set_offline(): [WARNING] Group Replication: setting host 172.16.23.224:3309 offline because: Subquery returns more than 1 row
2021-04-28 15:14:22 MySQL_Monitor.cpp:1472:monitor_group_replication_thread(): [ERROR] Got error. mmsd 0x7fd62cee3540 , MYSQL 0x7fd62b804600 , FD 39 : Subquery returns more than 1 row
2021-04-28 15:14:27 MySQL_Monitor.cpp:1472:monitor_group_replication_thread(): [ERROR] Got error. mmsd 0x7fd62cee1440 , MYSQL 0x7fd62b800000 , FD 41 : Subquery returns more than 1 row
2021-04-28 15:17:37 MySQL_HostGroups_Manager.cpp:3875:update_group_replication_set_offline(): [WARNING] Group Replication: setting host 172.16.23.151:3309 offline because: Subquery returns more than 1 row
2021-04-28 15:17:37 MySQL_Monitor.cpp:1472:monitor_group_replication_thread(): [ERROR] Got error. mmsd 0x7fd62cee78c0 , MYSQL 0x7fd62bc06400 , FD 51 : Subquery returns more than 1 row
2021-04-28 15:17:42 MySQL_Monitor.cpp:1472:monitor_group_replication_thread(): [ERROR] Got error. mmsd 0x7fd62cee0300 , MYSQL 0x7fd62bc00000 , FD 40 : Subquery returns more than 1 row

skeema简单使用

简介

Skeema is a tool for managing MySQL tables and schema changes in a declarative fashion using pure SQL. It provides a CLI tool allowing you to:

  • Export CREATE TABLE statements to the filesystem, for tracking in a repo (git, hg, svn, etc)
  • Diff changes in the schema repo against live DBs to automatically generate DDL
  • Manage multiple environments (e.g. dev, staging, prod) and keep them in sync with ease
  • Configure use of online schema change tools, such as pt-online-schema-change, for performing ALTERs
  • Convert non-online migrations from frameworks like Rails or Django into online schema changes in production

Skeema supports a pull-request-based workflow for schema change submission, review, and execution. This permits your team to manage schema changes in exactly the same way as you manage code changes. Our new companion Cloud Linter for GitHub repos provides automatic linting of schema change commits and pull requests.

我这的需求是同步生产环境表结构到演练环境, 以下是针对我这个场景的具体使用方法

权限

skeema需要的用户权限具体见https://www.skeema.io/docs/requirements/

这里说一下重点, skeema diff时会在目标环境创建一个_skeema_tmp临时数据库, 然后会删除这个库

DorisDB vs ClickHouse SSB对比测试

DorisDB vs ClickHouse SSB对比测试

TL;DR

  1. 进行本次测试时对DorisDB了解甚微
  2. 本次测试由于服务器资源有限, 没有严格遵循单一变量原则进行测试
  3. 本次测试有一定参考意义

数据导入速度

  • ClickHouse: 3500s
  • DorisDB: 5160s

数据压缩情况(通过磁盘占用空间比较)

  • ClickHouse: 85.2G
  • DorisDB: 132G

查询速度

单表查询

单表

DorisDB1 DorisDB2 ClickHouse1 ClickHouse2
Q1.1 350 290 226 195
Q1.2 270 190 34 63
Q1.3 310 240 43 22
Q2.1 410 370 1,723 1,791
Q2.2 780 720 1,463 1,470
Q2.3 340 280 659 1,337
Q3.1 1,560 860 3,488 1,254
Q3.2 1,080 790 1,272 966
Q3.3 250 290 979 889
Q3.4 230 260 36 20
Q4.1 870 720 5,067 2,791
Q4.2 720 490 804 752
Q4.3 510 380 561 482

多表查询

多表

DorisDB1 DorisDB2 ClickHouse1 ClickHouse2
Q1.1 450 490 1,496 1,424
Q1.2 410 450 1,366 659
Q1.3 510 340 678 1,377
Q2.1 1,560 1,600 4,360 2,667
Q2.2 1,690 1,060 4,498 1,554
Q2.3 780 1,150 2,569 2,577
Q3.1 3,480 3,700 10,190 12,960
Q3.2 1,320 1,850 5,926 5,743
Q3.3 1,030 1,040 3,445 3,300
Q3.4 1,330 1,170 3,455 3,330
Q4.1 3,480 3,750 15,560 9,494
Q4.2 2,830 3,170 16,109 18,048
Q4.3 1,560 2,140 15,685 14,838

MHA Failover测试

TL;DR

用例 ping_type=CONNECT ping_type=INSERT
master too many connection 不会触发failover 不会触发failover
master hang 不会触发failover 会触发failover且成功
仅manager无法连通master 不会触发failover 不会触发failover
manager无法连通master, 且无法ssh slave1 不会触发failover 不会触发failover
manager无法连通master, 且无法ssh slave1和slave2 不会触发failover 不会触发failover
manager无法连通master, ssh到slave1后无法连通master 不会触发failover 不会触发failover
manager无法连通master, ssh到slave1和slave2后均无法连通master 会触发failover且成功 会触发failover且成功(长连接断开后才会)
master宕机前slave1也宕机了 会触发failover, 但failover失败 会触发failover, 但failover失败
master挂了, 在此之前slave-1 io_thread stop了 会failover且成功 会failover且成功
master挂了, 在此之前slave-1 io_thread error了 会failover且成功 会failover且成功
master挂了, 在此之前slave-1 sql_thread stop了 会failover且成功 会failover且成功
master挂了, 在此之前slave-1 sql_thread error了 会触发failover, 但failover失败 会触发failover, 但failover失败

使用Canal + ClickHouse实时分析MySQL事务信息

使用Canal + ClickHouse实时分析MySQL事务信息

作为DBA, 有时候我们会希望能够了解线上核心库更具体的”样貌”, 如:

  • 这个库主要的DML类型是什么?
  • 这个库的事务大小, 执行时间, 影响行数大概是什么样的?

以上信息也许没什么价值, 但大事务对复制的影响不用多说, 并且当我们希望升级当前主从架构到MGR/PXC等高可用方案的场景时以上信息就比较重要了(毕竟用数据说话更有力度).

大事务对MGR和PXC都是不友好的, 尤其是MGR(起码在5.7版本)严重时会导致整个集群hang死

在Galera 4.0中新特性Streaming Replication对大事务有了更好的支持

当然, 有人可能会说, 通过分析binlog就可以完成这样的工作, 最简单的方法写个shell脚本就可以, 比如这篇文章中介绍的方法Identifying Useful Info from MySQL Row-Based Binary Logs(这篇文章介绍的方法比较简单, 分析速度也较慢, 可以试试analysis_binlog). 当然还有很多其他工具, 比如infobin.

但个人认为上面的方法从某种角度来看还是比较麻烦, 而且现在ClickHouse越来越流行, 使用ClickHouse去完成这个工作也能帮助我们更好的学习ClickHouse

先看一下最终的成果

overview

类MHA高可用方案存在的问题

类MHA高可用方案存在的问题

MHA Generaly Available since 2011?

MHA在当时主要解决两个问题:

  1. 自动的数据补偿
  2. 自动的主从切换

还有两个重要的背景需要交代:

  1. 当时主要使用异步复制
  2. 当时还没有ProxySQL

所以当时基本使用MHA+VIP作为MySQL复制集的高可用方案.

不谈vip的脑裂问题, 这种架构的一个关键点在于, MHA是作为一个外部机制检测MySQL复制集状态, 并变更复制集拓扑, 变更后漂移vip, 也就是说MHA既控制了集群拓扑的变化, 又控制了app的访问路径(写通过vip)


Powered by Hexo and Hexo-theme-hiker

Copyright © 2013 - 2021 Fan() All Rights Reserved.

访客数 : | 访问量 :