A new open source tool called gcache-inspector lets DBAs decode and inspect Galera Cache (galera.cache) files used by Percona XtraDB Cluster and MariaDB Galera Cluster. Instead of treating the write-set cache as a black box, the tool offers offline inspection of cache files, per-sequence-number detail views, row-based event decoding, and support for encrypted cache files (given the key or vault credentials). It aims to help with capacity planning, incident investigation, and understanding IST/SST node rejoin behavior. Released under GPLv3 with Go source and binaries available on GitHub, along with a demo recording.

5m read timeFrom percona.com
Post cover image
Table of contents
What is Galera Cache?The gcache-inspectorEncrypted Galera CacheSummary

Questions this post answers

How can I inspect the contents of a Galera Cache (galera.cache) file in Percona XtraDB Cluster?

Use gcache-inspector, an open source Go tool that decodes Galera cache and gcache.page.X files offline, whether or not the PXC node is running. It produces write pattern statistics and write-set information, and with the --detail flag shows per-sequence-number details, while --decode-rows prints full row-based event contents for a given seqno. Anyone debugging Galera replication write-sets can track tools like this via daily.dev.

Can gcache-inspector read encrypted Galera cache files in Percona XtraDB Cluster?

Yes, gcache-inspector can inspect encrypted gcache files if given the encryption key or vault credentials. However, unlike a regular cache file that shows replicated transactions immediately, an encrypted cache file only reveals new entries once the encryption in-memory cache is filled or synced during shutdown, so new transactions appear with a delay. It does not support MariaDB Galera Cluster Enterprise Edition encryption due to lack of source code access. Teams running encrypted PXC clusters can follow gcache tooling updates on daily.dev.

Why would a Galera or PXC node fail to rejoin via IST and fall back to a full SST instead?

A node falls back to SST when the donor's Galera cache does not cover enough of the time the joining node was offline, meaning the required write-set history has already been overwritten in the ring-buffer cache. The donor's coverage can be checked via the wsrep_local_cached_downto status variable, and cache rotation can be paused with gcache.freeze_purge_at_seqno to extend the donor's coverage window. Developers troubleshooting cluster rejoin failures can track Galera internals discussions on daily.dev.

329 Impressions