Coredump的设置和2个文件相关。在/proc/sys/kernel目录下：

/proc/sys/kernel/core_pattern文件设置core文件的保存路径和文件名称，pattern可使用参数：

%p – insert pid into filename

%u – insert current uid into filename

%g – insert current gid into filename

%s – insert signal that caused the coredump into the filename

%t – insert UNIX time that the coredump occurred into filename

%h – insert hostname where the coredump happened into filename

%e – insert coredumping executable name into filename

core文件统一在/data/coredump目录下产生，格式为core_进程名_时间戳

/proc/sys/kernel/core_pattern中的默认内容是core，表示core文件生成在可执行程序所在目录，文件名叫core。新的core就会覆盖旧的core文件。

/proc/sys/kernel/core_users_pid控制core文件是否加pid作为core_pattern中约定文件名称的扩展名。表示添加pid作为扩展名，生成的core文件格式为core.xxxx；为0则表示生成的core文件同一命名为core_pattern。该文件内容默认值是0。

再加上core_pattern 的设置，core文件统一在/data/coredump目录下产生，格式为core_进程名_时间戳.进程号

 

使用ulimit -c查看core文件生成开关。若为0则表示不会生成core文件。

使用ulimit -c size设置core文件的大小限制，size的单位是kbyte。若要想core文件大小不受限制，则使用ulimit -c unlimited

有了core文件。使用gdb加载调试：

       gdb –c core文件名 可执行程序名

Base64是用64个可见字符表示任意字节编码方式。

Base64在RFC2045的section 6.8（The Base64 Content-Transfer-Encoding is designed to represent arbitrary sequences of octets in a form that need not be humanly readable）定义：Base64内容传送编码被设计用来把任意序列的8位字节描述为一种不易被人直接识别的形式。

相对于Base64，还有Base16、Base32编码方式，可以参见RFC3548（The Base16, Base32, and Base64 Data Encodings）。

Base64编码应用：电子邮件编码传输、广告点击跳转加密编码串、Cookie串二进制内容编码。

 

一个字节的编码范围是[0x00, 0xff]，共8个位，256个字符（可称为一个八位组或Base256）。

Base64的编码范围是[0x00, 0x3f]，共6个位，64个字符（也为一个六位组）。

Base64的编码过程就是把八位组变成六位组的过程，每三个8bit的字节转换为四个6bit的字节（3*8 = 4*6 = 24），然后把6bit再添两位高位0，组成四个8bit的字节。也就是说，转换后的字符串理论上要比原来的长1/3（3字节编码成4字节）。

Base64使用的映射字符：

编码	字符	编码	字符	编码	字符	编码	字符
0	A	17	R	34	i	51	z
1	B	18	S	35	j	52	0
2	C	19	T	36	k	53	1
3	D	20	U	37	l	54	2
4	E	21	V	38	m	55	3
5	F	22	W	39	n	56	4
6	G	23	X	40	o	57	5
7	H	24	Y	41	p	58	6
8	I	25	Z	42	q	59	7
9	J	26	a	43	r	60	8
10	K	27	b	44	s	61	9
11	L	28	c	45	t	62	+
12	M	29	d	46	u	63	/
13	N	30	e	47	v
14	O	31	f	48	w	pad	=
15	P	32	g	49	x
16	Q	33	h	50	y

pad是填充字符，当转换字节不是3的倍数时，就用pad字符填充补齐。填充字符数=转换字节数 MOD 3。第62，63，pad字符可以根据使用场合来自定义。譬如在URL串里，=表示特殊意义，就不能使用=作为填充字符。

 

如果字节串是3的倍数，刚好对齐。下面是3字节编码成4字节：

转换前bit内容	12345678	12345678	12345678
转换后bit内容	00123456	00781234	00567812	00345678

如果字节串不是3的位数，不足的bit用0填充，不足的字节使用填充字符。下面是2字节编码成4字节：

转换前bit内容	12345678	12345678	pad
转换后bit内容	00123456	00781234	00567800	=

如：“张”占用2个字节，字节内容是：11010101 11000101，16进制（Base16）表示就是：D5C5。编码成Base64，需要使用填充字符补齐成3字节再编码，编码结果是1iU=

转换前bit内容	11010101	11000101	pad
转换后bit内容	00110101	00011100	00010100	=
转换后字符	1（53）	i（34）	U（20）	=

 

