Here at Percona, we operate on the premise that full transparency makes a product better. We strive to build the best open-source database products, but also to help you manage any issues that arise in any of the databases that we support. And, in true open source form, report back on any issues or bugs you might encounter along the way.
We constantly update our bug reports and monitor other boards to ensure we have the latest information, but we wanted to make it a little easier for you to keep track of the most critical ones. These posts are a central place to get information on the most noteworthy open and recently resolved bugs.
In this June 2022 edition of our monthly bug report, we have the following list of bugs:
Percona Server for MySQL/MySQL Bugs
PS-8250(MySQL#107352): Rows_examined, regardless if checked via performance_schema or slow query logs, have confusing values. It looks like only rows examined from an outer query are counted.
The row examined count is retrieved from thd->get_examined_row_count(); the member (ha_rows m_rows_examined). This variable is incremented after joins. THD::inc_examined_row_count().
In 8.0, the optimizer moved to a new style, the QueryIterator model. The examined row count is calculated differently.
The rows examination in 5.7 includes rows examined in all phases of the query which we expect the same in 8.0 as well.
Affected version/s: 8.0.28, 8.0.29
PS-8271(MySQL#82599): slave_type_conversions messing with data that still fits within the allowed range.
It may happen that you want to prepare for int column growth and change datatype from int to bigint, so you do it first on the slave.
Unfortunately, after passing the maximum value for signed int (2147483647), when the source has unsigned int, regardless of whether the replica has signed or unsigned bigint, the values get either truncated to 0 (when unsigned) or stored as negative numbers counting from -2147483647 downwards.
Affected version/s: 5.7.14, 5.6, 5.6.32, 8.0.28
PS-8070(MySQL#106560): Regression on DDL statements with big stage/sql/checking permissions.
So the reason for performance degradation is due to DDL operations in 8.0 are all atomic, while 5.7 operations did not allow that. Next, 8.0 has been designed to provide much better performance in multi-threaded loads. Hence, we recommend running your DDLs in many threads. That also means to dump your schemas with mysqlpump, instead of mysqldump.
Affected version/s: 8.0
PS-8050(MySQL#106616) : PS 8.0 upgrade (from PS 5.7) crashes with Assertion failure: dict0dict.cc:1236:table2 == nullptr
Please note that this bug is fixed and the fix is available in 8.0.28-19
Affected version/s: 8.0
Fixed version: 8.0.28-19
PS-8115(MySQL#106728) : CREATE EVENT DEFINER=test@usr@localhost processed as ‘test’@’usr@localhost’
Event scheduler looks for the first @ sign to separate the user name from the hostname.
MySQL can create users with @ side in the middle of user name: create user test@usr@localhost;
Affected version/s: 5.7.36-39
Fixed version: 5.7.37-40
Please note that 8.0 is unaffected by this issue.
Percona XtraDB Cluster
PXC-3923 : ANALYZE TABLE crashes node when [super_]read_only is set!
When the read_only or super_read_only is set, ANALYZE TABLE command gives an error “ERROR 1290 (HY000): The MySQL server is running with the –read-only option so it cannot execute this statement” which is expected but in the background, the node is evicted from the cluster with “Inconsistency detected” message.
Affected version/s: 8.0.26-16, 8.0.27-18
Fixed version : 8.0.28-19
Percona Toolkit
PT-2070 : pt-table-checksum to be run on PXC with pxc_strict_mode=ENFORCING
pt-table-checksum cannot be run with pxc_strict_mode=ENFORCING as STATEMENT events are rejected in this mode.
Setting the pxc_strict_mode=PERMISSIVE enables pt-table-checksum to run successfully.
Affected Version/s: 3.3.1
PT-2066 : pt-online-schema-change can’t connect on non-default port
When trying to use pt-online-schema-change to connect to MySQL DB with a non-default port it is throwing an error saying “Can’t connect to MySQL server on ‘[db instance].rds.amazonaws.com:3306‘ (110) at /usr/bin/pt-online-schema-change line 2345.”
As a workaround to this issue, we can pass the connection options via DSN.
Affected Version/s: 3.3.1
Percona Monitoring and Management (PMM)
PMM-9413 : pmm-managed gets deadlocked when an agent connects with a duplicate agent_id.
A VM with a PMM client installed is replicated in a cloud environment. PMM client runs in a replica with the same configuration data as the original VM. Duplicate agent ID is detected by pmm-managed. It causes failure to add any new resources for monitoring and OOM-killer kills pmm-managed.
Affected version/s: 2.25.0
Fixed version: 2.27.0
Percona Operator for MySQL based on Percona XtraDB Cluster
K8SPXC-804 : Mark pxc container restarts in logs container output
mysqld could be killed by oom killer or by kill -9 in private clouds.
There are no messages generated between the last valid log entry and the first mysqld startup message.
Affected version/s: 1.7.0
Fixed version: 1.12.0
K8SPXC-1036 : Liveness check fails when XtraBackup is running and wsrep_sync_wait is set
Backups run on non-writer nodes. When XtraBackup runs, it performs a LOCK TABLES FOR BACKUP on the instance. If the writer instance performs a DDL, such as creating a table, on the node where the backup is running, the DDL will wait behind the BACKUP LOCK to complete. If wsrep_sync_wait is != 0, subsequent SELECTs will remain on the write-set queue until the node is in sync.
Affected version/s: 1.10.0
Fixed version: 1.12.0
Summary
We welcome community input and feedback on all our products. If you find a bug or would like to suggest an improvement or a feature, learn how in our post, How to Report Bugs, Improvements, New Feature Requests for Percona Products.
For the most up-to-date information, be sure to follow us on Twitter, LinkedIn, and Facebook.
Quick References:
Report a Bug in a Percona Product
___
About Percona:
As the only provider of distributions for all three of the most popular open source databases—PostgreSQL, MySQL, and MongoDB—Percona provides expertise, software, support, and services no matter the technology.
Whether its enabling developers or DBAs to realize value faster with tools, advice, and guidance, or making sure applications can scale and handle peak loads, Percona is here to help.
Percona is committed to being open source and preventing vendor lock-in. Percona contributes all changes to the upstream community for possible inclusion in future product releases.