In the previous blog, we saw that users don’t lose anything by moving to MySQL on ARM. Infact, users are set to gain performance and save cost. In this blog post we will see performance numbers and analyze them to understand points where ARM scores.

Benchmarking Setup

Benchmarking is done using sysbench. We have used the CPM model. You can read more about it here. In short the idea is to keep the cost the same and hunt for comparable configuration.

• Server Configuration:
  • sysbench 100 tables * 3 millions (roughly 69 GB of data)
  • We tried 2 combinations:
    • CPU Bound: buffer pool = 80 GB so complete data in memory (lesser IO).
    • IO Bound: buffer pool = 35 …

Previously posted on link at Nov 3, 2020. Traditionally, MySQL has been used to power most of the backend services at Bolt. We've designed our schemas in a way that they're sharded into different MySQL clusters. Each MySQL cluster contains a subset of data and consists of one primary and multiple replication nodes. Once data is persisted to the database, we use the Debezium MySQL Connector to capture data change events and send them to Kafka.

Understanding how MySQL uses memory is key to tuning it for optimal performance as well as troubleshooting cases of unexpected memory usage, i.e. when you have MySQL Server using a lot more than you would expect based on your configuration settings.

Early in MySQL history, understanding memory usage details was hard and included a lot of guesswork.  Is it possible that some queries running require a large temporary table or allocated a lot of memory for stored user variables?  Are any stored procedures taking an unexpectedly high amount of memory? All could be reasons for excessive MySQL memory usage, but you would not easily see if that is just the case.

All that changed with MySQL 5.7, which added memory instrumentation in Performance Schema, and with MySQL 8.0, this instrumentation is enabled by default, so you can get this data from pretty much any running instance.

If you’re looking for current memory …

 This is a reminder that MySQL 5.6 reaches End of Life status in February 2021.  I have been sending out such reminders since February of this year. But in my presentations this year when I bring up the 5.6 EOL, there are a lot of users out there that are surprised to hear the news.

    Wikipedia says ""End-of-life" ("EOL") is a term used with respect to a product supplied to customers, indicating that the product is in the end of its useful life (from the vendor's point of view), and a vendor stops marketing, selling, or rework sustaining it. (The vendor may simply intend to limit or end support for the product.)" 

…

MySQL 8.0.22 introduces many new improvements and updates, many of which deserve their own blog post for a deep dive into the new features.  Among the notable changes are: Prepared Statements, SHOW PROCESSLIST, TIMESTAMP, Read Only Schema, Error Log, User Management, Optimizer, Replication, Keyring, Router, and more.

Here are the MySQL 8.0.22 top blog posts:

Server

• The MySQL 8.0.22 Maintenance Release is Generally Available
• Announcing MySQL Server 8.0.22, 5.7.32 and 5.6.50

Shell

• MySQL Shell 8.0.22 …

MySQL 8.0.22 introduces many new improvements and updates, many of which deserve their own blog post for a deep dive into the new features. Among the notable changes are: Prepared Statements, SHOW PROCESSLIST, TIMESTAMP, Read Only Schema, Error Log, User Management, Optimizer, Replication, Keyring, ...

Let’s answer a question which, to my knowledge, has never been systematically addressed: What are the requirements for a production-ready query metrics app at scale? I am uniquely qualified to answer that because I have written four query metrics apps, two of which are the open-source standard for MySQL: pt-query-digest and the original (v1) code behind the query metrics/analysis part of Percona Monitoring and Management. I’ve also published a couple of packages related to query metrics: go-mysql/slowlog and go-mysql/query.

Let’s answer a question which, to my knowledge, has never been systematically addressed: What are the requirements for a production-ready query metrics app at scale? I am uniquely qualified to answer that because I have written four query metrics apps, two of which are the open-source standard for MySQL: pt-query-digest and the original (v1) code behind the query metrics/analysis part of Percona Monitoring and Management. I’ve also published a couple of packages related to query metrics: go-mysql/slowlog and go-mysql/query.

Let’s answer a question which, to my knowledge, has never been systematically addressed: What are the requirements for a production-ready query metrics app at scale? I am uniquely qualified to answer that because I have written four query metrics apps, two of which are the open-source standard for MySQL: pt-query-digest and the original (v1) code behind the query metrics/analysis part of Percona Monitoring and Management. I’ve also published a couple of packages related to query metrics: go-mysql/slowlog and go-mysql/query.

Galera replication technology, a key component of Percona XtraDB Cluster, suffered from a remote code execution vulnerability. Percona has been working with the vendor since early September on this issue and has made releases available to address the problem.

Applicability

A malicious party with access to the WSREP service port (4567/TCP) as well as prerequisite knowledge of the configuration of the Galera cluster name is required in order to exploit this vulnerability, which leads to remote code execution via the WSREP protocol. 

Fixes are available in Percona XtraDB Cluster versions:

>= 8.0.20-11.2

>= …