第一个字符通过右移2位获得第一个目标字符的Base64表位置，根据这个数值取到表上相应的字符，就是第一个目标字符。

然后将第一个字符左移4 位加上第二个字符右移4位，即获得第二个目标字符。

再将第二个字符左移2位加上第三个字符右移6位，获得第三个目标字符。

最后取第三个字符的右6位即获得第四个目标字符。

在以上的每一个步骤之后，再把结果与 0×3f 进行 AND 位操作，就可以得到编码后的字符了。

如果原文字节数不是3的倍数，补齐尾部不足的字节使用填充字符。

长时间运行的Mysql服务器，运行flush status;可以重置一些计数器优化性能。

例如DB服务器是4核16G内存，通过状态变量，可以优化Mysql静态变量和SQL：

 

参数	说明
基本情况
Connections	连接服务器(不管是否成功)的次数
Uptime	服务器工作时间
Max_used_connections	同时使用的最大连接数量
Open_tables	当前打开的表的数量。
Opened_tables	已经打开的表的数量。调优静态变量表缓存数table_cache：如果open_tables接近table_cache，并且opened_tables不断增长，就需要增加table_cache的值。 table_cache是所有线程打开的表的数目(一个表使用2个文件描述符)，表数量多，就要大一些。增大该值可以增加mysqld需要的文件描述符的数量。根据数据库系统中表数量来决定该值，如2048。
线程使用情况
Threads_cached	线程缓存内的线程数
Threads_connected	当前打开的线程数
Threads_created	创建过的线程数。调优静态变量线程缓存数thread_cache：如果该值增加很快，当前thread_cache_size的值可能太小。缓存访问率是Threads_created/Connections。 服务器应缓存多少线程以便重新使用。当客户端断开连接时，如果线程少于thread_cache_size，则客户端的线程被放入缓存，一般配置8。
Threads_running	运行(非睡眠)状态的线程数
查询缓存
Qcache_free_blocks	缓存中相邻内存块的个数。数目大说明可能有碎片。调优方法：FLUSH QUERY CACHE;会对缓存中的碎片进行整理，从而得到一个空闲块，如果flush运行的时间很长，说明缓存太大了，可以适当调小静态变量query_cache_size的值。
Qcache_free_memory	缓存中剩余的内存。调优静态参数query_cache_size：如果剩余内存不足，可以增加该值，如设置query_cache_size=64M
Qcache_hits	查询缓存命中次数，该值越大越好
Qcache_inserts	插入查询缓存的次数。缓存命中率 = 1 – Qcache_hits/ Qcache_inserts。80%以上的查询缓存命中率就算合格。
Qcache_lowmem_prunes	查询缓存过低的次数。缓存出现内存不足并且必须要进行清理以便为更多查询提供空间的次数。这个数字最好长时间来看；如果这个数字在不断增长，就表示可能碎片非常严重，或者内存很少。（上面的 free_blocks 和 free_memory 可以告诉您属于哪种情况）。
Qcache_not_cached	不适合进行缓存的查询的数量，通常是由于这些查询不是 SELECT 语句。
Qcache_queries_in_cache	当前缓存的查询（和响应）的数量。
Qcache_total_blocks	缓存中块的数量。
SQL执行频率
Com_select	执行select操作次数
Com_insert	执行insert操作次数
Com_update	执行update操作次数
Com_delete	执行delete操作次数
Com_commit	事务执行commit操作次数
Comm_rollback	事务执行rollback操作次数。如果回滚频繁，就说明程序存在某些问题。
Slow_queries	慢查询的次数。调优SQL性能：如果该值增加很快，需要分析慢查询日志，针对查询SQL优化。
Innodb_rows_read	执行select返回的行数。以下几个InnoDB的。
Innodb_rows_inserted	执行insert操作的行数。通过这几个参数，可以知道数据库是查询为主还是插入为主。
Innodb_rows_updated	执行update操作的行数
Innodb_rows_deleted	执行delete操作的行数
Sort_merge_passes	排序算法已经执行的合并的数量。调优静态变量sort_buffer_size：如果该值很大，说明排序缓冲区太小，如设置sort_buffer_size = 5M 当 MySQL 必须要进行排序时，就会在从磁盘上读取数据时分配一个排序缓冲区来存放这些数据行。如果要排序的数据太大，那么数据就必须保存到磁盘上的临时文件中，并再次进行排序。
索引使用情况
Handler_read_first	使用全索引扫描的次数。如SELECT col1 FROM foo，假定col1有索引
Handler_read_key	使用索引次数，该值越高越好。
Handler_read_next	按照键顺序读下一行的请求数。使用索引描述时，从数据文件取数据的次数
Handler_read_prev	使用索引描述时，按索引倒序从数据文件取数据的次数。一般是order by/desc查询
Handler_read_rnd	查询直接操作数据文件的次数，有可能未使用索引
Handler_read_rnd_next	在数据文件中读下一行的请求数。若该值非常大，说明使用了大量的表扫描，索引使用率不高或没有使用索引。Handler_read_rnd_next/Com_select是表扫描比率，如果该值超过 4000，就应该调优静态参数read_buffer_size。如read_buffer_size=1M，若超过8M，那么就要优化SQL了。
锁使用情况
Innodb_row_lock_current_waits	当前等待行锁的行数
Innodb_row_lock_time	行锁定用的总时间(ms)
Innodb_row_lock_time_avg	行锁定的平均时间(ms)。该值大，说明锁冲突大
Innodb_row_lock_time_max	行锁定的最长时间(ms)
Innodb_row_lock_waits	行锁定必须等待的时间(ms)。该值大，说明锁冲突大

 

 

