MySQL半同步存在的问题
去年做过MySQL HA高可用方案,就是利用了Google的半同步补丁来加以实现的。而现在MySQL5.5中已经集成了semi-sync replication的功能,那么我们可以放心用它和其他组件及服务判断程序来实现我们的高可用解决方案。但是这里还存在一点瑕疵,需要注意。 By ivan@mysqlab.net
阅读全文…
去年做过MySQL HA高可用方案,就是利用了Google的半同步补丁来加以实现的。而现在MySQL5.5中已经集成了semi-sync replication的功能,那么我们可以放心用它和其他组件及服务判断程序来实现我们的高可用解决方案。但是这里还存在一点瑕疵,需要注意。 By ivan@mysqlab.net
细心的朋友可能会发现有时候在某些库目录下有个 db.opt 文件,那这个文件是干什么用的呢?如果你用vi等编辑器打开看的话,内容很简单,是用来记录该库的默认字符集编码和字符集排序规则用的。也就是说如果你创建数据库指定默认字符集和排序规则,那么后续创建的表如果没有指定字符集和排序规则,那么该新建的表将采用db.opt文件中指定的属性。
/*
Set table default charset, if not set
SYNOPSIS
set_table_default_charset()
create_info Table create information
DESCRIPTION
If the table character set was not given explicitely,
let’s fetch the database default character set and
apply it to the table.
*/
static void set_table_default_charset(THD *thd,
HA_CREATE_INFO *create_info, char *db)
{
/*
If the table character set was not given explicitly,
let’s fetch the database default character set and
apply it to the table.
*/
if (!create_info->default_table_charset)
{
HA_CREATE_INFO db_info;
load_db_opt_by_name(thd, db, &db_info);
create_info->default_table_charset= db_info.default_table_charset;
}
}
另外要说明的是,如果你是通过alter databases(schema) 命令更改的数据库默认属性,那么现有的表的默认字符集和排序规则不受影响。
通过创建数据库指定数据库的默认字符集和排序规则:
create_specification:
[DEFAULT] CHARACTER SET [=] charset_name
| [DEFAULT] COLLATE [=] collation_name
也可以通过alter database修改
alter_specification:
[DEFAULT] CHARACTER SET [=] charset_name
| [DEFAULT] COLLATE [=] collation_name
MySQL Cluster ndb 引擎每行存储的实际长度最大为8052个字节。Blob和Text字段在ndb engine中只存储前面的256个字节。超过256自己部分存储在另外的隐藏表里面。根据字段类型,隐藏表分3种大小(chunk size)。
假如一个LongBlob字段是10,000个字节,那么需要2个chunk,第一个存储8000字节,另外一个存储剩下的2000字节。
因此为了提高效率,如果我们存储的字段在8k(约)以内,那么在不超过8052字节限制的情况下,可以考虑用varbinary存储。比如比较典型的应用 session 管理。
MySQL5.1开始支持表分区,但是是水平分区,包括hash, list, range 等。
例如分区前:
分区后:
+—-+———+————-+——————+
| id | title | description | author |
+—-+———+————-+——————+
| 5 | title05 | desc05 | ivan@mysqlab.net |
| 6 | title06 | desc06 | ivan@mysqlab.net |
| 7 | title07 | desc07 | ivan@mysqlab.net |
| 8 | title08 | desc08 | ivan@mysqlab.net |
+—-+———+————-+——————+
VP存储引擎(vertical partitioning storage engine)支持垂直分区,将不同的表根据主键作join,而且还支持不同存储引擎的表,甚至原有的表还可以带有水平分区。
详情请参考:https://launchpad.net/vpformysql
这几天在中国移动音乐基地(四川成都)这儿培训MySQL Developer课程,当中萌生了个想法,采用提问的方式,然后筛选出合适的命题做介绍。
比如:MySQL是如何使用内存和磁盘的?
呵呵,被骗进来的朋友别生气,今天实在是太晚了,明早还要去上课,明后天补上。
这篇是普及MySQL基本知识的,介绍MySQL是如何使用磁盘和内存的,从手册上可以找到。
磁盘空间的占用:
内存的占用:

