marceloaltmann

Author here. Part 11 of a long series — if this is your first one, part 1 [1] has the setup, and part 5 [2] covers the original GTID_LOG_EVENT which is the natural thing to compare this against. Honestly, the tagged-GTID feature itself is the less interesting half of this event for me. What caught my attention while researching and writing it is that it's the first binlog event using MySQL's new mysql::serialization framework — a TLV format with field IDs and variants, where optional fields are just absent on the wire and older decoders skip unknown fields by ID. Everything before this was fixed layout (see [2]), so it feels like MySQL is quietly laying groundwork to evolve the binlog format without breaking downstream consumers. Tagged GTIDs are kind of the excuse to ship it.

[1] https://readyset.io/blog/mysql-binary-log-internals-part-1 [2] https://readyset.io/blog/replication-internals-decoding-the-...

Readyset is an Incremental View Maintenance cache that is powered by a dataflow graph to keep caches (result-set) up-to-date as the underlining data changes on the database (MySQL/PostgreSQL). RocksDB is only used as the persistent storage here, and the whole optimization is done for the DFG execution and not related to the persistent storage itself.

Straddled joins were still a bottleneck in Readyset even after switching to hash joins. By integrating Index Condition Pushdown into the execution path, we eliminated the inefficiency and achieved up to 450× speedups.

Replication has been one of MySQL’s most powerful and relied-upon features since the early days — long before it had things like foreign keys or even subqueries. It’s one of the foundational pillars that made MySQL suitable for large-scale, production use. This blog post walks through how replication evolved over time, and why it remains one of the strongest features in the MySQL ecosystem.

The Beginning (MySQL 3.23 — early 2000s) MySQL introduced statement-based replication (SBR) in version 3.23.15 in May 2000. This was a major milestone: it allowed users to replicate changes from one server (the source, previously called master) to others (replicas, previously slaves) by logging SQL statements executed on the source and replaying them on replicas.

That is a good point on the application changes. What is appealing from Readyset is that it does not require you to change your application code. You can just change your database connection string to point to it and it will start to proxy your queries to your database. From there you can choose what you want to cache, and everything else (writes, non supported queries, non cached read queries) will be automatically proxied to your database.

On top of that, quoting @martypitt reply:

> Most commonly the restrictions prevent you from launching a competing offering. In their case, you can't offer database-as-a-service using their code.

Meaning the self hosted version is free to use in any number of servers having in mind the competing offering restriction.

You can deploy on your own via their .deb packages - https://readyset.io/download

The advantages is that reading from a cache will be faster than from a read replicas. The benefits increase even further if you have to perform computation on the fetched data.

I found one case study on their blog - https://blog.readyset.io/medical-joyworks-improves-page-load...

> It will be interesting to see if any of these introduce some form of write support over time

Writes performed by your application in Readyset are automatically proxied(redirected) to your database.

You will add readyset between your backend and database in order to cache the data you fetch from db.

Caches are never invalidated. Readyset uses CDC to receive updates from PostgreSQL/MySQL and update the cache entries. No invalidation required. The price you pay is eventually consistent data, which is already true if you use any async replication like readyset does.

GDB is the go-to tool for debugging and troubleshooting low-level applications such as C++.

Sometimes all you need simple break at some specific point and print a variable to inspect its value. Other times you need to go even further and loop through some memory structure such as a list.

ReadySet is a new caching layer for PostgreSQL and MySQL that does not rely on TTL or cache invalidation, instead, it keeps a dataflow graph with dependencies and registers itself as a replica to keep cache entries up to date.

The new FIFO datasink has enabled XtraBackup to achieve remarkable transfer speeds exceeding 10Gbps.

Our recent blog post explains the architecture behind XtraBackup streaming and how the new FIFO enables true data transfer parallelism.

Amazon instance profiles are used to pass IAM roles to an EC2 instance. This IAM role can be queried using EC2 instance metadata to access an S3 bucket. Please check Amazon’s Official Documentation for more information.

Today we are happy to announce that starting with Percona XtraBackup 8.0.31-24, xbcloud can read instance metadata and fetch credentials from an instance profile, utilizing it to authenticate against an S3 bucket. Xbcloud is a tool part of Percona XtraBackup and allows you to upload and download backups to Amazon S3 storage.

We are glad to announce Percona XtraBackup Smart Memory Estimation as of the release of Percona XtraBackup 8.0.30. PXB has extended the crash recovery logic to extract the formula used to allocate memory.

That is exactly it. The difference comes from compression ratio. ZSTD is compressing the data more, so you need to write less back to disk. Also when talking about streaming, the difference is even more as it has to go over wan to S3 (provider used on blog test).

Today we are glad to introduce support for a new compression algorithm in Percona XtraBackup 8.0.30 – Zstandard (ZSTD).

Results shows that ZSTD not only overcame LZ4 results on all tests, but it also brought backup size to half of its original size.

When streaming is added to the mix is when we see the biggest difference between both algorithms, with ZSTD overcoming LZ4 with an even bigger margin.

This can bring users and organizations a huge amount of savings in backup storage, either on-premises or especially in the cloud – where we are charged for each GB of storage we use.