[Percona Community Forum] Summary

No dark-mode styles — this email renders the same in a dark client.

A brief summary of [Percona Community Forum][1] since 2026-09-21 00:46:46 UTC

6 New Topics
17 New Users


  
  ### Popular Topics

    [Tarball-based Percona SST/IST failure after upgrading from 8.4.4-4.1 to 8.4.8-8.1][2]

      We have successfully deployed a 3 node Percona XtraDB Cluster v8.4.4 via the el8 (glibc2.28) “miminal” tarballs on 3 RHEL8.10 servers. Everything is running as root and deployed under /root directory (tarball extracted into /root/install/ and datadir set as /root/datastore/var/lib/mysql) 

Node 1 = ‘ha4’ - example IP address of 1.1.1.1
Node 2 = ‘ha5’ - example IP address of 2.2.2.2
Node 3 = ‘ha6’ - example IP address of 3.3.3.3

We are then trying to do a rolling minor version upgrade of the cluster to v8.4.8, guided generally by the docs at Upgrade Percona XtraDB Cluster - Percona XtraDB Cluster and so far we cannot get an upgraded node to rejoin the cluster and IST/SST times out on that node after approx 100s and the node aborts. 
Our general steps to attempt to upgrade a node are: 

Gracefully stop the mysql process
Download and extract the PXC8.4.8 glibc2.28 minimal tarball to the /root/install dir
Update the PATH variable in the /root/.bashrc file to reference the newer Percona pa...

    
    [Forged TCP RST (TTL 128) killing frontend sessions on ProxySQL 6033 — PXC 8.4.10 / ProxySQL 3.0.9][3]

      Environment 

ProxySQL 3.0.9, two nodes (keepalived VIP 10.160.9.72:6033)
Percona XtraDB Cluster 8.4.10, 3 nodes, singlewrite (HG10 writer / 11 reader)
Zabbix 7.0.19 frontend (PHP), Oracle Linux 9

Symptom 
Linking an MSSQL template from the Zabbix frontend fails with MySQL server has gone away. Simple templates work. Only through ProxySQL. 
What the packet captures show 
Simultaneous tcpdump on both ends: 

A single TCP RST arrives inbound on both hosts, 657 µs apart, in the same session
Both carry TTL 128 — Linux stacks here use 64
Neither host transmits any RST
The reset lands ~159 µs after a 1242-byte INSERT INTO item_rtname ... UPPER('Service\'s TCP port state')
The statement never reaches the PXC backend

Ruled out 

Replaying the exact bytes from the pcap via the mysql CLI succeeds (returns Duplicate entry — so it reaches the server)
Payloads up to 4 MB pass fine; the 1.2 KB one that fails does not
SQLi-like patterns (UNION SELECT, @@version, xp_cmdshell, backslash-escaped quote...

    
    [Openshift - operator upgrade - OLM wants to upgrade 2.9.0 straight to 3.1.0][4]

      Hey @eprevost , 
This is a limitation related to the certified OLM bundles and the OpenShift versions for which each operator version was certified. 
In general, our recommendation is to upgrade OpenShift through each minor version and update the operator bundle accordingly at each step. This ensures that OLM follows the supported upgrade path and that the corresponding certified bundle is available for that OpenShift version. 
For example, rather than keeping the same OpenShift version while moving directly across multiple operator versions, the recommended approach is to upgrade OpenShift minor by minor and update the operator bundle along the way. 
Could you please confirm: 


Which OpenShift version was running when PGO 2.9.0-cw was originally installed? 


Which OpenShift version is the cluster running now? 


This will help us understand which certified bundles should be available and determine the appropriate upgrade path from 2.9.0-cw to 3.1.0. 
Thank you!

    
    [PMM - disk latency graph][5]

      In PMM there is a “Disk Latency” graph. Its description says: 

Shows average latency for read and write IO operations. Higher than typical latency for highly loaded storage indicates saturation (overload) and is a frequent cause of performance problems. Higher than normal latency can also indicate internal storage problems. 

Calculation formula: 

sum(rate(node_disk_read_time_seconds_total{instance=~“instance”,device= “instance”,device= “device”}[instance", device=~“device”}[interval])) > 0 or sum(irate(node_disk_read_time_seconds_total{instance=~“instance”,device= “instance”,device= “device”}[5m]) / irate(node_disk_reads_completed_total{instance=~“instance”,device= “instance”,device= “device”}[5m])) > 0 or vector(0) 

Using this calculation formula, I wrote a script: 

#!/bin/bash 
INTERVAL=300 
DEV_REGEX=‘^(sd[a-z]+|nvme[0-9]+n[0-9]+|vd[a-z]+|xvd[a-z]+|mmcblk[0-9]+)$’ 
snapshot() { 
awk -v re=“$DEV_REGEX” ‘$3 ~ re {print $3, $4, $7, $8, $11}’ /proc/diskstats 
} 
now_human() { 
date...

    
    [Reviewing large projects with AI: contributing in a … | Percona Community][6]

      When you read about how LLMs help developers start on a project, it’s usually about how quickly they can create their first meaningful PRs.
But is it really them creating those patches? 

This is a companion discussion topic for the original entry at https://percona.community/blog/2026/09/25/reviewing-large-projects-with-ai-contributing-in-a-meaningful-way/

    

  




**New for you**

* [Open FIPS Build, Vectors, and Binlog Server: Marco Tusa at … | Percona Community][7] - 1 - [Community website]



[1]: https://forums.percona.com/
[2]: https://forums.percona.com/t/tarball-based-percona-sst-ist-failure-after-upgrading-from-8-4-4-4-1-to-8-4-8-8-1/41279
[3]: https://forums.percona.com/t/forged-tcp-rst-ttl-128-killing-frontend-sessions-on-proxysql-6033-pxc-8-4-10-proxysql-3-0-9/41292
[4]: https://forums.percona.com/t/openshift-operator-upgrade-olm-wants-to-upgrade-2-9-0-straight-to-3-1-0/41289
[5]: https://forums.percona.com/t/pmm-disk-latency-graph/41290
[6]: https://forums.percona.com/t/reviewing-large-projects-with-ai-contributing-in-a-percona-community/41294
[7]: https://forums.percona.com/t/open-fips-build-vectors-and-binlog-server-marco-tusa-at-percona-community/41293
[8]: https://forums.percona.com/



  This summary is sent from [Percona Community Forum][8] when we haven't seen you in a while. Change [your email settings][9], or [click here][10] to unsubscribe.

[9]: https://forums.percona.com/my/preferences/emails
[10]: https://forums.percona.com/email/unsubscribe/7a84c161f40e67425674b6316d3b522e55a87992e008a73827fbaa0f4a6340ec

Accession

nse/percona/2026-09-28/2660

From

Percona Community Forum · notifications@percona1.discoursemail.com

Sent

28 September 2026 · 01:00 UTC