修改主服务器my.cnf，在[mysqld]中增加如下内容：

 

修改从服务器my.cnf，设置server-id=2。

另外，主从服务器的ip和端口信息配置不在my.cnf里配置，整合到后面的change master命令里。

修改了my.cnf，重启主从服务器：

 

在主服务器上，必须为从服务器创建主从复制的用户，并设置replication slave权限。所用具体命令如下：

172.25.38.145是从服务器，就通过rep用户密码为空来同步复制。通过查询user表查看Repl_slave_priv的值为Y：

 

执行完这句后，所有对主服务器数据库的更新都被挂起，直到执行UNLOCK TABLES;或者关闭当前的终端。

记录File 及Position 项的值，以便之后对从服务器进行配置。File是当前处理的binlog，Position是处理的binlog位置，这是从服务器的同步起点。

接下来是导出主服务器的数据。导出数据有两种方式：mysqldump导出需要同步的数据库和拷贝数据库数据目录。

 

Mysqldump适合数据库还不是特别大的情况。

 

拷贝文件的方式需要关闭数据，比较适合数据库庞大mysqldump比较慢的场合。注意：binlog可能非常庞大，影响文件备份速度。可以定期移走不用的binlog，通过show slave status查看当前的binlog，移走这以前的binlog。

对于MyISAM引擎，可以在不关闭数据库的情况下直接tar，但对于InnoDB事务型数据库，就麻烦一些了。商业软件InnoDB Hot Backup提供了在线备份工具，除了这个收费的工具，最简单的办法就是关闭主服务器后执行tar。

新开一个终端（不能在FLUSH TABLES WITH READ LOCK;的终端操作），关闭主服务器：

打包数据库数据目录，例如数据目录是/data/dbdata：

 

以上两种备份选择任意一种即可，把文件scp到从服务器上。

 

 

要确保文件的权限属主等设置没问题，dbdata目录应该是mysql:mysql用户所有。

 

删除dbdata下的主机信息文件和中继日志文件：

 

这里包含的信息有主机的地址和端口、主机提供的复制帐号、主机的binlog位置信息。Master_log_file和Master_log_pos是主服务器的快照信息，从服务器从该binlog的相应位置开始从主服务器同步数据。

一旦从服务器开始同步了，就能在数据文件目录下找到2个文件master.info和relay-log.info。从服务器利用这2个文件来跟踪处理了多少master的binlog。

分别在主从服务器show processlist查看连接，就可以看到rep用户的连接，可证明复制已经生效。

 

 

配置文件中my.cnf的server-id可以不修改，只要保证id不冲突就行了。

 

 

TCMalloc的原理介绍翻译：http://shiningray.cn/tcmalloc-thread-caching-malloc.html

google-perftools包括TCMalloc、heap-checker、heap-profiler和cpu-profiler共4个组件，在只用TCMalloc的场景下，可以不编译其他三个组件，使用tcmalloc_minimal就足够。

下面介绍在Linux SUSE x86上安装TCMalloc动态库的过程。

 

