生命之中的最大错误在于：终日担心犯错误。— 爱尔伯特·哈伯德 (Elbert Hubbard 1856-1915)，《笔记》
此需求的可能性：
做所有的数据库同步需要很多无用的空间，如果仅仅用到其中一个数据库，那就做一个数据库的同步就足够了。
步骤一 主数据库开通replication用户
按需求不一样名称和密码以及IP不同：
步骤二 取得当前数据备份，备份mysql库和你要的database2
方式1 从master取得
做所有的数据库同步需要很多无用的空间，如果仅仅用到其中一个数据库，那就做一个数据库的同步就足够了。
步骤一 主数据库开通replication用户
按需求不一样名称和密码以及IP不同：
CREATE USER 'slave'@'192.168.1.2' IDENTIFIED BY '***';
GRANT REPLICATION SLAVE ON * . * TO 'slave'@'192.168.1.2' IDENTIFIED BY '***' WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0 ;
GRANT REPLICATION SLAVE ON * . * TO 'slave'@'192.168.1.2' IDENTIFIED BY '***' WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0 ;
步骤二 取得当前数据备份，备份mysql库和你要的database2
方式1 从master取得
FLUSH TABLES WITH READ LOCK; //锁定所有表
show master status; //取得当前日志点
//打包文件或者是直接导出数据，比停止服务好的地方就是有一段读数据库的时间
unlock tables; //解锁
show master status; //取得当前日志点
//打包文件或者是直接导出数据，比停止服务好的地方就是有一段读数据库的时间
unlock tables; //解锁
今天发现phpMyadmin3.3版本有两个新功能很实用：
1 Synchronize是支持两个数据库同步的操作，这功能挺好的
2 管理replication
不过，同步操作似乎是经过本地web管理的服务器，如果是远端的数据库同步，可能不太合适了，未确认。除非把管理的web端放在数据库的局域网，那样应该挺快。
复制的管理也蛮好，把平时需要输入的命令行给做成点击几下就可以，很方便，这个实用。
去phpmyadmin官网下载最新版本吧！
点击这里查看官方关于同步功能的介绍
1 Synchronize是支持两个数据库同步的操作，这功能挺好的
2 管理replication
不过，同步操作似乎是经过本地web管理的服务器，如果是远端的数据库同步，可能不太合适了，未确认。除非把管理的web端放在数据库的局域网，那样应该挺快。
复制的管理也蛮好，把平时需要输入的命令行给做成点击几下就可以，很方便，这个实用。
去phpmyadmin官网下载最新版本吧！
点击这里查看官方关于同步功能的介绍
mysql的安装目录里有support-files，里面有几份默认的配置
分别是 huge large medium 等，还有高压力的InnoDB的参考：
[root@aslibra support-files]# grep -v ^# my-huge.cnf
key_buffer = 384M
table_cache = 512
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size = 32M
thread_concurrency = 8
分别是 huge large medium 等，还有高压力的InnoDB的参考：
[root@aslibra support-files]# grep -v ^# my-huge.cnf
key_buffer = 384M
table_cache = 512
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size = 32M
thread_concurrency = 8
如果你的服务和我的问题类似，则不妨参考此项做法(只是临时迁移)：
A数据库服务是在3306，数据库连接用的是hosts里的名称，要迁移到B数据库，但端口服务是3307
在不改PHP代码的前提下，可以这样：
1 先用iptables设置B服务器的3306端口转发到3307：
这里限制了eth1
2 相应的用户导入，如果不知道用户密码，可以导入相应的mysql/usr表里的相应记录，如果有表权限分配，则比较复杂了，这个多熟悉一下数据库操作才行
3 导出数据并导入，当然了，也需要创建相应的库
这里用户是u，密码是p，可以在此服务器访问目标数据库
4 修改hosts相应的记录为B的IP，OK
A数据库服务是在3306，数据库连接用的是hosts里的名称，要迁移到B数据库，但端口服务是3307
在不改PHP代码的前提下，可以这样：
1 先用iptables设置B服务器的3306端口转发到3307：
iptables -t nat -A PREROUTING -i eth1 -p tcp -m tcp --dport 3306 -j DNAT --to-destination :3307
这里限制了eth1
2 相应的用户导入，如果不知道用户密码，可以导入相应的mysql/usr表里的相应记录，如果有表权限分配，则比较复杂了，这个多熟悉一下数据库操作才行
3 导出数据并导入，当然了，也需要创建相应的库
mysqldump -S /Data/mysqldb/3306/mysql.sock -uu -pp aslibra >aslibra.sql
mysql -h 192.168.1.8 -P3307 -uu -pp aslibra < aslibra.sql
mysql -h 192.168.1.8 -P3307 -uu -pp aslibra < aslibra.sql
这里用户是u，密码是p，可以在此服务器访问目标数据库
4 修改hosts相应的记录为B的IP，OK
案例：
希望增加一台只读的从数据库，已经有主从配置。
这里就不必停止主服务器做主从了，从服务器拷贝一份就直接能够处理。
方法：
先停止从服务器的同步 slave stop
这样，从服务器就是处于一个没有更新的且只读的状态，如果没有inodb类型的，那整个数据库文件夹拷贝一份就可以了，我的配置文件在此文件夹里。
拷贝完毕，执行 slave start 继续同步。
启用另外一台：
把拷贝的那份放另外一个机器上运行，能够正常运行，没有太留意问题。
正常状态应该是在主服务器看到slave的进程的状态是：
比较奇怪的是，我有三台slave，只有两个进程看的到，另外一台的进程看不到。
在另外一台上查看状态是
还非常奇怪，一直都是这个状态，明显可以检查出来，数据更新延后了，半天时间过去了也这样。
问题所在：
想起来配置文件没有修改，server-id是一样的，这个可能是问题。
遂修改所有slave服务器为唯一的id，问题解决。
三个slave的进程都在主服务器进程，状态都是
希望增加一台只读的从数据库，已经有主从配置。
这里就不必停止主服务器做主从了，从服务器拷贝一份就直接能够处理。
方法：
先停止从服务器的同步 slave stop
这样，从服务器就是处于一个没有更新的且只读的状态，如果没有inodb类型的，那整个数据库文件夹拷贝一份就可以了，我的配置文件在此文件夹里。
拷贝完毕，执行 slave start 继续同步。
启用另外一台：
把拷贝的那份放另外一个机器上运行，能够正常运行，没有太留意问题。
正常状态应该是在主服务器看到slave的进程的状态是：
引用
Has sent all binlog to slave; waiting for binlog to be updated
比较奇怪的是，我有三台slave，只有两个进程看的到，另外一台的进程看不到。
在另外一台上查看状态是
引用
Queueing master event to the relay log
还非常奇怪，一直都是这个状态，明显可以检查出来，数据更新延后了，半天时间过去了也这样。
问题所在：
想起来配置文件没有修改，server-id是一样的，这个可能是问题。
遂修改所有slave服务器为唯一的id，问题解决。
三个slave的进程都在主服务器进程，状态都是
引用
Has sent all binlog to slave; waiting for binlog to be updated
最近在生产环境使用了amoeba，发现一些问题：
1 sql语句不支持，产生大量错误日志
2 有重复执行的迹象，发生数据重复插入到master，还不确定这问题是否amoeba的问题
3 读写分离会在master出现读进程
第二点，就目前的使用情况而言，amoeba还是很稳定的，只是不太清楚是什么问题，如果重复插入数据的问题不是amoeba产生的，那对于应用而言没有错误发生。
对于第一点和第三点，我觉得是这么一个过程：
1 读写分离时会分析sql语句
2 如果语句属于检查范围的则正常进行读写判断，读操作发送到writePool，写操作发送至readPool，未知的sql语句则发送至defaultPool
3 一般defaultPool和写操作是master，所以在master发现select语句很正常，肯定是判断不出来的语句
sql出现的问题比较多，在log里面有找到以下性质的语句错误记录：
希望amoeba可以正常运行，不产生第二点错误就很满意了。
对于读操作，使用amoeba肯定是不错。
另外，master重启可能导致主从同步会不太稳定，多个从服务器的话比较长的时间才能稳定下来。
比较经常出现“Queueing master event to the relay log”，slave进程都没有持续，可能导致更新不够及时。
@20100105 补充：以上可能是server-id的问题，参考这里
1 sql语句不支持，产生大量错误日志
2 有重复执行的迹象，发生数据重复插入到master，还不确定这问题是否amoeba的问题
3 读写分离会在master出现读进程
第二点，就目前的使用情况而言，amoeba还是很稳定的，只是不太清楚是什么问题，如果重复插入数据的问题不是amoeba产生的，那对于应用而言没有错误发生。
对于第一点和第三点，我觉得是这么一个过程：
1 读写分离时会分析sql语句
2 如果语句属于检查范围的则正常进行读写判断，读操作发送到writePool，写操作发送至readPool，未知的sql语句则发送至defaultPool
3 一般defaultPool和写操作是master，所以在master发现select语句很正常，肯定是判断不出来的语句
sql出现的问题比较多，在log里面有找到以下性质的语句错误记录：
1 TRUNCATE TABLE XXX
2 EXPLAIN XXX
3 SELECT * FROM xx FORCE INDEX (xx)
4 insert into xx values('\'test\'') 转义的单引号
5 order by rand()
2 EXPLAIN XXX
3 SELECT * FROM xx FORCE INDEX (xx)
4 insert into xx values('\'test\'') 转义的单引号
5 order by rand()
希望amoeba可以正常运行，不产生第二点错误就很满意了。
对于读操作，使用amoeba肯定是不错。
另外，master重启可能导致主从同步会不太稳定，多个从服务器的话比较长的时间才能稳定下来。
比较经常出现“Queueing master event to the relay log”，slave进程都没有持续，可能导致更新不够及时。
@20100105 补充：以上可能是server-id的问题，参考这里
1 IP高可用性
可以靠keepalived来维持。
2 web高可用性
可以用proxy服务器的负载均衡分配，一般自带后端检查，可以是nginx，比较流行这个。
3 php运行
可以是fastcgi，也是可以实现负载均衡，能者多劳。
4 mysql
可以使用amoeba或者mysql-proxy，实现读写分离和负载均衡，重要的事情是主从配置和维护。
amoeba-mysql的安装使用和读写分离
Amoeba for Mysql 试用小结
5 数据缓存层
可以用memcached，速度要求低一点的可以用memcachedb，使用magent可以做代理，保持高可用性。
Nginx和memcached/memcachedb配合可以加速可缓存的访问。
memcached和magent的安装
memcachedb的缓存解决方案
6 nginx的proxy性能
可以使用自带的memcache加速，起文件缓存作用。
也许还可以使用同步文件到本地的方式，不经过cache服务器。
7 cache服务器
比如lighttpd+modcache，或者squid、varnish等。新出的modcache可以利用内存缓存，性能估计能高一些，只是用内存缓存居然不支持本地压缩了，需要改为后端处理gzip工作。
lighttpd的mod_cache缓存不了的问题
总体而言
要高可用性，必须有代理层，有了代理层才会解决单点故障。。。
可以靠keepalived来维持。
2 web高可用性
可以用proxy服务器的负载均衡分配，一般自带后端检查，可以是nginx，比较流行这个。
3 php运行
可以是fastcgi，也是可以实现负载均衡，能者多劳。
4 mysql
可以使用amoeba或者mysql-proxy，实现读写分离和负载均衡，重要的事情是主从配置和维护。
amoeba-mysql的安装使用和读写分离
Amoeba for Mysql 试用小结
5 数据缓存层
可以用memcached，速度要求低一点的可以用memcachedb，使用magent可以做代理，保持高可用性。
Nginx和memcached/memcachedb配合可以加速可缓存的访问。
memcached和magent的安装
memcachedb的缓存解决方案
6 nginx的proxy性能
可以使用自带的memcache加速，起文件缓存作用。
也许还可以使用同步文件到本地的方式，不经过cache服务器。
7 cache服务器
比如lighttpd+modcache，或者squid、varnish等。新出的modcache可以利用内存缓存，性能估计能高一些，只是用内存缓存居然不支持本地压缩了，需要改为后端处理gzip工作。
lighttpd的mod_cache缓存不了的问题
总体而言
要高可用性，必须有代理层，有了代理层才会解决单点故障。。。
