Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
gh-ost with MTS #841
gh-ost with MTS #841
Comments
|
gh-ost is/was used with multithreaded replication at GitHub, using |
|
That's good to hear. Would it be worth adding a pre-launch check that, if MTS is enabled, |
|
Probably a good idea. And anything else that may be relevant from https://dev.mysql.com/doc/refman/5.7/en/replication-features-transaction-inconsistencies.html |
We use gh-ost all the time and are considering switching our 5.7+ clusters to use MTS / parallel replication in one of the LOGICAL_CLOCK modes (COMMIT_ORDER for now; maybe WRITESET_SESSION later). Has gh-ost been tested with MTS or would we need to keep around a serial replica to run migrations from? I couldn't find anything in the docs or in any other issues, but I would imagine that parallel replication would mess up the way gh-ost detects events through the
_ghctables since you couldn't assume any kind of synchronization barrier between reading DML on the main table and reading DML into the ghc table.