从 http://code.google.com/p/google-perftools/ 下载源码包，现在最新版本是1.4。如果机器联网，直接：

Mysql服务器只需要用SO动态库就可以了，没有必须要把其他的文件(头文件静态库文档等)也安装到/usr/local/里。先安装到一个临时文件夹：

加上后面的几个参数是指只生成tcmalloc_minimal。

如果要生成包含所有组件的tcmalloc，可：

使用./configure –h可查看安装选项。

使用了最小安装，拷贝tcmalloc_minimal的动态库到系统库目录：

建立软连接指向tcmalloc：

 

修改mysql服务的启动脚本mysqld_safe，在“ # executing mysqld_safe”行后添加行：

目的是在启动mysql前，加载tcmalloc动态库。

重启Mysql服务：

 

使用lsof查看mysql进程是否已经加载了tcmalloc库：

恭喜，成功安装了tcmalloc。

 

[client]

port        = 3306

socket      = /tmp/mysql.sock

# The MySQL server

[mysqld]

bind-address = 192.168.0.11

port         = 3306

socket       = /tmp/mysql.sock

 

##设置表的默认类型。和default-storage-engine同义

 

#连接进程帧听队列的大小

 

#之前有过经验，connections超过370的时候，线程的栈空间被占满，mysqld无法工作，所以限制为200

 

#连接500次发生错误之后，屏蔽从该host的所有连接

 

#通信缓冲区的最大长度。包或任何生成的/中间字符串的最大大小。

 

在查询之间将通信缓冲区重设为该值。如果语句超出该长度，缓冲区自动扩大，直到max_allowed_packet字节。

 

#避免外部锁定(默认是ON). 对应variable的skip_external_locking

 

#索引缓冲区(仅作用于MYISAM表和临时表)，决定了数据库索引处理的速度

 

#所有线程打开的表的数目(一个表使用2个文件描述符)，表数量多，就要大一些。增大该值可以增加mysqld需要的文件描述符的数量。可以检查Opened_tables(已经打开的表的数量)状态变量来检查你是否需要增加表缓存。

 

#每个排序线程分配的缓冲区的大小。增加该值可以加快ORDER BY或GROUP BY操作

 

#用于完全联接的缓冲区的大小(当不使用索引的时候使用联接操作)。

#一般情况获得快速联接的最好方法是添加索引。当增加索引时不可能通过增加join_buffer_size值来获得快速完全联接。

#将为两个表之间的每个完全联接分配联接缓冲区。对于多个表之间不使用索引的复杂联接，需要多联接缓冲区。

 

#服务器应缓存多少线程以便重新使用。当客户端断开连接时，如果线程少于thread_cache_size，则客户端的线程被放入缓存。

#如果状态变量Threads_created(创建用来处理连接的线程数)较大，你可能要增加thread_cache_size值。缓存访问率的计算方法Threads_created/Connections(试图连接到(不管是否成功)MySQL服务器的连接数)

 

#使应用程序向线程系统提供需要同时运行的期望的线程数目的提示

 

#为缓存查询结果分配的内存的数量，加快查询的速度。默认值是0，即禁用查询缓存。

 

#不要缓存大于该值的结果，默认值是1048576(1MB)。

 

#ft_min_word_len和ft_max_word_len表示FULLTEXT索引的最小和最大字长

 

#每个线程的堆栈大小

 

#事务隔离级别。READ-UNCOMMITTED: 未提交读 会出现脏读、不可重复读、幻读 ( 隔离级别最低，并发性能高 ) ；READ-COMMITTED: 提交读 会出现不可重复读、幻读问题（锁定正在读取的行）；REPEATABLE-READ: 默认值，可重复读 会出幻读（锁定所读取的所有行） ；SERIALIZABLE: 序列化 保证所有的情况不会发生（锁表）

 

#联合查询或者view的时候，可能会建立临时表，如果在磁盘上建的话，会导致性能低，设置此值可以一定程度上加快速度

 

#每个线程连续扫描时为扫描的每个表分配的缓冲区的大小,如果进行多次连续扫描，可能需要增加该值

 

#当排序后按排序后的顺序读取行时，则通过该缓冲区读取行，避免搜索硬盘。将该变量设置为较大的值可以大大改进ORDER BY的性能。但是，这是为每个客户端分配的缓冲区，因此你不应将全局变量设置为较大的值。相反，只为需要运行大查询的客户端更改会话变量。

 

