公司有使用默认安装目录的ProxySQL跑业务. 在升级2.0.8 至 2.0.12的时候发现卸载2.0.8后这些使用默认方式安装的ProxySQL实例就会被关闭.
原因是rpm包安装和卸载前后执行了一些动作
1 | [root@bj1-mysql-manager-prod-01 tmp]# rpm --scripts -qp /tmp/proxysql-2.0.8-1-centos7.x86_64.rpm |
公司有使用默认安装目录的ProxySQL跑业务. 在升级2.0.8 至 2.0.12的时候发现卸载2.0.8后这些使用默认方式安装的ProxySQL实例就会被关闭.
原因是rpm包安装和卸载前后执行了一些动作
1 | [root@bj1-mysql-manager-prod-01 tmp]# rpm --scripts -qp /tmp/proxysql-2.0.8-1-centos7.x86_64.rpm |
1 | root* from t3; 17:46:56 [fanboshi]> select |
2020.05.18 16:12 收到报警
登录主机, 查看error log( 开启了innodb_print_all_deadlocks参数)
1 | *** (1) TRANSACTION: |
简单解释一下上面的死锁日志
和同事探讨一个问题, MGR单主做不做冲突检测.
我理解是不需要做的, 因为已经明确只有主节点才能写入数据了, 那么必然不会有数据冲突的可能, 没必要再做冲突检测浪费性能了.
看了下官方文档
1 | In single-primary mode, Group Replication enforces that only a single server writes to the group, so compared to multi-primary mode, consistency checking can be less strict and DDL statements do not need to be handled with any extra care |
Percona XtraDB Cluster 8.0附带了一个升级的Galera 4.0库, 它提供了一个新特性—Streaming Replication.让我们回顾一下它是什么, 什么时候可能有用
以前版本的Percona XtraDB集群和Galera 3.x在处理大事务方面有限制.
让我们看一下sysbench-tpcc工作负载下的性能, 与此同时, 我们对一个表执行了一个大的更新语句, 该更新甚至与主工作负载中的表都不相关.
我正在测试最新的Percona XtraDB Cluster 8.0 (PXC)版本, 其中包含了Galera 4插件, 我想分享一下到目前为止我在Streaming Replication特性方面的经验和想法,
在Galera 4中, 大型事务可以分割成更小的片段, 甚至在提交之前, 这些片段就已经被复制到其他节点, 并且已经开始了认证(certification)和应用(apply)过程.
手册描述了所有的优点和缺点, 但是让我们看看它是如何工作的. 我已经创建了一个包含1千万行的表, 我将在这个表上运行一些大的update语句,
首先, 我在不使用Streaming Replication的情况下运行更新, 由于默认情况下Streaming Replication是disabled, 所以我们不需要做任何事情, 只需运行更新即可. 在node1
上, 我记录更新之前和之后的时间, 在node2
上, 我每秒钟运行一次select, 以查看这个更新在其他节点上实际提交的时间.