Morgan Tocker

Great overview + all applies to Spirit too. But also jealous my videos don’t have the same level of visualizations. Particularly agree on all the caveats about online DDL. It’s very hard to navigate and be successful.

If you are a user of gh-ost or pt-online-schema-change, take a look at Spirit! Presented by @morgo during the #MySQLBelgianDays #MySQL #MySQLCommunity

@altmannmarcelo @lefred @stoker @datacharmer I've done one even better: dropped a column instead of an index.

@lefred @morgo @stoker @datacharmer They all have done a DELETE without WHERE

find what these 4 have in common! #MySQLCommunity #MySQLBelgianDays2024

Fellow Brisbane native @morgo speaking at #MySQLBelgiumDays2024 #MySQLCommunity #mysql code.cash.app/introducing-sp……

@sunbains @mjovanovictech IMHO the explanation of the cache-aside is too simplistic. If you depend on the cache there will be a race (aka stampede) where everyone tries to regenerate the cache at once. Regenerate it from the DB is nice, but usually in the cache you want to store more complicated objects

Sure, but how does that answer my question? The diagram seems to be about a simple stateless cache. Why can't it be moved closer to or on the same DB host? Hypothetical example, write a plugin/extension in your favorite database that uses the write aside cache in the same way as in the diagram.

The Cache-aside pattern can 10x your application performance. Another name for it is "Lazy Loading". Here's the entire Cache aside logic summarized: 1. Try to read data from the cache first 2. Cache hit - return the cached data directly 3. Cache miss - query the database and cache the result The Cache-aside pattern comes with a few interesting advantages. The cache only contains the frequently requested data in the application. This is helpful to control the cache size. Another advantage is that this approach is simple to implement. The only significant disadvantage is that the first request is often slow. This is because of the cache miss and having to query the database. What other caching approach would you consider and why? --- Do you want to become a better software engineer? Consider subscribing to The .NET Weekly. You'll get one practical tip about .NET and software architecture every Saturday. Join 37,000+ engineers: milanjovanovic.tech/?utm_source=Tw…

We are sold-out ! But there is a waiting list, please don't hesitate to subscribe to it if you want to attend we might free some spots next week ! #MySQLBelgianDays #MySQLCommunity 🐬🇧🇪

Interesting idea by @morgo bugs.mysql.com/bug.php?id=113… I think it’s doable but don’t think it’s as simple as taking multiple views from a single transaction. IIRC, handling the deletes makes it tricky. Perhaps easier to use a transaction per B-tree sub-tree. Once a sub-tree scan completes delete the read view.

@sunbains Yes, apply phase can be tricky: Gh-ost/spirit implement the "multiple read views" feature already outside the server (autocommit reads), so that part of the FR was not novel. Gh-ost is single threaded apply. Spirit is multi-threaded only when PK is mem comparable.

@morgo The problem is the apply phase of concurrent changes . There are assumptions built into the change capture and reconciliation at the end. I suspect that will have to change too. I won’t be holding my breath 🙂

@sunbains Think of it as a dirty copy (except uncommitted data) followed by an apply of all deltas

@sunbains It can be multiple transactions. There is no reason it has to be one, it just needs to be RC+. As long as it subscribes and applies changes (delete,insert, update) at the end it will be consistent.

The end of dbdeployer #mysql datacharmer.github.io/end-of-dbdeplo…

@datacharmer Thank you so much for your work over the years! It has saved me many hours of work.

@sjmudd It is easy for me to add them to CI. Last I checked they were not in dbdeployer's built in download list. That was the only hold up :-)

@morgo Morgan, MySQL 8.1 is out and 8.2 is expected very shortly. Usage of 8.1+ may not be high yet, but unless something significant changes I'd expect spirit to work on these versions too.

Part 2 of our MySQL Schema Change story: code.cash.app/introducing-sp… (Spirit; a reimplementation of gh-ost)

More Resilient Schema Changes at Scale code.cash.app/more-resilient… (part 1 of 2 in introducing 'Spirit'; our online schema change tool for MySQL).

A much needed improvement.

A fun blog post - some random database feature ideas that are 'keynote worthy' tidb-blog.vercel.app/posts/keynote-…

A TiDB success story (feat. Plan Digests) tidb-blog.vercel.app/posts/a-tidb-s…

@tobias_petry @Muffins_ @MySQL @mariadb This is likely the result of MySQL cost-model work in ~MySQL 5.7. I think it is relevant because new cost model work is a MariaDB 11 feature. Implementations will likely differ of course.

@Muffins_ @MySQL @mariadb I have the same feeling. MariaDB more often chooses a weird execution plan. But that is not a hard fact I can prove. So it won‘t be included.

Most developers still believe @MySQL and @mariadb to be the same. But over the years they developed completely different features. I am currently collecting all the differences to write a very big article. What missing features in one of the databases did you encounter?

Blip: A New Open Source MySQL Metrics Collector hackmysql.com/post/blip-v1.0…