michaeldejong

3 ms·

1. 1.▲
   by michaeldejong 3y ago

   Very cool! Congratulations to the authors on the release! I'm the author of a similar (zero-downtime migration) tool for PG called QuantumDB[0]. It was the first (to my knowledge at least) tool to support foreign keys, by creating tabl
2. 2.▲
   by michaeldejong 8y ago

   Actually both lock for many (crucial) schema operators, and often severely enough to block your application from reading from the table(s) under change. I've been researching this stuff for a while. Check out http://blog.min
3. 3.▲
   by michaeldejong 8y ago

   I felt the same way, so I've been working on QuantumDB for the last couple of years. Take a look at https://quantumdb.io . QuantumDB doesn't use the binlog / WAL log like gh-ost does, but it does support foreign k
4. 4.▲
   by michaeldejong 9y ago

   Agreed. But to be fair I've not yet encountered such a library/tool yet. All tools I've seen leave the active table alone, and simply create a new table, do all their work there, and finally somehow switch the two tables (eit
5. 5.▲
   by michaeldejong 9y ago

   I agree with that. If your database doesn't care about a "schema", there usually are no operations available which change the schema of your data. Unfortunately that also means that if your database doesn't consider the
6. 6.▲
   by michaeldejong 9y ago

   That's not great either. Moving the "master" role from one server to a replica isn't instantaneous (meaning you have a period of read-only state), and while your replica is performing the schema operation you still need
7. 7.▲
   by michaeldejong 9y ago

   Indeed. It seems there are many such tools available for MySQL: Openark kit [0] for instance, whose author also brought us gh-ost. Unfortunately most tools focus on just MySQL, and none really have an answer when you want to use (and enforc
8. 8.▲
   by michaeldejong 9y ago

   Researcher/author of a tool [0,1] also attempting to tackle this problem here. Unfortunately zero-downtime schema changes are even more complex than suggested here. Although the expand-contract method as described in the post is a good