# Replication Master Server (default)

#主机是1。备机从2开始。

 

#启动数据库更新二进制日志记录，日志文件名前缀为mysql-bin

 

#在事务过程中容纳二进制日志SQL语句的缓存大小，

#二进制日志缓存是服务器支持事务存储引擎并且服务器启用了二进制日志(–log-bin选项)的前提下为每个客户端分配的内存。

#如果经常使用大的，多语句事务，可以增加该值以获得更有的性能

 

#是否记录慢查询，默认OFF。用long_query_time变量的值来确定“慢查询”。

 

#超过2S的query将记slow query日志

 

#没有使用索引的查询也作为慢速查询记录到慢速日志里

 

#告诉主服务器，如果当前的数据库(即USE选定的数据库)是db_name，不应将更新保存到二进制日志中。

binlog-ignore-db = information_schema

binlog-ignore-db = cluster

binlog-ignore-db = mysql

 

#告诉从服务器限制默认数据库(由USE所选择)为db_name的语句的复制

replicate-do-db = test1

replicate-do-db = test2

 

#跨库更新表要用到如下配置。告诉从服务器线程限制复制更新的表匹配指定的数据库和表名模式的语句。模式可以包含‘%’和‘_’通配符，与LIKE模式匹配操作符具有相同的含义。要指定多个表，应多次使用该选项，每个表使用一次。该选项可以跨数据库进行更新。

replicate-wild-do-table = test1.%

replicate-wild-do-table = test2.%

 

#当Slave从Master数据库读取日志时更新新写入日志中 。如果只启动log-bin 而没有启动log-slave-updates则Slave只记录针对自己数据库操作的更新

 

#InnoDB 不会自己建立目录，必须自己使用操作系统命令建立相应的目录。检查你的 MySQL 服务程序在 datadir 目录里 有足够的权限建立文件(mysql用户组拥有)。

#这是InnoDB表的目录共用设置。如果没有设置，InnoDB 将使用MySQL的 datadir 目录为缺省目录。如果设定一个空字串,可以在 innodb_data_file_path 中设定绝对路径。

 

#单独指定数据文件的路径与大小。数据文件的完整路径由 innodb_data_home_dir 与这里所设定值的组合。 文件大小以 MB 单位指定。因此在文件大小指定后必有“M”。 InnoDB 也支持缩写“G”， 1G = 1024M。从 3.23.44 开始，在那些支持大文件的操作系统上可以设置数据文件大小大于 4 GB。而在另一些操作系统上数据文件必须小于 2 GB。

#如果用 autoextend 选项描述最后一个数据文件，当 InnoDB 用尽所有表自由空间后将会自动扩充最后一个数据文件，每次增量为8MB

#InnoDB是不会注意你的OS文件尺寸限制的， 在一些文件系统中你可能要设定最大容量2G限制：

#innodb_data_home_dir = innodb_data_file_path = /ibdata/ibdata1:100M:autoextend:max:2000M

#这里应当预先创建好10个2048M的文件，目前还没有创建

innodb_data_file_path = ibdata1:2000M;ibdata2:2000M;ibdata3:2000M;ibdata4:2000M;ibdata5:2000M;ibdata6:2000M;ibdata7:2000M;ibdata8:2000M;ibdata9:2000M;ibdata10:2000M:autoextend

 

#InnoDB 日志文件的路径。如果没有明确指定将默认在 MySQL 的 datadir 目录下建立两个 5 MB 大小的ib_logfile0和ib_logfile1文件。

#将日志文件与数据文件分别放在不同的物理硬盘中对提高性能通常是很有益的

 

#主要用来存储表结构和数据字典，表越多要求内存就越大

 

# You can set .._buffer_pool_size up to 50 – 80 %

# of RAM but beware of setting memory usage too high

#表和索引数据的内存缓冲区，越大性能越高。但不能超过物理内存的50%。若64位OS，该值可以更大

#32位OS受2G内存的限制，不能将内存使用设置太高， glibc 会把进程堆增长到线程堆栈之上，这将会使服务器崩溃。下面的接近或超过于 2G 将会很危险：

#innodb_buffer_pool_size + key_buffer +    max_connections * (sort_buffer_size + record_buffer_size + binlog_cache_size) + max_connections * 2 MB

