公司有使用默认安装目录的ProxySQL跑业务. 在升级2.0.8 至 2.0.12的时候发现卸载2.0.8后这些使用默认方式安装的ProxySQL实例就会被关闭.

原因是rpm包安装和卸载前后执行了一些动作

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

[root@bj1-mysql-manager-prod-01 tmp]# rpm --scripts -qp  /tmp/proxysql-2.0.8-1-centos7.x86_64.rpm 
preinstall scriptlet (using /bin/sh):
# Cleanup artifacts
if [ -f /var/lib/proxysql/PROXYSQL_UPGRADE ]; then 
    rm -fr /var/lib/proxysql/PROXYSQL_UPGRADE
fi
postinstall scriptlet (using /bin/sh):
# Create relevant user, directories and configuration files
if [ ! -d /var/run/proxysql ]; then /bin/mkdir /var/run/proxysql ; fi
if [ ! -d /var/lib/proxysql ]; then /bin/mkdir /var/lib/proxysql ; fi
if ! id -u proxysql > /dev/null 2>&1; then useradd -r -U -s /bin/false -d /var/lib/proxysql -c "ProxySQL Server" proxysql; fi
/bin/chown -R proxysql: /var/lib/proxysql /var/run/proxysql
/bin/chown root:proxysql /etc/proxysql.cnf
/bin/chmod 640 /etc/proxysql.cnf
# Configure systemd appropriately.
/bin/systemctl daemon-reload
/bin/systemctl enable proxysql.service
# Notify that a package update is in progress in order to start service.
if [ $1 -eq 2 ]; then /bin/touch /var/lib/proxysql/PROXYSQL_UPGRADE ; fi
preuninstall scriptlet (using /bin/sh):
# When uninstalling always try stop the service, ignore failures
/bin/systemctl stop proxysql || true
postuninstall scriptlet (using /bin/sh):
if [ $1 -eq 0 ]; then
    # This is a pure uninstall, systemd unit file removed
    # only daemon-reload is needed.
    /bin/systemctl daemon-reload
else
    # This is an upgrade, ProxySQL should be started. This
    # logic works for packages newer than 2.0.7 and ensures
    # a faster restart time.
    /bin/systemctl start proxysql.service
    /bin/rm -fr /var/lib/proxysql/PROXYSQL_UPGRADE
fi
posttrans scriptlet (using /bin/sh):
if [ -f /var/lib/proxysql/PROXYSQL_UPGRADE ]; then
    # This is a safeguard to start the service after an update
    # which supports legacy "preun" / "postun" logic and will
    # only execute for packages before 2.0.7.
    /bin/systemctl start proxysql.service
    /bin/rm -fr /var/lib/proxysql/PROXYSQL_UPGRADE
fi

通过max行转列不是动态的, 你还是要知道所有列名才可以

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

root@localhost 17:46:56 [fanboshi]> select * from t3;
+----+---------+------+-----------+
| id | title   | env  | progress  |
+----+---------+------+-----------+
|  1 | 工单1   |    1 | 完成      |
|  2 | 工单1   |    2 | 完成      |
|  3 | 工单1   |    3 | 待审核    |
|  4 | 工单2   |    1 | 待审核    |
+----+---------+------+-----------+
4 rows in set (0.00 sec)

root@localhost 17:48:20 [fanboshi]> select title,max(if(env=1,progress,-1)) 'RC',max(if(env=2,progress,-1)) 'Stage',max(if(env=3,progress,-1)) 'Prod' from t3 group by title;
+---------+-----------+--------+-----------+
| title   | RC        | Stage  | Prod      |
+---------+-----------+--------+-----------+
| 工单1   | 完成      | 完成   | 待审核    |
| 工单2   | 待审核    | -1     | -1        |
+---------+-----------+--------+-----------+
2 rows in set (0.00 sec)

问题描述

2020.05.18 16:12 收到报警

登录主机, 查看error log( 开启了innodb_print_all_deadlocks参数)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

*** (1) TRANSACTION:

TRANSACTION 1261729280, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 3645828, OS thread handle 139681739994880, query id 1522438991 172.16.23.82 yos_rw Searching rows for update
UPDATE f_log SET D_UPDATED_AT = NOW() , I_STATUS = 17 WHERE I_STATUS = 1 AND I_TYPE = 1
2020-05-18T16:11:11.696061+08:00 3056367 [Note] InnoDB: *** (1) WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 1208 page no 29439 n bits 160 index PRIMARY of table `yos`.`f_log` trx id 1261729280 lock_mode X locks rec but not gap waiting
2020-05-18T16:11:11.696079+08:00 3056367 [Note] InnoDB: *** (2) TRANSACTION:

TRANSACTION 1261729278, ACTIVE 0 sec updating or deleting
mysql tables in use 1, locked 1
10 lock struct(s), heap size 1136, 7 row lock(s), undo log entries 3
MySQL thread id 3056367, OS thread handle 139682403342080, query id 1522438990 172.16.23.82 yos_rw updating
UPDATE f_log SET D_UPDATED_AT='2020-05-18 16:11:11.693998',I_STATUS=3 WHERE (I_FILE_ID='92b52d6589ce11a9a3c985e7c5f37462efb66ac7')
2020-05-18T16:11:11.696099+08:00 3056367 [Note] InnoDB: *** (2) HOLDS THE LOCK(S):