最近一直在学习研究MySQL Cluster,今天正好也看到消息说支付宝在测试IBM DB2 Cluster,16个数据居节点,1个管理节点,采用万兆网卡连接。DB2 Cluster跟MySQL Cluster采用同样的share-nothing构架,网络对它来说至关重要。
但是我这里要说的是,虽然MySQL Cluster发展到今天已经取得很大的成就,性能翻了好几倍,也开始支持磁盘存储(非主键、索引),但是它有致命的弱点:不支持真正的ACID(整个机群down掉的时候,最新GCP之后提交的事务丢失),不支持在线热备(备份的时候需要停止其他请求–single user mode,防止备份数据损坏)…
话说回来,虽然缺点还不止上面提到的这些,在很多情景下不适合使用,但是不可否定它的高明。在高可用和写负载均衡上它的确是性价比很高的解决方案,比如session(Ivan)管理、用户管理等。
这几天要考试,等过阵子陆续写一些有关MySQL Cluster的文章,做下MySQL Cluster的普及和推广。
MySQL5.1 引入表分区功能,使得MySQL在处理大表的能力上得到增强。使用过表分区功能的朋友应该知道,MySQL5.1中使用表分区的时候,对字段是有要求的,那就是必须是整数型,或者可以将其他类型的字段通过函数转换成整数型才可以。
SHOW CREATE TABLE mysqlab_net\G
*************************** 1. row ***************************
TABLE: mysqlab_net
CREATE TABLE: CREATE TABLE `mysqlab_net` (
`ivan` date DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1
/*!50100 PARTITION BY RANGE (TO_DAYS(ivan))
(PARTITION p01 VALUES LESS THAN (733261) ENGINE = InnoDB,
PARTITION p02 VALUES LESS THAN (733627) ENGINE = InnoDB,
PARTITION p03 VALUES LESS THAN (733992) ENGINE = InnoDB,
PARTITION p04 VALUES LESS THAN MAXVALUE ENGINE = InnoDB) */
怎么样?读取的时候谁知道那个数字是多少?(不过也可以通过自定义函数实现还原)
MySQL5.5中加入了columns关键字,使得可读性好多了。看例子
SHOW CREATE TABLE `mysqlab.net`\G
*************************** 1. row ***************************
TABLE: mysqlab.net
CREATE TABLE: CREATE TABLE `mysqlab.net` (
`ivan` date DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1
/*!50500 PARTITION BY RANGE COLUMNS(ivan)
(PARTITION p01 VALUES LESS THAN (’2007-08-08′) ENGINE = InnoDB,
PARTITION p02 VALUES LESS THAN (’2008-08-08′) ENGINE = InnoDB,
PARTITION p03 VALUES LESS THAN (’2009-08-08′) ENGINE = InnoDB,
PARTITION p04 VALUES LESS THAN (MAXVALUE) ENGINE = InnoDB) */
另外MySQL5.5表分区(partition) columns关键字还支持多字段,比如 partition by range columns(a,b);将支持清空指定的分区TRUNCATE PARTITION。MySQL5.5有望在明年(2010)夏季GA。另外MySQL5.5支持的半同步功能在高可用上的使用,让人非常期待!
Reference: MySQL 5.5 partitioning enhancements
Note:在使用表分区的时候,并不是分区越多越好,要根据情况而定,因为会出现意想不到的问题。
MySQL 5.5第一个版本释出,基于MySQL5.4,性能相对于当前MySQL5.0、5.1有很大的提升,更让人可喜的是MySQL5.5内置了Google的半同步(semi-sync-replication)补丁,以此可以搭建一个相对来说比较完美的MySQL高可用方案,之前我已经在“MySQL新版(5.x)及特性”中提到过,很是让人期待!
半同步的配置很简单:
master > INSTALL PLUGIN rpl_semi_sync_master SONAME ‘libsemisync_master.so’;
slave-x > INSTALL PLUGIN rpl_semi_sync_slave SONAME ‘libsemisync_slave.so’;
master > SET GLOBAL rpl_semi_sync_master_enabled=1;
slave-x > SET GLOBAL rpl_semi_sync_slave_enabled=1;
对于半同步需要说明的是:
1:不需要所有的slave都确认接收到复制事件
2:slave确认并不是表示执行完成
3:如果slave没有跟上同步设置将被中断继续原来的异步模式直到跟上再重新开启
注意:当前MySQL5.4, MySQL5.5都还不是GA版本,生产环境请慎重选择,升级前也请备份好数据。
MySQL 5.1.42 预计在今年(2009)12月18日发布,其中会包含最新的Innodb Plugin。新的InnoDB Plugin在除了支持Data compression和Fast index create特性之外,兼容之前的表空间,并加入了大量Google的patch,极大的提高了Innodb的性能。
MySQL 5.4 GA 预计可能在明年夏季,roadmap如下图:

MySQL 5.5 会加入Google semi-replication patch,Google原链接。
MySQL Cluster Manager 加入自动管理功能,不过应该会收费。
———————————————-
这几天去fetion看了他们的DB,服务器奢侈(可能穷惯了),性能也很强劲30k+的QPS。不过构架有些问题,以后我想应该会改;另外还去了现场帮客户解决问题。至此来北京的计划全部打乱。下次一定提前安排,组织一次MySQL实验室聚会。
MySQL Cluster, MySQL Innodb, MySQL Replication, news / tools
geographic-replication-deep-dive(PDF)下载
其中异构复制的时候有些技巧,比如 不同的mysqld只复制一部分表,从而避免延时的出现。
上面是Gearman的一个角色功能图,它在整个系统体系里面担任中间代理人的作用,负责接收和分配任务并返回结果。这样它能很好的胶合各个子系统从而实现项目目标。
之所以介绍这个,我是想将它用到MySQL的监控管理备份平台上,DB服务器上运行worker daemon连接到管理节点上,这样需要对DB进行动作的时候,只要在管理节点上通过gearman下达任务即可,而且不同的地方可以用最合适的语言去实现,实现开发效率和运行效率的平衡和统一。开发人员能给我们带来这么好的东东,实乃大幸。Gearman可用的地方非常多,它在一定程度上开阔了人的思路,提供了一个相对通用的解决方案。
---------- ---------- ---------- ----------
| Client | | Client | | Client | | Client |
---------- ---------- ---------- ----------
\ / \ /
\ / \ /
-------------- --------------
| Job Server | | Job Server |
-------------- --------------
| |
----------------------------------------------
| | | |
---------- ---------- ---------- ----------
| Worker | | Worker | | Worker | | Worker |
---------- ---------- ---------- ----------
Gearman的官方网站在这里
2009-11-19 02:00 (+8:00) 的web presentation,里面介绍了InfiniDB(基于列的事务存储引擎)
Building High-Performance MySQL Query Systems and Analytic Applications PPT下载(PDF)
前段时间看innodb plugin源码的时候,看到有如下一段
include/univ.i
/* Maximum number of parallel threads in a parallelized operation */
#define UNIV_MAX_PARALLELISM 32
尝试将 UNIV_PAGE_SIZE_SHIFT 改成13 (相当于page size为8K),编译通过并可以正常使用。
后来找到Google的MySQL团队发表的一篇文章,文中的介绍 Innodb page size 可以选择 8K、 16K、 32K、 64K。不过因为Innodb每个page都有不小的冗余空间,从空间和内存利用的角度来讲,page size越大越好。但是从checkpoint的角度来讲恰恰相反,page size越小,性能越好(上次演讲的时候我介绍过原理)。所以最后选择多大的page size可以根据实际的业务测试而定。
最近评论