#每个线程将使用 2MB(MySQL AB 二进制版本为 256 KB)的堆栈，在最坏的环境下还会使用 sort_buffer_size + record_buffer_size 的附加内存。

 

#InnoDB 中的文件 I/O 线程。 通常设置为 4

 

#并发线程。2*(内核数量+磁盘数量)

 

#1表示每次事务结束都写日志并刷新磁盘；2表示每次事务写日志但不刷新磁盘(每秒刷新)；0(默认值)表示每秒写日志并刷新磁盘。0表示最多丢失1秒的数据，但性能最好。

 

#InnoDB 将日志写入日志磁盘文件前的缓冲大小。理想值为 1M 至 8M。大的日志缓冲允许事务运行时不需要将日志保存入磁盘而只到事务被提交(commit)。 因此，如果有大的事务，设置大的日志缓冲可以减少磁盘I/O。

 

# Set .._log_file_size to 25 % of buffer pool size

#日志文件大小设置。增大该值可减少刷新日志频率，但会延长mysql启动和灾难恢复的时间。

#日志组中的每个日志文件的大小(单位 MB)。如果 n 是日志组(innodb_log_files_in_group)中日志文件的数目，那么理想的数值为 1M 至缓冲池(innodb_log_buffer_size)大小的 1/n。较大的值，可以减少刷新缓冲池的次数，从而减少磁盘 I/O。但是大的日志文件意味着在崩溃时需要更长的时间来恢复数据。

 

#日志组中的日志文件数目。InnoDB 以环型方式(circular fashion)写入文件。数值 3 被推荐使用

 

#InnoDB行锁导致的死锁等待时间(默认值是50S)

 

#是否支持分布式事务，关闭以提高性能(默认是ON)

 

[mysqldump]

quick

max_allowed_packet = 16M

 

[mysql]

no-auto-rehash

# Remove the next comment character if you are not familiar with SQL

#safe-updates

 

[isamchk]

key_buffer = 20M

sort_buffer_size = 20M

read_buffer = 2M

write_buffer = 2M

 

[myisamchk]

key_buffer = 20M

sort_buffer_size = 20M

read_buffer = 2M

write_buffer = 2M

 

[mysqlhotcopy]

interactive-timeout

USE test2;

UPDATE client SET name='test' WHERE uid=1;

数据未能同步到备机，而使用use  test后，才可以成功同步，如下方式：

USE test;

UPDATE client SET name='test' WHERE uid=1;

 

仔细看Mysql手册，发现同步启动选项中还有玄机，只设置replicate-do-db指定同步数据库还不够。是没有设置replicate-wild-do-table导致的跨库同步问题。Mysql默认是同步指定数据库下的更新操作，若要跨库操作更新同步，就必须指定replicate-wild-do-table参数。下面是Mysql手册中对replicate-do-db和replicate-wild-do-table启动选项的说明：

 

–replicate-do-db=db_name

告诉slave只同步那些缺省数据库是 db_name (也就是用 USE 选中的)的语句。想要指定更多的数据库，只需多次使用该选项，每次指定一个数据库。注意，类似 UPDATE some_db.some_table SET foo='bar' 这样的跨库操作语句以及没有选中数据库的操作都不会被同步。如果必须使用跨库操作，要确保使用MySQL 3.23.28或更高，并且使用 –replicate-wild-do-table=db_name.% 选项。请仔细阅读最后面的注意事项。

下面是一个不能按照预期工作的例子：如果启动slave时使用 –replicate-do-db=sales 选项，并且在master上执行下列语句，那么这个 UPDATE 语句不会被同步：

USE prices;

UPDATE sales.january SET amount=amount+1000;

如果需要同步跨库操作，只需使用 –replicate-wild-do-table=db_name.% 选项。这个"只检查缺省数据库"特性的主要原因是因为想要单从一个语句中判断是否要被同步比较困难(例如，使用多表 DELETE 或者 UPDATE，这就跨库了)。不过想要检查是否是缺省数据库却很快。

 

–replicate-wild-do-table=db_name.tbl_name

限制slave只同步那些匹配指定模式的数据表。模式中可以包含通配符 `%` 和 `_`，它们的含义和 LIKE 模式一样。想要指定更多的数据表，只需多次使用该选项，每次指定一个数据表。请仔细阅读最后面的注意事项。

