Percona are flogging a dead horse called "Oracle" while at the same time basically being an Oracle subsidiary without being Oracle, but it's basically Oracle wrapped in scary perl scripts with backported features from better forks.
If you were to meet me in person I would just say "Fuck Percona/Oracle and their shitty shit".
does anyone know if this supports RBR with --binlog-row-image=minimal? I could only find mention of wanting RBR, no hints about whether it can handle minimal format
given that this needs access to the binary log, am I out of luck if I want to use this with amazon rds? (I don't see a way to see/access the binlog at rds)
thank you - still not sure if this tool could use it as it needs (perhaps 'streaming' the binlog?). I'm wrestling with making changes on a large RDS table, but I also don't actually have total permission on the account as it belongs to a client so I have to keep trying things, then seeing what breaks, then asking for a change, then trying again.
Apparently gh-ost won't work, but there are other tools that work fine on RDS: I've been using https://github.com/soundcloud/lhm On some fairly large tables (30 million + rows) without any problems
thanks - will look at this if I can't get the pt stuff working (already have used that in the past, so would rather keep new tools to minimum). This particular table is ... 200 million rows, give or take, and is a bugger to deal with).
I really want this to work on RDS. However, according to the docs[0]: Amazon RDS and Google Cloud SQL are probably not supported (due to SUPER requirement)
Ah indeed it won't work on RDS as they explicitly test for SUPER or ALL privileges. But it's possible that the tool could be made to work without it in the future.
While MySQL isn't the best db, and does have many flaws, it's asinine to say that other solutions are wholly better. Everything has a set of limitations, so just because something like Postgres doesn't have this specific limitation doesn't mean it doesn't have others. It also may be more worth it to work around the limitations of MySQL than to migrate all data to another database.
Keep in mind that Postgresql wasn't as in vogue when Github was first built, and most or all of the NoSQL solutions you're thinking of didn't even exist. Up until 2 years ago, they were running Rails 2.3, and then is when they moved to Rails 3 (Rails 4 had been out a year at that point). I am very assured that Github is very careful about their technology choices and not quick to chase trends, given the importance of their application.
Not by my recollection, and most ways of looking at trends seem to suggest the same: (unfortunately many don't go back that far, but let you see some trends)
And if you read carefully through their post, and the comments, and the commentary on pgsql-hackers, you'd see that:
1) it was an engineering decision based on their particular situation and use case (as it should be)
2) that use case may be pretty specific and/or unique, and not well suited for Postgres (which is fine)
3) they don't explain what all their tradeoffs are, just the ones they're making arguments against (which makes the post much less useful than it could be)
I would not take that blog post as a general "MySQL is better than Postgres" argument. It really needed more info on what they're doing, why they're doing it that way, and what tradeoffs they were willing to make (speed vs. data integrity, etc.).
