Archive for September, 2008
MySQL Replication(复制)基本原理
Wednesday, September 24th, 2008
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、复制常用架构
Mysql复制环境90%以上都是一个Master带一个或者多个Slave的架构模式，主要用于读压力比较大的应用的数据库端廉价扩展解决方案。因为只 要master和slave的压力不是太大（尤其是slave端压力）的话，异步复制的延时一般都很少很少。尤其是自slave端的复制方式改成两个进程 处理之后，更是减小了slave端的延时。而带来的效益是，对于数据实时性要求不是特别的敏感度的应用，只需要通过廉价的pc [...]
MySQL单表到底可以多大
Thursday, September 18th, 2008
前天突然收到Monitor Center发出来的报警：
PROBLEM:CN_DSL_***4/MAXFILE is CRITICAL,SNMP CRITICAL - *These File size is larger than 18932735283: /abc/def/ghi/***/***.MYD
刚看到这个报警的时候，还吓了一跳。数据文件超过最大文件限制？不会吧？好像才18G嘛，怎么会就开始报警了？
于是开始查找报警来源，经过一番查找，总算找到监控脚本。这台机器之前是SA管理维护的，所以相关规范也是按照SA管理的web服务器来设计的。所以他们 在监控系统中添加了某些特定的目录下文件大小的限制，防止某些意外出现大文件的情况。最后我只得在监控脚本中过滤掉了MySQL的“.MYD”和 “.MYI”文件。
说到文件大小，刚好常有人问我说MySQL是否有单个表的大小限制？限制多大呢？这里做一个简单的介绍吧。
在老版本的MySQL 3.22中，MySQL的单表限大小为4GB，当时的MySQL的存储引擎还是ISAM存储引擎。但是，当出现MyISAM存储引擎之后，也就是从 MySQL 3.23开始，MySQL单表最大限制就已经扩大到了64PB了（官方文档显示）。也就是说，从目前的技术环境来看，MySQL数据库的MyISAM存储 引擎单表大小限制已经不是有MySQL数据库本身来决定，而是由所在主机的OS上面的文件系统来决定了。
而MySQL另外一个最流行的存储引擎之一Innodb存储数据的策略是分为两种的，一种是共享表空间存储方式，还有一种是独享表空间存储方式。
当使用共享表空间存储方式的时候，Innodb的所有数据保存在一个单独的表空间里面，而这个表空间可以由很多个文件组成，一个表可以跨多个文件存在，所 以其大小限制不再是文件大小的限制，而是其自身的限制。从Innodb的官方文档中可以看到，其表空间的最大限制为64TB，也就是说，Innodb的单 表限制基本上也在64TB左右了，当然这个大小是包括这个表的所有索引等其他相关数据。
而当使用独享表空间来存放Innodb的表的时候，每个表的数据以一个单独的文件来存放，这个时候的单表限制，又变成文件系统的大小限制了。
以下是从收集到的一点信息，不一定全部准确：
操作系统 大小限制
win32 w/ FAT/FAT32 2GB/4GB
win32 w/ NTFS 2TB（可能更大）
Linux 2.2-Intel 32-bit 2GB (LFS: 4GB)
Linux 2.4+ 4TB(ext3)
Solaris 9/10 16TB
NetWare w/NSS filesystem 8TB
MacOS X w/ HFS+ 2TB
以下是MySQL文档中的内容：
Windows用户请注意： FAT和VFAT (FAT32)不适合MySQL的生产使用。应使用NTFS。
在默认情况下，MySQL创建的MyISAM表允许的最大尺寸为4GB。你可以使用SHOW TABLE STATUS语句或myisamchk -dv tbl_name检查表的最大尺寸。请参见13.5.4节，“SHOW语法”。
如果需要使用大于4GB的MyISAM表（而且你的操作系统支持大文件），可使用允许AVG_ROW_LENGTH和MAX_ROWS选项的CREATE TABLE语句。创建了表后，也可以使用ALTER TABLE更改这些选项，以增加表的最大允许容量。
原文首发： Sky.Jian 朝阳的天空
原文链接：MySQL单表到底可以多大
自己搞了函数行专列还是可以拼接
Saturday, September 13th, 2008
今天有个需求，要求把一个表里的根据一列（例如id）分组并且将每行的任意几列的数据挨着拼装在一起中间加特殊字符，
然后分组之后每个id对应的几行合成一条记录，例如：
SQL> select * from test;
P_ID NAME VALUE
———- ——————– ——————–
1 AAA aaa
2 BBB bbb
1 ABC abc
3 CCC ccc
2 DDD ddd
SQL> SELECT P_ID, Mystrcat_n(NAME||chr(01)||value) NAME FROM TEST GROUP BY P_ID;
P_ID
———-
NAME
——————————————————————————–
1
AAAaaaABCabc
2
BBBbbbDDDddd
3
CCCccc
寻求Sky.Jian（简朝阳）帮助，给我了一个他自己搞的一个函数，结果不满足我的要求，
在他的基础上修改一下，可以满足以上要求，中间是用chr(01)来分隔的，函数体如下：
（执行此函数到底消耗多少资源没有测试过）
create or replace type Mystrcat_new as object
(
str varchar2(4000),
static function ODCIAggregateInitialize(sctx IN OUT Mystrcat_new) return number,
member function ODCIAggregateIterate(self IN OUT Mystrcat_new,value IN varchar2) return number,
member function ODCIAggregateTerminate(self IN Mystrcat_new,returnValue [...]
ASM Lib包务必注意小版本啊
Friday, September 12th, 2008
这件事是我太大意了，前几天装ASM的RPM包，怎么搞都搞不上去。我迷茫了好几天。到configure最后一步总是过不去，还调整了N多的OS参数，还上metalink上去查。报的错误是这样的：
[root@localhost wt]# /etc/init.d/oracleasm configure
Configuring the Oracle ASM library driver.
This will configure the on-boot properties of the Oracle ASM library
driver. The following questions will determine whether the driver is
loaded on boot and what permissions it will have. The current values
will be shown in brackets (’[]‘). Hitting <ENTER> without typing an
answer will keep that current value. Ctrl-C [...]
oracle 11g standby query error: ora-08103 and ora-01410
Wednesday, September 3rd, 2008
范鑫做的测试，我转过来。看起来很简单的一件事情，由于具有偶然性，不能每次都重现，所以特地记录下来，一直报的 ORA-08103: object no longer exists 是由于 standby 上的查询进程导致 ，把standby 激活后查询就正常了
当然这里要交代一下前提，就是在主数据库上有一个job，每天晚上将一个表truncate再插入数据，第二天就发现standby上查询错误，在主数据库上move表之后恢复正常。 但是手工做 truncate却取法重现，重新做个job任务偶尔重现，也不是一定得到这个现象。目前正在进一步测试中，但至少发现了 11g的 standby提供适时查询功能是存在缺陷的。当然不truncate就没问题。
测试在一个已经存在问题的standby上进行，先以standby模式open，再open read only，最后激活open：
oracle@ctr_db1:/home/oracle>export ORACLE_SID=testctrdmsb2
oracle@ctr_db1:/home/oracle>sqlplus /nolog
SQL*Plus: Release 11.1.0.6.0 - Production on Wed Sep 3 10:28:45 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
@>
@>sqlplus /nolog
SP2-0734: unknown command beginning “sqlplus /n…” - rest of line ignored.
@>conn / as sysdba
Connected.
sys@CTRDM_DB1>
sys@CTRDM_DB1>select count(*) from mcc.sync_job_status;
select count(*) [...]
如何恢复被删除的表空间？
Tuesday, September 2nd, 2008
前几天看到论坛上有人问，看到大家都是纸上谈兵，我做了个example。
下载地址：
删除表空间恢复.pdf
