Chinaunix首页 | 论坛 | 博客
  • 博客访问: 142968
  • 博文数量: 82
  • 博客积分: 1415
  • 博客等级: 上尉
  • 技术积分: 890
  • 用 户 组: 普通用户
  • 注册时间: 2009-06-08 22:30
文章分类

全部博文(82)

文章存档

2011年(1)

2009年(81)

我的朋友

分类: Mysql/postgreSQL

2009-06-29 17:09:40

Ben Handy (Google), Justin Tolmer (Google)
4:25pm Wednesday, 04/22/2009
Replication and Scale-Out, Storage Engine Development and Optimization
Location: Ballroom C
 
Like most users, Google wants MySQL to be perfect. Perfect means that it should scale linearly on large servers, never crash and be trivial to manage. We will describe the changes we have published, document their benefit with benchmark results, and describe our experience as a member of the MySQL developer community. Anything we implement is deployed on critical servers within a few months. This makes for interesting times.
 
We have enhanced InnoDB and MySQL to scale on servers with more than 4 cores for read-only and read-write workloads. We made the mutex code in InnoDB faster, refactored code to remove mutex hot spots, added instrumentation to report on mutex contention by mutex and by mutex caller and integrated MySQL with tcmalloc. We will provide benchmark results for 8 and 16 core servers to show that they run MySQL much faster than 4 core servers.
 
We have made replication more robust and easier to manage. This includes transparent slave failover, crash-safe slaves, checksums in binlog events and better support for hierarchical replication. Slaves are made crash-safe by fixing bugs that corrupt slave replication state on a crash. With these changes and the use of transactional replication, it is safe to crash and restart a slave without fear of duplicate transactions or a halted slave.
 
Global transactions IDs have been implemented. These provide unique binlog event identifiers to enable transparent slave failover and hierarchical replication. When a master fails a slave can change to the new master without losing transactions and without manually remapping its replication offset to the new master. Hierarchical replication is much easier to support when slave failover is transparent. In addition, slaves that restore a backup taken before a master failure can catch up on replication using other servers without remapping replication offsets.
 
We continue to add instrumentation to make the server easier to understand. New features include SQL commands that display mutex contention statistics, query plans for running queries and information on temporary tables open for all connections. We will describe interesting things that can be done with these details.
阅读(603) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~