例如： –replicate-wild-do-table=foo%.bar% 会同步所有以 foo 开头的数据库下的以 bar 开头的数据表上的更新操作。

如果匹配模式是 %，则匹配所有的表名，且应用到数据库级语句(CREATE DATABASE, DROP DATABASE,和 ALTER DATABASE)。例如，使用 –replicate-wild-do-table=foo%.% 选项的话，所有匹配 foo% 模式的数据库级操作都会被同步。

如果想要在数据库/表模式中包含原义通配符，需要用反斜杠来转义它们。例如，想要同步 my_own%db 数据库下的所有表，但是不想同步 my1ownAABCdb 数据库下的表，就需要转义字符 `_`： –replicate-wild-do-table=my\_own\%db。如果是在命令行中使用这个选项，就可能需要两个反斜杠来转义，这依赖于命令行解释器。例如，在 bash shell下，就需要输入： –replicate-wild-do-table=my\\_own\\%db。

 

还存在一些问题

不管有没有replicate-wild-do-table选项，更新操作必须是mysql连接已经有选择的数据库了才进行，譬如新建的mysql（新连接是没有默认选择的database的）连接中执行：

UPDATE test.client SET name='test' WHERE uid=1;

这条更新无法同步到备机，必须在update前use database操作，该database必须是replicate-wild-do-table中指定的database。

保险的解决方式：连接上mysql后，调用mysql_select_db()选择数据库，之后进行的更新操作就可以自动同步了。

 

SQL模式匹配

SQL的模式匹配允许你使用“_”匹配任何单个字符，而“%”匹配任意数目字符(包括零个字符)。在 MySQL中，SQL的模式缺省是忽略大小写的。下面显示一些例子。注意在你使用SQL模式时，你不能使用=或!=；而使用LIKE或NOT LIKE比较操作符。

Mysql并发瓶颈

Mysql的连接数到达150以上的时候，服务器4核cpu占有率会急增，性能会急剧下降。Apache并发80的情况下，mysql连接数基本上到了配置的满额200（max-connections=200）。

 

Apache与mysql的并发关系

Apache最大并发数配置是600，大于mysql最大并发数200，每个apache请求要对应一个mysql连接，而Apache的并发能力要远大于mysql服务器的并发能力。高并发情况下，mysql的查询还没有返回结果，但下一次的apache请求已经到了，堆积效果就是mysql都是满额并发运行，可能导致连接mysql错误：“too many connections…”。

 

Apache做Mysql的连接池

从上面分析可以看出， mysql_pconnect连接Mysql，但没有控制和管理mysql连接数，可能导致Mysql服务器忙死。只要有连接池，就可以解决问题。

利用apache做mysql的连接池，即控制apache的并发数。apache配置最大并发数（如20）小于mysql最大连接数。当并发过大的时候，就自动利用apache的队列来达到连接池的目的。虽然牺牲了apache性能，但保证了业务的稳定性和安全性，也不会导致Mysql服务器忙死。

apache最大并发数配置的一个缺陷是：无法配置虚拟主机的并发数，只能配置全局并发数。

使用Apache的prefork模式配置并发数：

http://www.shenmiguo.com/archives/2009/318_apache-mpm.html

Mysql持久连接介绍：

http://www.shenmiguo.com/archives/2009/319_mysql-pconnect.html

不同于mysql_connect的短连接，mysql_pconnect持久连接的时候，将先尝试寻找一个在同一个主机上用同样的用户名和密码已经打开的（持久）连接，如果找到，则返回此连接标识而不打开新连接。

当执行完毕后，到 mysql 服务器的持久连接不会被关闭，此连接将保持打开以备以后使用，即mysql_close() 不会关闭由 mysql_pconnect() 建立的连接。

 

Apache与长连接管理

PHP本身并没有数据库连接池的概念，但是Apache有进程池的概念, 一个Apache子进程结束后会被放回进程池, 这也就使得用mysql_pconnect打开的的那个mysql连接资源可以不被释放，而是依附在相应的Apache子进程上保存到了进程池中。于是在下一个连接请求时它就可以被复用。但是在Apache并发访问量大的时候，如果使用mysql_pconnect，会由于之前的Apache子进程占用的MySQL连接没有close, 很快使MySQL达到最大连接数，使得之后的请求可能得不到响应。

