上次说到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的需求变得更大，因此成本很高；

如果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

因为 y&(*(%*t*(y(y ... 所以BLOG要移窝了,很感谢 XUCHAO "MM" 在这个时候拔刀相助.真是相当滴感动啊!!!
可就当满心欢喜挪的时候,突然想起以前MYSQL乱码问题来了,以前太懒,发现可以用就不管了，全不管PHPMYADMIN
里全是乱码.如今麻烦来了,昨天搞到2点,还是一无所有.幸好今天去了趟新公司,得到不知道喜还是忧的答复,也算是
一种解脱了.把 GOOGLE 搜烂了,结果发现问题当然还是出在 字符集 上.还是出在 latin1_swedish_ci 这个鸟老
字符集上.就当要放弃的时候,GOOGLE 了一下,居然找到惊喜.测试一遍OK.转换过去OK.太帅了.MYSQL 乱码问题到这
里算是终结了。感谢湖南卫视,感谢快乐男生,感谢我型我SHOW!!!(别误会,这几个感谢只是为了提高点流量...)
下面是正文...被乱码烦恼的人们.请点击.PS: 版权所有:huangliming

---

MySQL从4.1版本开始才提出字符集的概念，所以对于MySQL4.0及其以下的版本，他们的字符集都是Latin1的，所以有时候需要对mysql的字符集进行一下转换，MySQL版本的升级、降级，特别是升级MySQL的版本，为了不让程序继续沿用Latin1字符集之后对以后Discuz！版本升级的影响和安装SupeSite，这就需要我们进行字符集的转换!
   本人转换过好多数据了，也用过了好多的办法，个人感觉最好用的就是使用MySQL命令导出导入中将字符集转换过去!
   现在我将用图文并茂的方式向大家展示一下如何将MySQL字符集进行转换,由于字符集比较多,现在主要举GBK和Latin1这两种字符集之间的转换!