译文 Galera 4 Streaming Replication in Percona XtraDB Cluster 8.0

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

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

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与两个群集进行交互。

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

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

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 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。

ClickHouse多实例部署

ClickHouse多实例部署

本人刚接触ClickHouse两周, 难免有错误之处, 感谢指正. 另外一些参数我也不甚理解, 大家也可以先不必纠结参数, 先部署起来再说, 我的感触是部署后就会对整体结构有了一遍认识. 如果多实例都可以部署完毕, 那么生产单实例部署当然就不成问题了.

生产环境并不建议多实例部署, ClickHouse一个查询可以用到多个CPU, 本例只适用于测试环境


Powered by Hexo and Hexo-theme-hiker

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

访客数 : | 访问量 :