当然，高并发情况下也不能怪罪pconnect，用短连接频繁连接mysql，也一样有问题。在没有连接池的情况下，用apache做连接池管理是比较好的选择。

prefork模式是预派生子进程方式，使用多个子进程，每个子进程只有一个线程。每个进程在某个确定的时间只能维持一个连接。

worker模式是多线程与多进程混合方式，使用多个子进程，每个子进程有多个线程。每个线程在某个确定的时间只能维持一个连接。

总的来说，prefork方式速度要稍高于worker，然而它需要的cpu和memory资源也稍多于woker。

 

prefork模式

httpd.conf中，prefork的配置如下：

<IfModule prefork.c>

ServerLimit          2000

StartServers         300

MinSpareServers      5

MaxSpareServers     10

MaxClients          600

MaxRequestsPerChild 10000

</IfModule>

prefork的工作原理是，控制进程在最初建立"StartServers"个子进程后，为了满足"MinSpareServers"设置的需要创建一个进程，等待一秒钟，继续创建两个，再等待一秒钟，继续创建四个……如此按指数级增加创建的进程数，最多达到每秒32个，直到满足 MinSpareServers设置的值为止。这就是预派生（prefork）的由来。这种模式可以不必在请求到来时再产生新的进程，从而减小了系统开销以增加性能。

MaxClients是最重要的一个参数。可通过MaxClients来控制Apache并发数。

 

prefork指令

ServerLimit

默认的MaxClient最大是600个线程,如果想设置更大的值，就的加上ServerLimit这个参数。20000是ServerLimit这个参数的最大值。如果需要更大，则必须编译apache，此前都是不需要重新编译Apache。

生效前提：必须放在其他指令的前面。

StartServers

指定服务器启动时建立的子进程数量。应该要小于等于MaxClients。

MinSpareServers

指定空闲子进程的最小数量，默认为5。如果当前空闲子进程数少于MinSpareServers ，那么Apache将以最大每秒一个的速度产生新的子进程。此参数不要设的太大。

MaxSpareServers

设置空闲子进程的最大数量，默认为10。如果当前有超过MaxSpareServers数量的空闲子进程，那么父进程将杀死多余的子进程。此参数不要设的太大。如果你将该指令的值设置为比MinSpareServers小，Apache将会自动将其修改成MinSpareServers+1。

MaxClients

限定同一时间客户端最大接入请求的数量(单个进程并发线程数)，默认为600。任何超过MaxClients限制的请求都将进入等候队列,一旦一个链接被释放，队列中的请求将得到服务。要增大这个值，你必须同时增大ServerLimit。

MaxRequestsPerChild

MaxRequestsPerChild指令控制服务器杀死旧进程产生新进程的频率。每个子进程在其生存期内允许伺服的最大请求数量，默认为10000。到达MaxRequestsPerChild的限制后，子进程将会结束。如果MaxRequestsPerChild为”0″，子进程将永远不会结束。将MaxRequestsPerChild设置成非零值有两个好处：

1. 可以防止(偶然的)内存泄漏无限进行，从而耗尽内存。

2. 给进程一个有限寿命，从而有助于当服务器负载减轻的时候减少活动进程的数量。

 

worker模式

httpd.conf中，prefork的配置如下：

<IfModule worker.c>

ServerLimit 25

ThreadLimit        200

StartServers        3

MaxClients         600

MinSpareThreads     50

MaxSpareThreads     100

ThreadsPerChild     100

MaxRequestsPerChild 10000

</IfModule>

worker的工作原理是，由主控制进程生成"StartServers"个子进程，每个子进程中包含固定的ThreadsPerChild线程数，各个线程独立地处理请求。同样，为了不在请求到来时再生成线程，MinSpareThreads和MaxSpareThreads设置了最少和最多的空闲线程数；而MaxClients设置了所有子进程中的线程总数。如果现有子进程中的线程总数不能满足负载，控制进程将派生新的子进程。

ThreadsPerChild

是worker模式中与性能相关最密切的指令。这个指令设置了每个子进程建立的线程数。子进程在启动时建立这些线程后就不再建立新的线程了。

 

资源

prefork文档：http://lamp.linux.gov.cn/Apache/ApacheMenu/mod/prefork.html

workder文档：http://lamp.linux.gov.cn/Apache/ApacheMenu/mod/worker.html