It all started for me with the Google patch for MySQL in April 2007. The Register summary of that included a Cringely story repeated by Nick Carr that Google might have shared the patch as part of a plan to dominate IT via cloud computing. I thought that was ridiculous. AWS said hold my beer and brought us Aurora.
My reformatted posts:
- work done by several people to fix the InnoDB rw-lock for SMP
- other work for InnoDB SMP performance
- user, table, index monitoring
- crash safe replication state
- parser changes for new features
- semisync replication and design doc
- SHOW STATUS
- SHOW INNODB STATUS
- my.cnf
- adding roles to mysql
- make user delayed
- the Google patch for MySQL 5.0
- InnoDB IO performance
- user, table, index monitoring, also see this doc
- InnoDB Async IO
- Batch Key Access
- Binlog Event Checksum
- Fast Master Promotion
- InnoDB IO tuning
- InnoDB IO configuration
- InnoDB optimizer stats sampling
- InnoDB SMP
- Making mysqldump lossless for float & double
- Mirrored binlogs - this turned out to be a problem in production. I won't say more.
- More logging
- SHOW INNODB STATUS
- SHOW STATUS
- New SQL functions
- Online data drift
- Patch for MySQL 4.0
- QPS Rate Limits
- Semisync doc and design doc
- Transactional replication
- Global transactions IDs - work by Justin Tolmer at Google to enable failover automation. This was impressive. It was done years ahead of upstream. We couldn't wait.
- Roles
- SMP Performance
- Mutex statistics
Great post. I guess Global Transactions ID is pointing to LinkedIn.
ReplyDeleteFast, correct, automated failover is a game changer for upstream
Delete