Comments on: MySQL Architecture meeting at Google http://www.mysqlperformanceblog.com/2008/04/24/mysql-architecture-meeting-at-google/ Everything about MySQL Performance Thu, 28 Aug 2008 00:12:27 +0000 http://wordpress.org/?v=2.5.1 By: peter http://www.mysqlperformanceblog.com/2008/04/24/mysql-architecture-meeting-at-google/#comment-288855 peter Sun, 27 Apr 2008 06:58:33 +0000 http://www.mysqlperformanceblog.com/2008/04/24/mysql-architecture-meeting-at-google/#comment-288855 Oh yes, All details of integration with existing MySQL environments could be interesting story. Replication, Backups, Monitoring need to be thought of. Oh yes,

All details of integration with existing MySQL environments could be interesting story. Replication, Backups, Monitoring need to be thought of.

]]> By: Mark Callaghan http://www.mysqlperformanceblog.com/2008/04/24/mysql-architecture-meeting-at-google/#comment-288003 Mark Callaghan Fri, 25 Apr 2008 15:32:02 +0000 http://www.mysqlperformanceblog.com/2008/04/24/mysql-architecture-meeting-at-google/#comment-288003 There are trade-offs that many deployments will have to make. Today with InnoDB on a slave you can use MySQL replication to trickle changes to the slave and have long-running reporting queries concurrent with the replication changes. Reporting is done against current data and changes are pushed to the server automatically. Some of the new storage engines don't support replication. You have to figure out how to capture changes on your OLTP masters (full extraction might cost too much) and then automate pushing them to the new storage engine. And if the change capture mechanism is to use a trigger on every table on the OLTP master, then that makes the OLTP master a lot slower. Others might support replication, but don't support MVCC meaning that when you do updates, all queries have to stop. Lets hope that the query speedups are worth the added costs. There are trade-offs that many deployments will have to make. Today with InnoDB on a slave you can use MySQL replication to trickle changes to the slave and have long-running reporting queries concurrent with the replication changes. Reporting is done against current data and changes are pushed to the server automatically.

Some of the new storage engines don’t support replication. You have to figure out how to capture changes on your OLTP masters (full extraction might cost too much) and then automate pushing them to the new storage engine. And if the change capture mechanism is to use a trigger on every table on the OLTP master, then that makes the OLTP master a lot slower.

Others might support replication, but don’t support MVCC meaning that when you do updates, all queries have to stop.

Lets hope that the query speedups are worth the added costs.

]]>