上次说到MySQL可靠性方案分析与比较,这回简单介绍下 mysql-master-master的安装,希望有使用过的兄弟多多讨论 ...

    作用: 高可用性 mysql 集群,也称不上集群,主要体现在高可用性上吧!
    原理: 在 master-master (互为 master-slave) 基础上,用 perl 写的脚本,提供虚拟IP,并实现HA

--------------------  警用分隔线 ------------------------

下载: http://code.google.com/p/mysql-master-master/
安装: 1. 解压 mmm-1.0.tar.bz2
        2. 运行 install.pl
        3. 一般情况下会提示一下依赖包未安装,安装即可.
                                       cpan Time::HiRes
                                       cpan DBI
                                       cpan DBD::mysql
                                       cpan Algorithm::Diff    

         安装 DBD::mysql 可能会遇到的问题: (1).mysql_config 提示为找到. ---  加入 /usr/local/mysql/bin 到 path 里即可
                                       (2).mysql.so,类似找不到 mysql 客户端库文件,请执行:
                                                                cp /usr/local/mysql/lib/mysql/*  /usr/lib/
                                                                cp /usr/local/mysql/include/mysql/*  /usr/include/
                                                          (3). make test 时候提示拒绝访问错误:
                                                                 perl -MCPAN -e shell
                                                                 force install DBD::mysql  强制安装,跳过 make test

什么是我们能和应该优化的

Hardware
OS / libraries
SQL server (setup and queries)
API
Application

优化硬件

如果你需要大表(>2G),你应该考虑使用64位硬件,像Alpha,Sparc或者IA64.由于MySQL使用大量内部的64位整型,64位的CPU将有更好的表现.
对于大数据库,优化顺序通常是内存,硬盘,CPU.
更多的内存可以通过把更多的索引页保留在内存中来提高索引更新的速度
如果你不使用事务安全表或者有一个大硬盘并且想避免大文件检查,有一个UPS是个好办法,它能在断电的时候使系统正常关闭.
对于数据库运行在专用的服务器上的系统来说,应该考虑1G的网络,传输延迟和吞吐量同样重要.

优化磁盘

从基本情况、成本、优缺点和应用场合等方面对5种MySQL的可靠性方案进行了分析和比较，对MySQL的开发和管理有一定的借鉴作用。

1．MySQL Clustering(ndb-cluster stogare)

简介：
MySQL公司以存储引擎方式提供的高可靠性方案，是事务安全的，实时复制数据，可用于需要高可靠性及负载均衡的场合。该方案至少需要三个节点服务器才能达到较好的效果。

成本：
节点服务器对RAM的需求很大，与数据库大小呈线性比例；
最好使用千兆以太网络；
还需要使用Dolphin公司提供的昂贵的SCI卡。

优点：
可用于负载均衡场合；
可用于高可靠性场合；
高伸缩性；
真正的数据库冗余；
容易维护。

缺点：
随着数据库的变大，对RAM的需求变得更大，因此成本很高；

前提:
Lamp架构(原理上虽然jsp,.net等都一样,但我现在只懂php了)

1.用户对准确度的要求是不一样的.银行会要求客户帐上的钱的数目永远是精确的,但是论坛的在线人数,贴子数没这个必要.每天有成千上成的贴子发表。谁会去对质?我们只半个小时算一个甚至每天算一次就行了.所以,应用中要是没加Cron,那就肯定不是一个好应用.想象一下awstats,每当你的老板让你给演示一下前一周的访问周数据时,它就嘎吱嘎吱地算上老半天,然后在你的老板快要睡着时IE终于弹出一个页:服务器超时…. 你就知道要把一些服务设为定时跑一次,而不是时时保持最新最准确了
2.瓶颈永远是先在CPU/内存/磁盘IO中的一个出现.他们很少是同时告急的.因此,针对这个设计一个.比如:某台服务器上CPU占用平均为60%左右,而内存占用是5%左右。那么我们可以预先猜测,CPU资源会首先占尽。由于日志显示占用CPU最多的是mysqld进程，说明mysql查询耗尽了 CPU.再查之,原来是贴子主题太多,一个表有上G大小,索引不当.
找到问题,于是马上做出改进.原来的URL已经优化成***.com/topic/10/10001.html, ***.com/topic/12/12001.html…这样的了,但其实后台是用rewrite的.而id从1到100,000的主题都因为已经太老,无人参与回复了，所以没必要每次都查库.马上写个脚本,将***.com/topic/1.html…. ***.com/topic/10/10001.html…这些页面都读下来,保存为web根下/topic/***/***.html文件。现在这些文件是实际存在的了,Apache会优先读这个静态文件,而不是适用rewriterule了.
(注:我的apache 的rewrite规则是这样写的,这样文件找不到的时候会交给index.php来处理.

如果MySQL服务器启用了二进制日志，你可以使用mysqlbinlog工具来恢复从指定的时间点开始 (例如，从你最后一次备份)直到现在或另一个指定的时间点的数据。关于启用二进制日志的信息，参见5.11.3节，“二进制日志”。对于mysqlbinlog的详细信息，参见8.6节，“mysqlbinlog：用于处理二进制日志文件的实用工具”。

要想从二进制日志恢复数据，你需要知道当前二进制日志文件的路径和文件名。一般可以从选项文件(即my.cnf or my.ini，取决于你的系统)中找到路径。如果未包含在选项文件中，当服务器启动时，可以在命令行中以选项的形式给出。启用二进制日志的选项为--log-bin。要想确定当前的二进制日志文件的文件名，输入下面的MySQL语句：


SHOW BINLOG EVENTS \G


你还可以从命令行输入下面的内容：

A为主机,B为备份机, 同为双网卡，而且可以通过内网相连

A 内网IP : 192.168.195.28

B 内网IP : 192.168.195.30

数据库版本(5.0.22),目录,初始的库,表 两台机器是一样的

需要备份的库     ad_data , alexa_info , log_db , oblog , union_db , zm0061_db

不需要备份的库     mysql , test