RECORD LOCKS space id 1208 page no 29439 n bits 160 index PRIMARY of table `yos`.`f_log` trx id 1261729278 lock_mode X locks rec but not gap
2020-05-18T16:11:11.696112+08:00 3056367 [Note] InnoDB: *** (2) WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 1208 page no 17 n bits 1120 index idx_status_type of table `yos`.`f_log` trx id 1261729278 lock_mode X locks rec but not gap waiting
2020-05-18T16:11:11.696223+08:00 3056367 [Note] InnoDB: *** WE ROLL BACK TRANSACTION (1)

简单解释一下上面的死锁日志

和同事探讨一个问题, 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

New Feature in Percona XtraDB Cluster 8.0 – Streaming Replication

Percona XtraDB Cluster 8.0附带了一个升级的Galera 4.0库, 它提供了一个新特性—Streaming Replication.让我们回顾一下它是什么, 什么时候可能有用

以前版本的Percona XtraDB集群和Galera 3.x在处理大事务方面有限制.

让我们看一下sysbench-tpcc工作负载下的性能, 与此同时, 我们对一个表执行了一个大的更新语句, 该更新甚至与主工作负载中的表都不相关.

Galera 4 Streaming Replication in Percona XtraDB Cluster 8.0

我正在测试最新的Percona XtraDB Cluster 8.0 (PXC)版本, 其中包含了Galera 4插件, 我想分享一下到目前为止我在Streaming Replication特性方面的经验和想法,

What Is Streaming Replication, in One Sentence?

在Galera 4中, 大型事务可以分割成更小的片段, 甚至在提交之前, 这些片段就已经被复制到其他节点, 并且已经开始了认证(certification)和应用(apply)过程.

手册描述了所有的优点和缺点, 但是让我们看看它是如何工作的. 我已经创建了一个包含1千万行的表, 我将在这个表上运行一些大的update语句,

首先, 我在不使用Streaming Replication的情况下运行更新, 由于默认情况下Streaming Replication是disabled, 所以我们不需要做任何事情, 只需运行更新即可. 在node1上, 我记录更新之前和之后的时间, 在node2上, 我每秒钟运行一次select, 以查看这个更新在其他节点上实际提交的时间.

A Simple Approach to Troubleshooting High CPU in MySQL - 在MySQL中对高CPU进行故障排除的简单方法

我们的一位客户最近问，是否有可能从MySQL方面识别导致系统CPU使用率高的查询。 PostgreSQL和Oracle DBA长期以来一直使用简单的OS工具查找罪魁祸首，但是它对MySQL无效，因为历史上我们一直缺乏将OS线程与内部线程进行匹配的工具 - 直到最近。

Percona添加了支持，可从针对MySQL 5.6.27的Percona Server开始，通过information_schema.processlist表的TID列将进程列表ID映射到OS线程ID。 在5.7发行版中，MySQL扩展了PERFORMANCE_SCHEMA.THREADS表并添加了一个名为THREAD_OS_ID的新列，从而实现了自己的实现，Percona Server for MySQL代替了自己的列，因为它通常尽可能地靠近上游。

对于在其他内核正常运行时查询使一个特定CPU过载的情况，以下方法很有用。 对于一般的CPU使用问题，可以使用不同的方法，例如另一篇博客文章Reducing High CPU on MySQL: A Case Study的方法.

Group Replication and Percona XtraDB Cluster: Overview of Common Operations

在这篇博客文章中，我将概述使用MySQL Group Replication 8.0.19 (aka GR 国内爱叫MGR发现国外还是习惯叫GR)和Percona XtraDB Cluster 8 (PXC)(基于Galera)时最常见的故障转移场景和操作，并解释每种技术如何处理每种情况。我已经创建了一个包含三个节点的集群，使用一个主节点和一个包含三个节点的PXC进行组复制，它们均使用默认参数配置。 我还将使用ProxySQL与两个群集进行交互。

在这两个群集中，节点的名称分别为mysql1，mysql2和mysql3。 在组复制中，如果我们使用单主模式，则主节点处理写请求。 在PXC中，我也将使用相同的术语，并将在发送写操作的节点称为Primary。 请注意，在PXC中没有主节点的概念，所有节点都是相等的。

ClickHouse In the Storm. Part 2: Maximum QPS for key-value lookups

上一篇文章调查了ClickHouse的连接性基准，以估计服务器并发的总体性能。 在本文中，我们将以实际示例为例，并在涉及实际数据时探讨并发性能。

MergeTree: Key-value lookup

让我们看看MergeTree引擎表如何处理高并发性，以及它能够处理多少个QPS用于键值查找。

我们将使用2个综合数据集：

‘fs12M’-具有1200万条记录的表，id为FixedString(16)和5个不同类型的参数：

1
2
3
4
5
6
7
8
9

CREATE TABLE default.fs12M (
    id FixedString(16),
    value1 Float64,
    value2 Float64,
    value3 UInt32,
    value4 UInt64,
    str_value String
) ENGINE = MergeTree PARTITION BY tuple() ORDER BY id
SETTINGS index_granularity = 256

ClickHouse In the Storm. Part 1: Maximum QPS estimation - 最大QPS估算

ClickHouse是一个用于分析的OLAP数据库, 因此典型的使用场景是处理相对少量的请求:

• 每小时几个查询到每秒几十甚至几百个查询
• 影响大量数据(gigabytes/millions of rows)

但是它在其他情况下表现如何? Let’s try to use a steam-hammer to crack nuts, 并检查ClickHouse每秒将如何处理数千个小请求。 这将帮助我们更好地理解可能的用例范围和限制。

这篇文章分为两个部分。 第一部分介绍连接性基准测试和测试设置。 下一部分将介绍涉及实际数据的方案中的最大QPS。