2008年10月11日星期六
Mysql Replication(MySQL主从复制)介绍
Mysql Replication(MySQL主从复制)是MySQL数据库使用率非常高的一种技术,它使用某个数据库服务器为主,然后在其他数据库服务器上进行复制,后面复制的数据库也称从数据库。MySQL支持单向、异步复制,复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器。在设置链式复制服务器时,从服务器本身也可以充当主服务器,如:a->b->c,b对于a来说是从服务器,但是它又是c的主服务器。Mysql Replication(MySQL主从复制)主要用于:
1.使用一个从服务器执行备份,而不会干扰主服务器。在备份过程中主服务器可以继续处理更新;
2.解决数据库读需求很高的情况:Mysql复制架构绝大部分都是使用一个主服务器(Master)带一个或者多个从服务器(Slave)的架构模式,这样可以适用于读压力比较大的应用,这样的架构里面只要master和slave的压力不是太大(尤其是slave端压力)的话,异步复制的延时一般都可以容忍的。
尤其是自slave端的复制方式改成两个进程处理之后,更是减小了slave端的延时。而带来的效益是,对于数据实时性要求不是特别的敏感度的应用,只需要通过廉价的pc server来扩展slave的数量,将读压力分散到多台slave的机器上面,即可解决数据库端的读压力瓶颈。这在很大程度上解决了目前很多中小型网站的数据库压力瓶颈问题,甚至有些大型网站也在使用类似方案解决数据库瓶颈。这个架构方案的实施也会比较廉价同时易于扩展。
甚至还可以使用第三方软件来专门将MySQL的读写进行分离。这类软件有:MySQL Proxy及Amoeba。
二、Mysql Replication(MySQL主从复制)的原理:
1、复制进程Mysql的复制(replication)是一个异步的复制,从一个Mysql instace(称之为Master)复制到另一个Mysql instance(称之Slave)。实现整个复制操作主要由三个进程完成的,其中两个进程在Slave(Sql进程和IO进程),另外一个进程在Master(IO进程)上。
要实施复制,首先必须打开Master端的binary log(bin-log)功能,否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。复制的基本过程如下:
1)、Slave上面的IO进程连接上Master,并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容;
2)、Master接收到来自Slave的IO进程的请求后,通过负责复制的IO进程根据请求信息读取制定日志指定位置之后的日志信息,返回给Slave的IO进程。返回信息中除了日志所包含的信息之外,还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置;
3)、Slave的IO进程接收到信息后,将接收到的日志内容依次添加到Slave端的relay-log文件的最末端,并将读取到的Master端的bin-log的文件名和位置记录到master-info文件中,以便在下一次读取的时候能够清楚的高速Master“我需要从某个bin-log的哪个位置开始往后的日志内容,请发给我”;
4)、Slave的Sql进程检测到relay-log中新增加了内容后,会马上解析relay-log的内容成为在Master端真实执行时候的那些可执行的内容,并在自身执行。
实际上在老版本的Mysql的复制实现在Slave端并不是两个进程完成的,而是由一个进程完成。但是后来发现这样做存在较大的风险和性能问题,主要如下:
首先,一个进程就使复制bin-log日志和解析日志并在自身执行的过程成为一个串行的过程,性能受到了一定的限制,异步复制的延迟也会比较长。另外,Slave端从Master端获取bin-log过来之后,需要接着解析日志内容,然后在自身执行。在这个过程中,Master端可能又产生了大量变化并声称了大量的日志。如果在这个阶段Master端的存储出现了无法修复的错误,那么在这个阶段所产生的所有变更都将永远无法找回。如果在Slave端的压力比较大的时候,这个过程的时间可能会比较长。
所以,后面版本的Mysql为了解决这个风险并提高复制的性能,将Slave端的复制改为两个进程来完成。提出这个改进方案的人是Yahoo!的一位工程师“Jeremy Zawodny”。这样既解决了性能问题,又缩短了异步的延时时间,同时也减少了可能存在的数据丢失量。
当然,即使是换成了现在这样两个线程处理以后,同样也还是存在slave数据延时以及数据丢失的可能性的,毕竟这个复制是异步的。只要数据的更改不是在一个事物中,这些问题都是会存在的。
如果要完全避免这些问题,就只能用mysql的cluster来解决了。不过mysql的cluster是内存数据库的解决方案,需要将所有数据都load到内存中,这样就对内存的要求就非常大了,对于一般的应用来说可实施性不是太大。
2、复制实现级别Mysql的复制可以是基于一条语句(Statement level),也可以是基于一条记录(Row level),可以在Mysql的配置参数中设定这个复制级别,不同复制级别的设置会影响到Master端的bin-log记录成不同的形式。
Row Level:日志中会记录成每一行数据被修改的形式,然后在slave端再对相同的数据进行修改。优点:在row level模式下,bin-log中可以不记录执行的sql语句的上下文相关的信息,仅仅只需要记录那一条记录被修改了,修改成什么样了。所以row level的日志内容会非常清楚的记录下每一行数据修改的细节,非常容易理解。而且不会出现某些特定情况下的存储过程,或function,以及trigger的调用和触发无法被正确复制的问题。
缺点:row level下,所有的执行的语句当记录到日志中的时候,都将以每行记录的修改来记录,这样可能会产生大量的日志内容,比如有这样一条update语句:update product set owner_member_id = ‘b’ where owner_member_id = ‘a’,执行之后,日志中记录的不是这条update语句所对应额事件(mysql以事件的形式来记录bin-log日志),而是这条语句所更新的每一条记录的变化情况,这样就记录成很多条记录被更新的很多个事件。自然,bin-log日志的量就会很大。尤其是当执行alter table之类的语句的时候,产生的日志量是惊人的。因为Mysql对于alter table之类的表结构变更语句的处理方式是整个表的每一条记录都需要变动,实际上就是重建了整个表。那么该表的每一条记录都会被记录到日志中。
Statement Level:每一条会修改数据的sql都会记录到 master的bin-log中。slave在复制的时候sql进程会解析成和原来master端执行过的相同的sql来再次执行。优点:statement level下的优点首先就是解决了row level下的缺点,不需要记录每一行数据的变化,减少bin-log日志量,节约IO,提高性能。因为他只需要记录在Master上所执行的语句的细节,以及执行语句时候的上下文的信息。缺点:由于他是记录的执行语句,所以,为了让这些语句在slave端也能正确执行,那么他还必须记录每条语句在执行的时候的一些相关信息,也就是上下文信息,以保证所有语句在slave端杯执行的时候能够得到和在master端执行时候相同的结果。
另外就是,由于Mysql现在发展比较快,很多的新功能不断的加入,使mysql得复制遇到了不小的挑战,自然复制的时候涉及到越复杂的内容,bug也就越容易出现。在statement level下,目前已经发现的就有不少情况会造成mysql的复制出现问题,主要是修改数据的时候使用了某些特定的函数或者功能的时候会出现,比如:sleep()函数在有些版本中就不能真确复制,在存储过程中使用了last_insert_id()函数,可能会使slave和master上得到不一致的id等等。由于row level是基于每一行来记录的变化,所以不会出现类似的问题。从官方文档中看到,之前的Mysql一直都只有基于statement的复制模式,直到5.1.5版本的Mysql才开始支持row level的复制。
从5.0开始,Mysql的复制已经解决了大量老版本中出现的无法正确复制的问题。但是由于存储过程的出现,给Mysql的复制又带来了更大的新挑战。
另外,从5.1.8版本开始,Mysql提供了除Statement Level和Row Level之外的第三种复制模式:Mixed,实际上就是前两种模式的结合。在Mixed模式下,Mysql会根据执行的每一条具体的sql语句来区分对待记录的日志形式,也就是在Statement和Row之间选择一种。新版本中的Statment level还是和以前一样,仅仅记录执行的语句。而新版本的Mysql中队row level模式也被做了优化,并不是所有的修改都会以row level来记录,像遇到表结构变更的时候就会以statement模式来记录,如果sql语句确实就是update或者delete等修改数据的语句,那么还是会记录所有行的变更。
3、复制常用架构
一个Master带多个slave的架构实施非常简单,多个slave和单个slave的实施并没有太大区别。在Master端并不care有多少个slave连上了master端,只要有slave进程通过了连接认证,向他请求binlog信息,他就会按照连接上来的io进程的要求,读取自己的binlog信息,返回给slave的IO进程。对于slave的配置细节,在Mysql的官方文档上面已经说的很清楚了,甚至介绍了多种实现slave的配置方法。
Mysql不支持一个Slave instance从属于多个Master的架构。就是说,一个slave instance只能接受一个master的同步源,听说有patch可以改进这样的功能,但没有实践过。Mysql AB之所以不实现这样的功能,主要是考虑到冲突解决的问题。
Mysql也可以搭建成dual master模式,也就是说两个Mysql instance互为对方的Master,也同时为对方的Slave。
不过一般这种架构也是只有一端提供服务,避免冲突问题。因为即使在两边执行的修改有先后顺序,由于复制的异步实现机制,同样会导致即使在晚做的修改也可能会被早做的修改所覆盖,就像如下情形:时间点 Mysql A Mysql B1 更新x表y记录为102 更新x表y记录为203 获取到A日志并应用,更新x表的y记录为10(不符合期望)4 获取B日志更新x表y记录为20(符合期望)这样,不仅在B库上面的数据不是用户所期望的结果,A和B两边的数据也出现了不一致的情况。除非能将写操作根据某种条件固定分开在A和B两端,保证不会交叉写入,才能够避免上面的问题。
三、一些相关的扩展和管理脚本
Google的SemiSyncReplication扩展
MySQL Community Replication Monitoring System
Maatkit的管理脚本MySQL Master-Master Replication Manager (Google Code)
MySQL Replication Manager (Google Code)
四、参考文档
官方文档--第6章:MySQL中的复制官方文档--Chapter 15. Replication
MySQL Replication(复制)基本原理--Sky.Jian
五、其他参考
Mysql Proxy简介
MySQL Community Replication Monitoring System
Mysql 管理工具集 maatkit
2008年10月10日星期五
SHELL水平测试OVERVIEW篇部分答案
原题目地址:http://bbs.chinaunix.net/viewthread.php?tid=476260
(2)C Shell是加州伯克利大学的Bill Joy为BSD Unix开发的,与sh不同,它的语法与C语言很相似。它提供了Bourne Shell所不能处理的用户交互特征,如命令补全、命令别名、历史命令替换等。但是,C Shell与BourneShell并不兼容。
(3)Korn Shell是AT&T Bell实验室的David Korn开发的,它集合了C Shell和Bourne Shell的优点,并且与Bourne Shell向下完全兼容。Korn Shell的效率很高,其命令交互界面和编程交互界面都很好。
(4)Bourne Again Shell (即bash)是自由软件基金会(GNU)开发的一个Shell,它是Linux系统中一个默认的Shell。Bash不但与Bourne Shell兼容,还继承了C Shell、Korn Shell等优点。
A: 在此我们主要讨论Bourne shell及其兼容shell。在许多情况下shell会在子shell中执行命令:
1.(...)结构
小括号内的命令会在一个子shell环境中执行,命令执行的结果不会影响当前的shell环境。需要注意是此时变量$$会显示当前shell的进程id,而不是子shell的进程id。
参考:
{...;}结构中的命令在当前shell中执行,(内部)命令执行的结果会影响当前的shell环境。
a.使用临时文件
...
#in subshell
a=100
echo "$a">tmpfile
...
#in parent
read b
b.使用命名管道
mkfifo pipef
(...
echo "$a" > pipef
...)
read b
c.使用coprocess(ksh)
( echo "$a" &)
read -p b
d.使用命令替换
b=`echo "$a"`
e.使用eval命令
eval `echo "b=$a"`
f.使用here document
read b <`echo "$a"`
END
g.使用here string(bash/pdksh)
read b <<<`echo "$a"`
shell
BLOCK
方法二:
if then fi 结构来屏蔽
以下题目暂无答案
Cacti的Mysql模板
Cacti是一款非常强大的系统监视工具,同样强大的还有它的可扩展性,在它的论坛里有上百种的各种设备、软件、服务的监视模板被发表、分享。这里给大家介绍一款专门用于查看Mysql各种状态的模板:mysql-cacti-templates ,它是Google Code的一个项目。
地址:http://code.google.com/p/mysql-cacti-templates/
监视图片的演示:http://www.xaprb.com/blog/2008/05/25/screenshots-of-improved-mysql-cacti-templates/
安装方式:
1.准备工作:下载和解压
2.在Mysql中创建有SUPER权限的用户,并设定密码和赋予相应的登录位置;
3.将ss_get_mysql_stats.php 放到 cacti/scripts/ 文件夹中;
4.在Cacti中导入cacti_host_template_x_db_server_ht.xml,再添加Mysql相关的图表即可。
注意:如需要监视多个Mysql服务器的话,尽量将每个的帐号及密码保持一直,否则需要自己需改模板。
一些MySQL Patches介绍
Google Code里面有一个google-mysql-tools项目,里面提供了一些MySQL的工具,以及提供了对MySQL 4和 MySQL 5做了大量功能扩展后的补丁。
其中对MySQL4系列的功能扩展详情请见:http://code.google.com/p/google-mysql-tools/wiki/Mysql4Patches
其中对MySQL5系列的功能扩展详情请见:http://code.google.com/p/google-mysql-tools/wiki/Mysql5Patches
整个项目的地址:http://code.google.com/p/google-mysql-tools/
ebay对MySQL做的扩展
地址:http://code.google.com/p/mysql-heap-dynamic-rows/
另外,还有一个专门从事MySQL的Team,其中包括了《High Performance MySQL Second Edition》的作者,他们在google和其他组织发布的补丁包上进行进一步的扩展MySQL。
他们的官方网址是:http://www.percona.com/
发布补丁的地址:http://www.percona.com/percona-lab.html
还可以参考:http://www.mysqlperformanceblog.com/mysql-patches/
2008年9月29日星期一
Mysql Proxy简介
Mysql Proxy运行于程序和数据库之间,可以将所有发给数据库的请求经过她的处理后转发给事先设定的数据库。它可以用来分析、监控和变换(transform)通信数据,它支持非常广泛的使用场景:
负载平衡和故障转移处理
查询分析和日志
SQL宏(SQL macros)
查询重写(query rewriting)
执行相关命令
读写分离
比较特别的是Mysql Proxy的脚本语言是Lua。
下载页面:http://dev.mysql.com/downloads/mysql-proxy/index.html
文档页面:http://dev.mysql.com/doc/refman/5.1/en/mysql-proxy.html
项目页面:http://forge.mysql.com/wiki/MySQL_Proxy
一个全是Mysql Proxy内容的blog:http://jan.kneschke.de/
2008年9月13日星期六
Mysql DBA tools--monolith
Monolith是一款类似于MySQL Enterprise Monitor的开源工具,使用PHP技术,在很大程度上可以作为替代的MySQL Enterprise Monitor的低成本解决方案。
官方地址:http://sourceforge.net/projects/monolith-mysql
MySQL Enterprise Monitor官方网址:http://www.mysql.com/products/enterprise/monitor.html
2008年9月12日星期五
Mysql集群安装脚本ndbinstaller
地址:http://www.jimdowling.info/ndbinstaller-trac
下载:wget http://www.jimdowling.info/ndbinstaller/trunk/ndbinstaller.sh
SVN地址:svn co http://www.jimdowling.info/ndbinstaller/trunk/ ndbinstaller