Repository navigation
Omar Farhat
I had my first introduction to MySQL during my master's in databases and distributed systems at the University of Waterloo. My own work was on streaming systems, but I was surrounded by peers in the Data Systems Group who were working on making consensus algorithms like 2PC and Paxos more performant and less needed, and a lot of that was done through experimentation with the MySQL codebase. I got to validate their code and run some of those experiments myself, all on top of MySQL 5.6. That was my first real exposure to the MySQL codebase. Afterwards, I joined AWS Aurora MySQL in 2020, and since then I've been working with the MySQL codebase on a regular basis.
At Aurora MySQL we always call MySQL "community MySQL," but I never really got to know who the "community" was until the contributor summit this past August. There, I got to see the range of dedicated MySQL contributors working across the ecosystem, from vector search and extensibility to what other MySQL vendors are building, along with a lot of improvement in the logical replication space.
My current specialty is logical replication, so I've been naturally connected to my counterpart at Oracle. Working closely with them, AWS contributed a large-transaction binary log optimization to MySQL. Tiago Jorge, Karolina Szczepankiewicz, Nuno Carvalho, and the rest of the MySQL engineering team were a big part of making it happen.
The summit also introduced me to people at other companies working in the same area, including Libing Song from Alibaba Cloud, who has pioneered a number of innovative logical replication solutions you can find on MySQL's GitHub. Across all of it, I saw a strong intersection with the optimizations we've been building on top of MySQL, especially on reducing I/O, improving compute utilization, and better handling of large transactions.
Inside AWS, there are plenty of talented engineers who have inspired me, who I've had the pleasure to learn from and work with on a lot of MySQL development over the years.
My favorite is WRITESET-based dependency tracking in the replication applier. It's one of the main reasons why MySQL replication throughput has improved significantly over the last few years.
Multi-threaded replication needs to know which transactions can be applied in parallel on the replica, and that decision is made on the source. The source stamps each transaction with a logical timestamp that the replica uses to parallelize execution. The original method, COMMIT_ORDER, derives the dependency from commit timing, treating two transactions as parallelizable only if they held all their locks at the same time, which means transactions touching completely unrelated rows can still be serialized simply because their commit windows did not overlap.
WRITESET, on the other hand, reflects real row conflicts. It does so through computing a set of hashes for each transaction, one per changed row, and setting the dependency to the most recent transaction whose writeset overlaps. When we quantified this by rendering the transaction dependencies as a directed acyclic graph, where each edge is a real dependency and the longest path is the serialization bottleneck, WRITESET produced much sparser graphs, with longest paths up to roughly 99% shorter than COMMIT_ORDER in a Sysbench workload. It was fascinating to visualize that and see how it translates into improved throughput on the applier.
It is worth understanding where WRITESET falls back to serialized behavior. If your workload has tables without a primary or unique key, or relies on foreign keys, this optimization will not work well for you and you might still see replication lag.
A lot of what made PostgreSQL thrive is how extensible it is, with a rich ecosystem that grew on top of the core engine. While MySQL's existing extension surface is narrower, the last two contributor summits both had ambitious proposals in this area, so I think a real breakthrough is close. This would let us build a lot of exciting artifacts into MySQL itself. One extension could consume the binary log inside the database and emit it in universal formats like Parquet or Avro, so the data becomes immediately usable by other systems.
The most interesting problem I have worked on is replication lag, where the replica cannot keep pace with the source. In the ideal world, the replica applies the same transactions as the source at a faster rate.
There are multiple reasons a replica ends up slower than the source. The main ones are that the multi-threaded applier does not utilize compute well and that I/O is heavy, since the applier continuously reads from and writes to the relay log. On top of that, the workload itself can make things worse, either through coarse dependencies sent by the source that force transactions to be applied serially (the WRITESET story from the earlier question), or through large transactions that collapse multi-threaded application down to a single thread.
Oracle and MySQL have already made significant progress on the compute side. Multi-threaded replication became the default in 8.0.27, WRITESET-based dependency tracking followed in 8.4.0, and the Change Stream Applier (CSA) landed in 26.10, which significantly optimizes compute scheduling. What remains is the I/O side and the handling of large transactions.
On I/O, we are currently contributing an in-memory relay log for the replica, so received transactions stay in memory instead of being written to disk and read back (PR #743). This does not only improve receiver speed, since the receiver no longer has to write to disk, but it also improves applier speed, because the applier can read the transaction straight from memory.
As for large transactions, there are two interesting proposals to tackle this. The first is intra-transaction parallelism in the CSA, where multiple threads cooperate to apply a single large transaction instead of single-threaded execution. The second, proposed by Alibaba, is to send the transaction's events to the replica while it is still live on the source, so the replica gets a head start instead of waiting for the full commit (mysql-community #115). That approach only helps when the replica is already caught up. Both of these solutions can work together towards a better solution for large transactions.
I am quite passionate about data interoperability, and Apache Iceberg and Apache Arrow are powering exactly that, with systems like DuckDB able to query data directly where it lives. What excites me most is the prospect of making migration a routine operation rather than the expensive one-off it is today.