1999年，我开始使用QQ。那时候叫OICQ，用的人不多，只有拨169的兄弟们才会用它，拨163的米人，用的都是ICQ。随着互联网的发展，QQ也在壮大，周围越来越多的朋友加入QQ的行列。渐渐地，QQ成为我生活中仅次于手机的通讯工具。

时光飞逝，转眼间QQ伴随我已经九年，还有几个月就要十周年时，QQ被盗了，就在伟大的祖国举办奥运会那年。那时，对我来说好象世界末日。突然发现认识很多年的朋友，居然连电话都没有，只能通过QQ联络。愤怒、无奈、惊慌、萎靡，当时的心情写照。29858曾经是我的幸运数字，但现在留给我的只有回忆和几百兆的聊天记录。被盗之后，我积极申诉，把能想起来的历史密码和个人资料都填上去了，发动N个5位数好友协助我申诉。两年间，我不记得申诉了多少次，但得到的是一次次的拒绝，一次次的无奈。

两年后，当我渐渐地从丢失QQ的阴影中走出的时候，接到一个电话。凌晨，陌生号码，陌生男，推销墓地。我开始以为什么人在恶作剧，这种情况持续了几天。最后，我终于爆发了。用我能想起来的、最恶毒的语言，XX他和他的全家。没想到那哥们比我还愤怒，就好象我真的XX了他全家一样。之后双方都冷静下来，谈了一次。原来那倒霉孩子被29858骗了几百块的Q币。居然有比我还笨的人......无语。

接下来，就是更多的人打电话过来骂我。报警，我能想到的第一件事，从南京110打到深圳110，从派出所到网监处。以上情况描述了不下十几次。最后可爱的警察同志说: “这情况我们也办法，要不你再想想密码？”  .......再次无语。

腾讯客服的回答更是让我菊花一紧:“要不你放弃这个几个号码，你的朋友就不会被骗了。” ......我想骂人，却骂不出来。

六月的南京，烈日如火。不知道为什么，突然想起李大师。于是我买了一瓶雪碧和一张单程飞深圳的机票。

右后方车门刮到车库  

兴奋过渡，倒车时撞到灌木丛 -_-  还好损伤不大 抛光一下就可以了

下次要小心 -.-

这大概是第八次还是第九次了

这次没什么特殊原因，只是想戒掉。

特写此帖，用以MARK。

先把剩下这盒抽完的。。。不然太浪费

台机已经很久未用，所以顺利成章的装到笔电上。 TC4400 T7600 4G RAM 320G HD 其他都是标配。

安装过程相比7.04就痛苦太多了。 记得当年7.04装到TC4200的时候，所有驱动都识别，包括触摸屏。 好容易解决了内核出错问题。结果蓝牙鼠标装不上去。 搞定蓝牙鼠标发现指纹不支持。放弃指纹之后发现触摸屏是不好用的。

-----------------------我是迷茫的分割线------------------

放弃硬件，搞搞软件。 相对好一些。 现在开发环境主要是python, 这个linux下还是不错的。但我钟爱的google浏览器和输入法没有。有替代品到也能忍。 pplive pps 都不支持。。。唯一的娱乐活动难道要终止？

-----------------------我是沮丧的分割线------------------

前后折腾了一个星期，还是决定放弃ubuntu。 期间还尝试了suse....他娘的还不如ubuntu.  wifi都搞不定。 老老实实做人，踏踏实实用windows。

其实windows也不错，起码我所有的硬件都可以驱动起来，我需要的功能都有软件支持。 我。。。。。。。。。。也只能这么安慰自己了，寄希望于9.10吧。

 后来找到一个流量监控软件：BWMeter  这个软件可以根据IP地址，协议，端口等条件进行带宽限制。 

PPS是UDP协议。 所以只要限制协议17的流量就可以。 经过多次测试 100K 是比较理想的数值。

引用: http://seanv.info/2007/farming_timers.html

In RuneScape, the act of logging in affects how long your crops take to grow. Specifically, it makes them take longer to grow.

Hypothesis: When you log in the timers on your patches are reset.

(The experiment supporting this article was done on Thu 11 May 2007 GMT; earlier or later experiments may yield different data if RuneScape’s code and/or constants were different from those running at the time of this experiment.)

Motivation

What got me thinking about this was the way herbs sometimes took a lot longer to grow than I’d anticipated. In a preliminary experiment, similar to the one documented below but with watermelons and ranarr weed, the watermelon took a full ten minutes to grow after logging in and the ranarr twenty minutes.

A bit of background: the patch timers

As you are probably aware if you’ve tried the Farming skill in RuneScape, crops grow in discrete stages. Each type of patch has a timer associated with it which, when it runs out, triggers a ‘grow event’.

I measured the time between grow events for the allotment/herb/flower set of patches:

(The timers seem to run a few seconds longer than these times. E.g. I measured times of 5:05 and 5:09 for flower patches.)

For at least some (and in my opinion probably all) of the different types of patches the timers are synchronised. I observed (as many farmers probably will have) that herb patch grow events occur simultaneously with every second allotment grow event.

The experiment: observation of effect of logging in on timing of grow events

The plan:

• Plant a limpwurt seed and water it
• Watch for grow events and record the time of each
• Log out and then quickly log back in while the limpwurt’s growing
• See what affect this has on the timing of the grow events

The flower patch south of Falador was used.

Logging out extended the period between the second and third grow events. The third grow event occurred about five minutes after logging back in. This is the evidence presented in support of this article’s hypothesis.

Length of time to fully grow crops

(How long crops take to fully grow wasn’t the principal data the experiment was designed gather. I’m including here some of the reliable data I got in order to be able to illustrate the effect of logging in on crops’ maturation times.)

(All times in minutes.)

(*If the outcome of any of a crop’s grow events is disease or don’t grow this time then the maximum maturation time may be longer than the figures in this column.)

Consequences for farmers

If you want your crops to grow as quickly as possible:

• stay logged in continuously, or
• if you log out, do not log back in until you know your crops will be fully grown.

Admittedly, I neither strive to make my crops grow as quickly as possible nor do either of these things. These suggestions might apply, say, to someone trying to get the maximum rate of farming experience.

The situation is interesting for crops which take a long time to grow, e.g. trees. I expect for normal or fruit trees the time between grow events is considerably longer, for otherwise fruit trees would have a large number of different stages of growth, which is not what I have observed. In fact I notice Maxromulan has said that fruit tree patch grow events occur every four hours. Now

4 hr = 240 min = 12 x 20 min

so perhaps fruit tree patch grow events are synchronised with every twelfth herb patch grow event. If logging in actually does reset a four hour timer, each login could lengthen the time to maturity of fruit trees by up to four hours, two hours on average if the time you spend logged on is completely random (whatever that means).

Further investigations

What about the other types of crop (trees, calquats, etc., etc.)? Their patch timers are quite a bit longer than 20 minutes. Does logging in completely reset the timer? I don’t know, but I may attempt to experiment to find out and if I do I’ll post the results here.

Acknowledgements and references

Thanks to Maxromulan for sharing some snippets of her farming knowledge in a thread on theRuneScape Rants forum. After I noticed that something interesting was happening with the farming timers, her thread confirmed it for me and encouraged me to investigate further. One of Maxromulan’s posts alerted me to the fact that there is a random chance that the outcome of a grow event is ‘don’t grow this time’. Thanks also to Luciferzero0 for his/her posts on that thread, in one of which he or she states the hypothesis of this article.

This document was originally written on 13 May 2007 GMT and was most recently updated on 22 May 2008.

写了几个监控脚本，对CPU,交换分区，硬盘使用率，进程等情况做了监视。 得到以下结论：

imap和maildrop引起的系统IO阻塞，是造成故障的主要原因。

imap 在大量用户的情况下本身就是瓶颈。 目前常规在线人数在100左右，邮件使用高峰期 IO的使用率是100%。 所以考虑换回POP3。

maildrop 主要是设置问题，之前没有限制最大进程数，群发的时候会启动1xxx个进程，而且都是读写硬盘的，所以要限制maxproc。

在master.cf里

maildrop  unix  -       n       n       -       -       pipe

  flags=DRhu user=vuser argv=maildrop -w 90 -d ${user}@${nexthop} ${recipient} ${user} ${extension} {nexthop}

改为

maildrop  unix  -       n       n       -       21       pipe

  flags=DRhu user=vuser argv=maildrop -w 90 -d ${user}@${nexthop} ${recipient} ${user} ${extension} {nexthop}

这键位基本能够满足所有linux操作需求. 很强大

这个滚轮和黑莓很象

USB充电口. 那个小孔应该是MIC, 我差点当成RESET......

相机钮, 感觉用处不大

音量钮

我的最爱..后面的图案很迷人

尤其是这个机器人 ;-)

G1键盘滑出的方式很特别 下面一组图可以看出滑动路线

特别的代价就是磨损严重....我才用了几天啊

G1 VS P4550

Download

2. pylrs      http://blog.bigcomic.com/upload/pylrs-1.0.0.zip

    python模块, 可以生成lrf

The goal of this page is to provide a reference to the programs that can be used for understanding the LRF format, the program listed here are not the only (and not necessarily the best) way to make lrf content.

Formats

LRF format. This BINARY format used in Sony Librie and Sony PRS-500 Readers. The format is barely documented. Some very limited information can be found at http://www.sven.de/librie/Librie/BBeB . The LRF format can be understood with the python code of lrf2lrs converter and utilities for extracting the objects from LRF files (see below). The LRF can contain text or images, the ability to show images sometimes used by homemade programs with the reference to "picture" LRF (actually this is just simple implementation of one of the features of LRF format).

LRS (Librie Reader Source) format. LRS is a "source" XML format with the description for the objects used in LRF. This format was introduced in the Book Creator program (commercial program with Japanese interface) by Canon (see below). The format is documented: http://www.y-adagio.com/public/committees/iec_pt62448/1_np(0509)/100_1017e_DC.pdf . LRS files can be generated by either 3 ways: 1) with commercial Book Creator program by Canon; 2) with freeware Book Designer program (see below for more details) 3) with Python lrf2lrs converter by roxfan, Igor Skochinsky and several newly developed utilities available at www.mobileread.com.

BBeB "Broadband ebook" format by Sony. Another name of LRF and, sometimes, LRS formats.

Programs useful for understanding the LRF format

Major programs for understanding the LRF format, listed by date:

1. Book Creator Commercial program by Canon. First mentioned in yahoo Librie group in June 2004, see post #18). The program has Japanese interface. Since that time the development of homemade LRF content was started. First, many affords were done to make English version of Book Creator (see Librie yahoo group); Second, some homebrew programs use XYLogParser.dll (with Lrs2lrf wrapper by roxfan) to create LRF files from LRS source; Third, reverse engineering of LRF format was started to develop programs independent from XYLogParser.dll.

2. Makelrf program by scythic (first introduced in yahoo librie group in October, 2004). The program comes with C-code and available in the File section of Librie group. The program allows to create Lrf files from the text files with support of the images. The program cannot create rich lrf files (only basic objects are supported), but it is hard to underestimated the progress archived with the program. Till now makelrf is widely used in many other programs as an engine for creation either simple text LRF or image-based LRF. Until recently makelrf was used in BookDesigner program (in "simple" conversion mode); and JAP programs to generate image-based LRFs.

3. LRFParser by roxfan (yahoo Librie group, November 2004, comes with C-source). The program decompiles LRF files to the objects, including TOC, header and compressed streams. To my knowledge, LRFparser is the first program where complex LRF objects and majority of tags were understood.

4. lrf2lrs (first version signed by roxan, February 2006; yahoo Librie group); the latest versions (signed by roxfan, Igor Skochinsky) are available at www.mobileread.com (Sony Portable Reader - Reader Developer's Corner - Lrf2Lrs thread, posts by igorsk). (I believe that roxfan=Igor Skorchinsky=igorsk). With the program the LRF files can be converted to the LRS files. Up to date the source of this Python program is the major source of information on LRF objects and tags. Almost all possible LRF objects and tags are supported by the program.

5. LRFunpack (by me, available at download section of this site, November 2006). NET2.0 C# application for extracting objects from LRF files with some translation of the tags and description of the streams. Creates both dump hex files for each of the object together with the text files with some decryption. I was using this program to understand the LRF format. The advantage of this program - it never stops decompiling even if tag is unknown. Some example of decompiled lrf can be found at download section. Sorry, no source available.

-----------

I did not mention Java tools, because I never tried them myself. Please have a look at the forums of the sites listed in the Link section. I believe the most significant contributions are flatLrf (http://monalipse.sourceforge.jp/tmp/lrf/, January 2005) and LRFParser.java (by Scotty1024, May 2005, Librie yahoo group). FlatLrf is Java application to create lrf from html files; LRFParser.java is Java version of LRFParser by roxfan.

BookDesigner (Wiki page) (by Valerii Woizechovsky (aka vvv))). This program is an universal program for conversion between many formats, reading and ebook creation. The program creates LRS file, than the LRS file is converted to LRF with external third-party converters (makelrf, lrs2lrf , LRSparser by AlexXF, the latest version uses my MSH_Lrsparser). The strong side of the BookDesigner for understanding the LRF format is ability to generate custom LRS together with corresponding LRF file for further analysis.

LRF conversion utilities

Please refer to the Wiki page and the link section for recent progress on content generation. Recently Sony launched site for the developers at www. prslabs.com. Unfortunately there is almost no new information. The LRS format specification is given (the one mentioned above), the XYLogParser.dll (almost the same to the discussed above, it is also very slow), and the description of the interface around the XYLogparser.dll.

 http://www.msh-tools.com/ebook/lrfformat.html

Header

Offset (hex)	Size(bytes)	Name/meaning	Example value
0	8	LRF Signature	4C 00 52 00 46 00 00 00 = "LRF" in Unicode
8	2	version?	999 in most files
A	2	"Psuedo-Encryption" key byte	48
0C	4	RootObjectID	0x0044
10	8	NumberOfObjects	342
18	8	ObjectIndexOffset	0x00093440
20	4	unknown	0
24	1	Flags (16 - back to front, 1 = front to back)	16
25	1	unknown (padding?)	0
26	2	unknown	1600
28	2	unknown (padding?)	0
2A	2	Height?	600
2C	2	Width?	800
2E	1	unknown	24
2F	1	unknown (padding?)	0
30	0x14	unknown	zeroes
44	4	Object ID of only PlaneStream (0x1E) object	0x0042
48	4	unknown	0x1536
4C	2	XMLCompSize	0x035C

Next two fields are only present if version>=800.

4E	2	unknown	0x0014
50	4	GifSize	0x03F2

Immediately follows the compressed XML metainfo, of size XMLCompSize. First dword of it is the size of uncompressed data, the rest is zlib compressed unicode XML.

If version>=800, the gif thumbnail follows, of size GifSize.

Object index

Offset to the index is specified by the ObjectIndexOffset in the header, and number of entries is NumberOfObjects.

Each index entry has the following layout:

Offset (hex)	Size(bytes)	Name/meaning	Example value
00	4	id	0x32
04	4	offset	0x07B0
08	4	size	0x44
0C	4	reserved?	0

Objects

See LrfObject [http://buycialis.cc(approve sites) buy cialis online] [http://buycialis.cc(approve sites) buy cialis] http://buycialis.cc buy cialis online(approve sites)

我等 我等

ubuntu下参考之前的文章: http://blog.bigcomic.com/post/241.html

有一点不同的是ubuntu下的pam日志在 /var/log/auth.log.  而centos5.2是在 /var/log/secure

EOF

下载TopWords

NRPE is an addon that allows you to execute plugins on remote Linux/Unix hosts. This is useful if you need to monitor local resources/attributes like disk usage, CPU load, memory usage, etc. on a remote host. Similiar functionality can be accomplished by using the check_by_ssh plugin, although it can impose a higher CPU load on the monitoring machine - especially if you are monitoring hundreds or thousands of hosts.

NSCA

NSCA is an addon that allows you to send passive check results from remote Linux/Unix hosts to the Nagios daemon running on the monitoring server. This is very useful in distributed and redundant/failover monitoring setups.

NSClient++

Monitoring private services or attributes of a Windows machine requires that you install an agent on it. This agent acts as a proxy between the Nagios plugin that does the monitoring and the actual service or attribute of the Windows machine. Without installing an agent on the Windows box, Nagios would be unable to monitor private services or attributes of the Windows box.

NDOUtils

NDOUtils is an addon that allows you to store all status information from Nagios in a MySQL database. Multiple instances of Nagios can all store their information in a central database for centralized reporting. This will likely serve as the basis for a new PHP-based web interface for Nagios in the future.

Vista推出一个很有意思的东西Sidebar. 可以在桌面显示一些小工具.  

这周计划制作一个工具, 可以显示当前最热门的关键词.

参考地址:

http://msdn.microsoft.com/en-us/library/aa974179.aspx#rightui

http://msdn.microsoft.com/en-us/library/bb456468(VS.85).aspx#_sidebar_basic_example

EOF

条件搜索:
order_by()    排序
distinct()    消除重复结果
id__gt=10    id >  10
id__gte=10    id >= 10
id__lt=10    id <  10
id__lte=10    id <= 10
id__startswith='xx'   id like 'xx%'
id__istartswith='xx'   id ILIKE 'xx%'
id__endswith='xx'   id LIKE '%xx'
id__iendswith='xx'   id ILIKE '%xx'
id__exact='xx'    id LIKE 'xx'
id__iexact='xx'    id ILIKE 'xx'
id__contains='xx'   id LIKE '%xx%'
id__icontains='xx'   id ILIKE '%xx%'
id__in=[1, 3, 4]   id IN (1, 3, 4)
id__exact=14    id = 14
id__exact=None    id IS NULL
id__isnull=Ture    id IS NULL
start_date = datetime.date(2005, 1, 1)
end_date = datetime.date(2005, 3, 31)
id__range=(start_date, end_date) id BETWEEN '2005-01-01' and '2005-03-31';
id__year=2009    EXTRACT('year' FROM id) = '2009'
id__iregex=r'^(an?|the) +'  id REGEXP '^(an?|the) +'

返回结果数量限制:
Entry.objects.all()[:5]   LIMIT 5
Entry.objects.all()[5:10]  OFFSET 5 LIMIT 5
Entry.objects.all()[:10:2]  step 2
Entry.objects.order_by('headline')[0] LIMIT 1

数据操作:
.delete()    删除
.save()     更新
.count()    结果数量

容错处理:

from django.core.exceptions import ObjectDoesNotExist
try:
 e = Entry.objects.get(id=3)
except ObjectDoesNotExist:
 print "Either the entry doesn't exist."

try:
    obj = Person.objects.get(first_name='John', last_name='Lennon')
except Person.DoesNotExist:
    obj = Person(first_name='John', last_name='Lennon', birthday=date(1940, 10, 9))
    obj.save()
 

collation=utf8_general_ci --with-mysqld-ldflags=-all-static --without-debug
# make && make install
# cp /usr/src/mysql-5.1.30/support-files/mysql.server /etc/rc.d/init.d/mysqld
# chmod 755 /etc/rc.d/init.d/mysqld
# chkconfig --add mysqld
# chkconfig --level 345 mysqld on
# cp support-files/my-medium.cnf /etc/my.cnf
# vi /etc/my.cnf
  - skip-federated
  + #skip-federated
# ./scripts/mysql_install_db
# cd /usr/local
# groupadd database
# adduser mysql -G database
# vi /etc/passwd
  - mysql:x:500:501::/home/mysql:/bin/bash
  + mysql:x:500:501::/home/mysql:/sbin/nologin
# chmod 750 mysql -R
# chgrp database mysql -R
# chown mysql mysql/var -R
# ln -s /usr/local/mysql/bin/mysql /sbin/mysql
# ln -s /usr/local/mysql/bin/mysqladmin /sbin/mysqladmin
# ln -s /usr/local/mysql/bin/mysql_config /sbin/mysql_config
# service mysqld start

Python
# tar zxvf Python-2.5.2.tgz
# cd Python-2.5.2
# ./configure --prefix=/usr/local/python
# make && make install
# ln -s /usr/local/python/bin/python /usr/bin/python
# ln -s /usr/local/python/lib/python2.5 /usr/lib/python2.5

MySQL-python
# tar zxvf MySQL-python-1.2.2.tar.gz
# cd MySQL-python-1.2.2
# python setup.py install
# ln -s /usr/local/mysql/lib/mysql/libmysqlclient_r.so.16 /usr/lib/libmysqlclient_r.so.16
# python
>>> import MySQLdb /检验mysql-python安装是否正确
 

Django
# tar xzvf Django-1.0.2-final.tar.gz
# cd Django-1.0.2-final
# python setup.py install

pcre
# tar zxvf pcre-7.8.tar.gz
# cd pcre-7.8
# ./configure
# make && make install

lighttpd
# tar xzvf lighttpd-1.4.20.tar.gz
# cd lighttpd-1.4.20
# ./configure --prefix=/usr/local/lighttpd --disable-ipv6 --with-linux-aio  --without-bzip2
# make && make install
# mkdir /usr/local/lighttpd/conf
# mkdir /usr/local/lighttpd/logs
# cp doc/lighttpd.conf /usr/local/lighttpd/conf/
# vi /usr/local/lighttpd/conf/lighttpd.conf
  @ server.document-root
  @ server.errorlog
  @ index-file.names
  @ accesslog.filename
# cp doc/rc.lighttpd.redhat /etc/rc.d/init.d/lighttpd
# chmod 755 /etc/rc.d/init.d/lighttpd
# vi /etc/rc.d/init.d/lighttpd
  - LIGHTTPD_CONF_PATH="/etc/lighttpd/lighttpd.conf"
  + LIGHTTPD_CONF_PATH="/usr/local/lighttpd/conf/lighttpd.conf"
# chkconfig --add lighttpd
# chkconfig --level 345 lighttpd on

 
python-flup
# tar zxvf flup-1.0.1.tar.gz
# cd flup-1.0.1
# python ez_setup.py
# python setup.py install

#  
# vi settings.py
  + FORCE_SCRIPT_NAME = ""

# vi /usr/local/lighttpd/conf/lighttpd.conf
  - # mod_rewrite
  + mod_rewrite
  - # mod_fastcgi
  + mod_fastcgi
  + fastcgi.server = ( "/mysite.fcgi" =>
  +                   ( "main" =>
  +                       ( "socket" => "/tmp/fcgi.sock",
  +                         "check-local" => "disable",
  +                       )
  +                   )
  + ) 
  + url.rewrite = (
  +      "^(/media.*)$" => "$1",
  +      "^(/.*)$" => "/mysite.fcgi$1",
  + )

# service lighttpd restart

#server.document-root        = "/home/radio/htdocs/"
server.document-root = "/home/radio/workspace/pywork/bigcomic/"

     "^(/media.*)$" => "$1",
     "^(/.*)$" => "/mysite.fcgi$1",

#
# chkconfig: - 91 35
# description: Starts and stops the Subversion service
# subversion options

OPTIONS="-d -r /home/svndata"

prog=_subversion
RETVAL=0
_subversion=/usr/bin/svnserve

# Source function library.

. /etc/rc.d/init.d/functions

# Source networking configuration.

. /etc/sysconfig/network

start() {
        KIND="SubVersion"
    echo -n $"Starting $KIND services: "
    daemon $_subversion $OPTIONS
    RETVAL=$?
    echo
    [ $RETVAL -eq 0 ] && touch /var/lock/subsys/subversion || \
     RETVAL=1
    return $RETVAL
}   

stop() {
        KIND="SubVersion"
    echo -n $"Shutting down $KIND services: "
    killproc $_subversion
    RETVAL=$?
    [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/subversion
    echo ""
    return $RETVAL
}   

restart() {
    stop
    start
}   

case "$1" in
  start)
      start
    ;;
  stop)
      stop
    ;;
  restart|reload)
      restart
    ;;
  status)
        status $dc_server
    RETVAL=$?
    ;;
  condrestart)
      [ -f /var/lock/subsys/subversion ] && restart || :
    ;;
  *)
    echo $"Usage: $0 {start|stop|restart|reload|status|condrestart}"
    exit 1
esac

exit $?

# chmod 755 svn_service
# cp svn_service /etc/rc.d/init.d/svn
# chkconfig --add svn
# chkconfig --level 345 svn on
# netstat -an|grep 3690  //查看svn的端口是否已经开启，没记错的话应该就是3690端口
可以使用绿毛龟（svn客户端）来查看项目情况，使用svn://ip:port/test来查看项目源码

配置
#cd /home/svndata/test/conf
#vi authz
 [groups]对组进行配置
 # harry_and_sally = harry,sally

 # [/foo/bar]按目录进行用户读写配置
 # harry = rw
 # * =

 [repository:/test]对svn库的路径进行配置
 # @harry_and_sally = rw
 # * = r
 radio=rw
 pencat=rw
 koala=rw
 soul=rw
#vi passwd
 [users]
 # harry = harryssecret
 # sally = sallyssecret
 radio=123456
 都是明文的
#vi svnserv.conf
password-db = passwd将这行的注释去掉，就会要求用户验证

svn换端口
#./svnserve --help 可以看到命令，里面有个参数--listen-port
不过我没有使用过

因为ssl关系出现认证失败的解决办法
1、停掉ssl
2、# authz-db = authz这行的#保留

#去掉#[general]前面的#号
[general]
#匿名访问的权限，可以是read,write,none,默认为read
anon-access = none
#认证用户的权限，可以是read,write,none,默认为write
auth-access = write
#密码数据库的路径，去掉前面的#
password-db = passwd

./configure --prefix=/usr/local/mysql --enable-thread-safe --enable-assembler --enable-shared --with-charset=utf8 --with-collation=utf8_general_ci --with-mysqld-ldflags=-all-static --without-debug

# make && make install
# .......漫长的等待
# cp /usr/src/mysql-5.1.30/support-files/mysql.server /etc/rc.d/init.d/mysqld
# chmod 755 /etc/rc.d/init.d/mysqld
# chkconfig --add mysqld
# chkconfig --level 345 mysqld on
# cp support-files/my-medium.cnf /etc/my.cnf
# vi /etc/my.cnf
  - skip-federated
  + #skip-federated
# ./scripts/mysql_install_db
# cd /usr/local
# groupadd mysql_g
# adduser mysql -G mysql_g
# vi /etc/passwd
  - mysql:x:500:501::/home/mysql:/bin/bash
  + mysql:x:500:501::/home/mysql:/sbin/nologin
# chmod 750 mysql -R
# chgrp_g mysql mysql -R
# chown mysql mysql/var -R
# ln -s /usr/local/mysql/bin/mysql /sbin/mysql
# ln -s /usr/local/mysql/bin/mysqladmin /sbin/mysqladmin
# ln -s /usr/local/mysql/bin/mysql_config /sbin/mysql_config
# service mysqld start

 http://www.2008-12-27.com/

高汤(鸡汤) 、蛤蜊、黄油、奶油（或鲜奶）、口蘑、面粉

做法：

1. 蘑菇洗好、切片、抄一下。

2. 蛤蜊抄一下。一定要处理好沙子，否则影响汤的口感。

3. 把黄油放入锅中，完全化开之后放入面粉。 翻炒至金黄。 炒好之后呈面糊状。 盛出待用

4. 高汤中加入蘑菇、蛤蜊大火3分钟。

5. 加入制好的面酱。

6. 文火搅拌10分钟。

完成.  口感和比胜客的蘑菇汤味道一样. 

]]>美味多得http://blog.bigcomic.com/post/260.html#commenthttp://blog.bigcomic.com/http://blog.bigcomic.com/feed.asp?cmt=260http://blog.bigcomic.com/cmd.asp?act=tb&id=260&key=5a8908capencat@bigfoot.com (pencat)http://blog.bigcomic.com/post/258.htmlFri, 05 Dec 2008 14:30:30 +0800http://blog.bigcomic.com/post/258.html

–auto-generate-sql, -a
自动生成测试表和数据

–auto-generate-sql-load-type=type
测试语句的类型。取值包括：read，key，write，update和mixed(默认)。

–number-char-cols=N, -x N
自动生成的测试表中包含多少个字符类型的列，默认1

–number-int-cols=N, -y N
自动生成的测试表中包含多少个数字类型的列，默认1

–number-of-queries=N
总的测试查询次数

–query=name,-q
使用自定义脚本执行测试，例如可以调用自定义的一个存储过程或者sql语句来执行测试。

–create-schema
测试的schema，MySQL中schema也就是database

–commint=N
多少条DML后提交一次

–compress, -C
如果服务器和客户端支持都压缩，则压缩信息传递

–concurrency=N, -c N
并发量，也就是模拟多少个客户端同时执行select。可指定多个值，以逗号或者–delimiter参数指定的值做为分隔符

–engine=engine_name, -e engine_name
创建测试表所使用的存储引擎，可指定多个

–iterations=N, -i N
测试执行的迭代次数

–detach=N
执行N条语句后断开重连

–debug-info, -T
打印内存和CPU的信息

–only-print
只打印测试语句而不实际执行

测试的过程需要生成测试表，插入测试数据，这个mysqlslap可以自动生成，默认生成一个mysqlslap的schema，如果已经存在则先 删除，这里要注意了，不要用–create-schema指定已经存在的库，否则后果可能很严重。可以用–only-print来打印实际的测试过程：

$mysqlslap -a --only-print
DROP SCHEMA IF EXISTS `mysqlslap`;
CREATE SCHEMA `mysqlslap`;
use mysqlslap;
CREATE TABLE `t1` (intcol1 INT(32) ,charcol1 VARCHAR(128));
INSERT INTO t1 VALUES (1804289383,'mxvtvmC9127qJNm06sGB8R92q2j7vTiiITRDGXM9ZLzkdekbWtmXKwZ2qG1llkRw5m9DHOFilEREk3q7oce8O3BEJC0woJsm6uzFAEynLH2xCsw1KQ1lT4zg9rdxBL');
...
SELECT intcol1,charcol1 FROM t1;
INSERT INTO t1 VALUES (364531492,'qMa5SuKo4M5OM7ldvisSc6WK9rsG9E8sSixocHdgfa5uiiNTGFxkDJ4EAwWC2e4NL1BpAgWiFRcp1zIH6F1BayPdmwphatwnmzdwgzWnQ6SRxmcvtd6JRYwEKdvuWr');
DROP SCHEMA IF EXISTS `mysqlslap`;

可以看到最后由删除一开始创建的schema的动作，整个测试完成后不会在数据库中留下痕迹。假如我们执行一次测试，分别50和100个并发，执行1000次总查询，那么：

$mysqlslap -a --concurrency=50,100 --number-of-queries 1000 --debug-info
Benchmark
Average number of seconds to run all queries: 0.375 seconds
Minimum number of seconds to run all queries: 0.375 seconds
Maximum number of seconds to run all queries: 0.375 seconds
Number of clients running queries: 50
Average number of queries per client: 20
Benchmark
Average number of seconds to run all queries: 0.453 seconds
Minimum number of seconds to run all queries: 0.453 seconds
Maximum number of seconds to run all queries: 0.453 seconds
Number of clients running queries: 100
Average number of queries per client: 10
User time 0.29, System time 0.11
Maximum resident set size 0, Integral resident set size 0
Non-physical pagefaults 4032, Physical pagefaults 0, Swaps 0
Blocks in 0 out 0, Messages in 0 out 0, Signals 0
Voluntary context switches 7319, Involuntary context switches 681

上结果可以看出，50和100个并发分别得到一次测试结果(Benchmark)，并发数越多，执行完所有查询的时间越长。为了准确起见，可以多迭代测试几次:

$ mysqlslap -a --concurrency=50,100 --number-of-queries 1000 --iterations=5 --debug-info
Benchmark
Average number of seconds to run all queries: 0.380 seconds
Minimum number of seconds to run all queries: 0.377 seconds
Maximum number of seconds to run all queries: 0.385 seconds
Number of clients running queries: 50
Average number of queries per client: 20
Benchmark
Average number of seconds to run all queries: 0.447 seconds
Minimum number of seconds to run all queries: 0.444 seconds
Maximum number of seconds to run all queries: 0.451 seconds
Number of clients running queries: 100
Average number of queries per client: 10
User time 1.44, System time 0.67
Maximum resident set size 0, Integral resident set size 0
Non-physical pagefaults 17922, Physical pagefaults 0, Swaps 0
Blocks in 0 out 0, Messages in 0 out 0, Signals 0
Voluntary context switches 36796, Involuntary context switches 4093

测试同时不同的存储引擎的性能进行对比：

$ mysqlslap -a --concurrency=50,100 --number-of-queries 1000 --iterations=5 --engine=myisam,innodbmysqlslap -a --concurrency=50,100 --number-of-queries 1000 --iterations=5 --engine=myisam,innodb --debug-info
Benchmark
Running for engine myisam
Average number of seconds to run all queries: 0.200 seconds
Minimum number of seconds to run all queries: 0.188 seconds
Maximum number of seconds to run all queries: 0.210 seconds
Number of clients running queries: 50
Average number of queries per client: 20
Benchmark
Running for engine myisam
Average number of seconds to run all queries: 0.238 seconds
Minimum number of seconds to run all queries: 0.228 seconds
Maximum number of seconds to run all queries: 0.251 seconds
Number of clients running queries: 100
Average number of queries per client: 10
Benchmark
Running for engine innodb
Average number of seconds to run all queries: 0.375 seconds
Minimum number of seconds to run all queries: 0.370 seconds
Maximum number of seconds to run all queries: 0.379 seconds
Number of clients running queries: 50
Average number of queries per client: 20
Benchmark
Running for engine innodb
Average number of seconds to run all queries: 0.443 seconds
Minimum number of seconds to run all queries: 0.440 seconds
Maximum number of seconds to run all queries: 0.447 seconds
Number of clients running queries: 100
Average number of queries per client: 10
User time 2.83, System time 1.66
Maximum resident set size 0, Integral resident set size 0
Non-physical pagefaults 34692, Physical pagefaults 0, Swaps 0
Blocks in 0 out 0, Messages in 0 out 0, Signals 0
Voluntary context switches 87306, Involuntary context switches 10326

MySQL Replication可以将master的数据复制分布到多个slave上，然后可以利用slave来分担master的读压力。那么对于前台应用来说，就要考虑如何将读的压力分布到多个slave上。如果每个应用都需要来实现读写分离的算法，一则成本太高，二来如果slave增加更多的机器，应用就要随之修改。明显的，如果在应用和数据库间加一个专门用于实现读写分离的中间层，则整个系统的架构拥有更好的扩展性。MySQL Proxy就是这么一个中间层代理，简单的说，MySQL Proxy就是一个连接池，负责将前台应用的连接请求转发给后台的数据库，并且通过使用lua脚本，可以实现复杂的连接控制和过滤，从而实现读写分离和负载平衡。对于应用来说，MySQL Proxy是完全透明的，应用则只需要连接到MySQL Proxy的监听端口即可。当然，这样proxy机器可能成为单点失效，但完全可以使用多个proxy机器做为冗余，在应用服务器的连接池配置中配置到多个proxy的连接参数即可。

MySQL Proxy是2007年6月由Jan Kneschke发布的一个项目，基于GPL，目前还处于Alpha测试阶段，最新版本0.6.1，可以从这里下载。使用MySQL Proxy需要MySQL 5.0.x以上版本，详细的安装使用手册可以参考MySQL 5.1手册第27章。

mysql-proxy --help-all
Usage:
  mysql-proxy.exe [OPTION...] - MySQL Proxy
Help Options:
  -?, --help     Show help options
  --help-all      Show all help options
  --help-admin    Show options for the admin-module
  --help-proxy    Show options for the proxy-module
admin module
  --admin-address=<host:port>   listening address:port of internal admin-server (default:4041)
proxy-module
  --proxy-address=<host:port>   listening address:port of the proxy-server (default:4040)
  --proxy-read-only-backend-addresses=<host:port>  address:port of the remote slave-server (default: not set)
  --proxy-backend-addresses=<host:port>   address:port of the remote backend-servers (default: 127.0.0.1:3306)
  --proxy-skip-profiling  disables profiling of queries (default: enabled)
  --proxy-fix-bug-25371  fix bug #25371 (mysqld > 5.1.12) for older libmysql versions
  --proxy-lua-script=<file>   filename of the lua script (default: not set)
  --no-proxy     Don't start proxy-server
Application Options:
  -V, --version      Show version
  --daemon        Start in daemon-mode
  --pid-file=<file>    PID file in case we are started as daemon

一、主要功能

    DRBD实际上是一种块设备的实现,主要被用于Linux平台下的高可用(HA)方案之中。他是有内核模块和相关程序而组成，通过网络通信来同步镜像整个设备，有点类似于一个网络RAID的功能。也就是说当你将数据写入本地的DRBD设备上的文件系统时,数据会同时被发送到网络中的另外一台主机之上，并以完全相同的形式记录在一个文件系统中（实际上文件系统的创建也是由DRBD的同步来实现的）。本地节点（主机）与远程节点（主机）的数据可以保证实时的同步，并保证IO的一致性。所以当本地节点的主机出现故障时,远程节点的主机上还会保留有一份完全相同的数据,可以继续使用，以达到高可用的目的。

    在高可用(HA)解决方案中使用DRBD的功能,可以代替使用一个共享盘阵存储设备。因为数据同时存在于本地主机和远程主机上,在遇到需要切换的时候,远程主机只需要使用它上面的那份备份数据,就可以继续提供服务了。

二、底层设备支持

    DRBD需要构建在底层设备之上，然后构建出一个块设备出来。对于用户来说，一个DRBD设备，就像是一块物理的磁盘，可以在商脉内创建文件系统。DRBD所支持的底层设备有以下这些类：

    1、一个磁盘，或者是磁盘的某一个分区；

    2、一个soft raid 设备；

    3、一个LVM的逻辑卷；

    4、一个EVMS（Enterprise Volume Management System，企业卷管理系统）的卷；

    5、其他任何的块设备。

三、配置简介

    1、全局配置项（global）

        基本上我们可以做的也就是配置usage-count是yes还是no了，usage-count参数其实只是为了让linbit公司收集目前drbd的使用情况。当drbd在安装和升级的时候会通过http协议发送信息到linbit公司的服务器上面。

    2、公共配置项（common）

        这里的common，指的是drbd所管理的多个资源之间的common。配置项里面主要是配置drbd的所有resource可以设置为相同的参数项，比如protocol，syncer等等。

    3、资源配置项（resource）

        resource项中配置的是drbd所管理的所有资源，包括节点的ip信息，底层存储设备名称，设备大小，meta信息存放方式，drbd对外提供的设备名等等。每一个resource中都需要配置在每一个节点的信息，而不是单独本节点的信息。实际上，在drbd的整个集群中，每一个节点上面的drbd.conf文件需要是完全一致的。

        另外，resource还有很多其他的内部配置项：

        net：网络配置相关的内容，可以设置是否允许双主节点（allow-two-primaries）等。

        startup：启动时候的相关设置，比如设置启动后谁作为primary（或者两者都是primary：become-primary-on both）

        syncer：同步相关的设置。可以设置“重新”同步（re-synchronization）速度（rate）设置，也可以设置是否在线校验节点之间的数据一致性（verify-alg 检测算法有md5，sha1以及crc32等）。数据校验可能是一个比较重要的事情，在打开在线校验功能后，我们可以通过相关命令（drbdadm verify resource_name）来启动在线校验。在校验过程中，drbd会记录下节点之间不一致的block，但是不会阻塞任何行为，即使是在该不一致的block上面的io请求。当不一致的block发生后，drbd就需要有re-synchronization动作，而syncer里面设置的rate项，主要就是用于re-synchronization的时候，因为如果有大量不一致的数据的时候，我们不可能将所有带宽都分配给drbd做re-synchronization，这样会影响对外提提供服务。rate的设置和还需要考虑IO能力的影响。如果我们会有一个千兆网络出口，但是我们的磁盘IO能力每秒只有50M，那么实际的处理能力就只有50M，一般来说，设置网络IO能力和磁盘IO能力中最小者的30%的带宽给re-synchronization是比较合适的（官方说明）。另外，drbd还提供了一个临时的rate更改命令，可以临时性的更改syncer的rate值：drbdsetup /dev/drbd0 syncer -r 100M。这样就临时的设置了re-synchronization的速度为100M。不过在re-synchronization结束之后，你需要通过drbdadm adjust resource_name 来让drbd按照配置中的rate来工作。

五、资源管理

    1、增加resource的大小：

    当遇到我们的drbd resource设备容量不够的时候，而且我们的底层设备支持在线增大容量的时候（比如使用lvm的情况下），我们可以先增大底层设备的大小，然后再通过drbdadm resize resource_name来实现对resource的扩容。但是这里有一点需要注意的就是只有在单primary模式下可以这样做，而且需要先在所有节点上都增大底层设备的容量。然后仅在primary节点上执行resize命令。在执行了resize命令后，将触发一次当前primary节点到其他所有secondary节点的re-synchronization。

    如果我们在drbd非工作状态下对底层设备进行了扩容，然后再启动drbd，将不需要执行resize命令（当然前提是在配置文件中没有对disk参数项指定大小），drbd自己会知道已经增大了容量。

    在进行底层设备的增容操作的时候千万不要修改到原设备上面的数据，尤其是drbd的meta信息，否则有可能毁掉所有数据。

    2、收缩resource容量：

    容量收缩比扩容操作要危险得多，因为该操作更容易造成数据丢失。在收缩resource的容量之前，必须先收缩drbd设备之上的容量，也就是文件系统的大小。如果上层文件系统不支持收缩，那么resource也没办法收缩容量。

    如果在配置drbd的时候将meta信息配置成internal的，那么在进行容量收缩的时候，千万别只计算自身数据所需要的空间大小，还要将drbd的meta信息所需要的空间大小加上。

    当文件系统收缩好以后，就可以在线通过以下命令来重设resource的大小：drbdadm — –size=***G resize resource_name。在收缩的resource的大小之后，你就可以自行收缩释放底层设备空间（如果支持的话）。

    如果打算停机状态下收缩容量，可以通过以下步骤进行：

        a、在线收缩文件系统

        b、停用drbd的resource：drbdadm down resourcec_name

        c、导出drbd的metadata信息（在所有节点都需要进行）：drbdadm dump-md resource_name > /path_you_want_to_save/file_name

        d、在所有节点收缩底层设备

        e、更改上面dump出来的meta信息的la-size-sect项到收缩后的大小（是换算成sector的数量后的数值）

f、如果使用的是internal来配置meta-data信息，则需要重新创建meta-data:drbdadm create-md resource_name

g、将之前导出并修改好的meta信息重新导入drbd（摘录自linbit官方网站的一段导入代码）：

    drbdmeta_cmd=$(drbdadm -d dump-md test-disk)

            ${drbdmeta_cmd/dump-md/restore-md} /path_you_want_to_save/file_name
        h、启动resource：drbdadm up resource_name

六、磁盘损坏

    1、detach resource

        如果在resource的disk配置项中配置了on_io_error为pass_on的话，那么drbd在遇到磁盘损坏后不会自己detach底层设备。也就是说需要我们手动执行detach的命令（drbdadm detach resource_name），然后再查看当前各节点的ds信息。可以通过cat /proc/drbd来查看，也可以通过专有命令来查看：drbdadm dstat resource_name。当发现损坏的那方已经是Diskless后，即可。如果我们没有配置on_io_error或者配置成detach的话，那么上面的操作将会由自动进行。

        另外，如果磁盘损坏的节点是当前主节点，那么我们需要进行节点切换的操作后再进行上面的操作。

    2、更换磁盘

        当detach了resource之后，就是更换磁盘了。如果我们使用的是internal的meta-data，那么在换好磁盘后，只需要重新创建mata-data（drbdadm create-md resource_name），再将resource attach上（drbdadm attach resource_name），然后drbd就会马上开始从当前primary节点到本节点的re-synchronisation。数据同步的实时状况可以通过 /proc/drbd文件的内容获得。

        不过，如果我们使用的不是internal的meta-data保存方式，也就是说我们的meta-data是保存在resource之外的地方的。那么我们在完成上面的操作（重建meta-data）之后，还需要进行一项操作来触发re-synchnorisation，所需命令为：drbdadm invalidate resource_name 。

七、节点crash（或计划内维护）

    1、secondary节点

        如果是secondary接待你crash，那么primary将临时性的与secondary断开连接，cs状态应该会变成WFConnection，也就是等待连接的状态。这时候primary会继续对外提供服务，并在meta-data里面记录下从失去secondary连接后所有变化过的block的信息。当secondary重新启动并连接上primary后，primary –> secondary的re-synchnorisation会自动开始。不过在re-synchnorisation过程中，primary和secondary的数据是不一致状态的。也就是说，如果这个时候primary节点也crash了的话，secondary是没办法切换成primary的。也就是说，如果没有其他备份的话，将丢失所有数据。

    2、primary节点

        一般情况下，primary的crash和secondary的crash所带来的影响对drbd来说基本上是差不多的。唯一的区别就是需要多操作一步将secondary节点switch成primary节点先对外提供服务。这个switch的过程drbd自己是不会完成的，需要我们人为干预进行一些操作才能完成。当crash的原primary节点修复并重新启动连接到现在的primary后，会以secondary存在，并开始re-synchnorisation这段时间变化的数据。

        在primary节点crash的情况下，drbd可以保证同步到原secondary的数据的一致性，这样就避免了当primary节点crash之后，secondary因为数据的不一致性而无法wcitch成primary或者即使切换成primary后因为不一致的数据无法提供正常的服务的问题。

    3、节点永久性损坏（需要更换机器或重新安装相关软件的情况）

        当某一个节点因为硬件（或软件）的问题，导致某一节点已经无法再轻易修复并提供服务，也就是说我们所面对的是需要更换主机（或从OS层开始重新安装）的问题。在遇到这样的问题后，我们所需要做的是重新提供一台和原节点差不多的机器，重新开始安装os，安装相关软件，从现有整提供服务的节点上copy出drbd的配置文件（/etc/drbd.conf），创建meta-data信息，然后启动drbd服务，以一个secondary的身份连接到现有的primary上面，后面就会自动开始re-synchnorisation。

八、split brain的处理

    split brain实际上是指在某种情况下，造成drbd的两个节点断开了连接，都以primary的身份来运行。当drbd某primary节点连接对方节点准备发送信息的时候如果发现对方也是primary状态，那么会会立刻自行断开连接，并认定当前已经发生split brain了，这时候他会在系统日志中记录以下信息：“Split-Brain detected,dropping connection!”当发生split brain之后，如果查看连接状态，其中至少会有一个是StandAlone状态，另外一个可能也是StandAlone（如果是同时发现split brain状态），也有可能是WFConnection的状态。

    如果我们在配置文件中配置了自动解决split brain（好像linbit不推荐这样做），drbd会自行解决split brain问题，具体解决策略是根据配置中的设置来进行的。

    如果没有配置split brain自动解决方案，我们可以手动解决。首先我们必须要确定哪一边应该作为解决问题后的primary，一旦确定好这一点，那么我们同时也就确定接受丢失在split brain之后另外一个节点上面所做的所有数据变更了。当这些确定下来后，我们就可以通过以下操作来恢复了：

    a、首先在确定要作为secondary的节点上面切换成secondary并放弃该资源的数据：

        drbdadm secondary resource_name

        drbdadm — –discard-my-data connect resource_name

    b、在要作为primary的节点重新连接secondary（如果这个节点当前的连接状态为WFConnection的话，可以省略）

        drbdadm connect resource_name

    当作完这些动作之后，从新的primary到secondary的re-synchnorisation会自动开始。

八、meta data存放地点的比较

    1、internal meta-data（meta-data和数据存放在同一个底层设备之上）

    优点：一旦meta-data创建之后，就和实际数据绑在了一起，在维护上会更简单方便，不用担心meta-data会因为某些操作而丢失。另外在硬盘损坏丢失数据的同时，meta-data也跟着一起丢失，当更换硬盘之后，只需要执行重建meta-data的命令即可，丢失的数据会很容易的从其他节点同步过来。

    缺点：如果底层设备是单一的磁盘，没有做raid，也不是lvm等，那么可能会造成性能影响。因为每一次写io都需要更新meta-data里面的信息，那么每次写io都会有两次，而且肯定会有磁头的较大寻道移动，因为meta-data都是记录在dice设备的最末端的，这样就会造成写io的性能降低。

    2、external meta data（meta-data存放在独立的，与存放数据的设备分开的设备之上）

    优点：与internal meta-data的缺点完全相对，可以解决写io的争用问题。

    缺点：由于meta-data存放在与数据设备分开的地方，就意味着当磁盘损坏更换磁盘之后，必须手动发起全量同步的操作。也就是管理维护会稍微麻烦那么一点点，很小的一点点。

    如果我们希望在已经存在数据的设备上面建立drbd的资源，并且不希望丢失该设备上面的数据，又没办法增大底层设备的容量，而且上层文件系统又没办法收缩的话，我们就只能将meta data创建成external方式。

要实施复制，首先必须打开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 server来扩展slave的数量，将读压力分散到多台slave的机器上面，即可解决数据库端的读压力瓶颈。这在很大程度上解决了目前很多中小型网站 的数据库压力瓶颈问题，甚至有些大型网站也在使用类似方案解决数据库瓶颈。
一个Master带多个slave的架构实施非常简单，多个slave和单个slave的实施并没有太大区别。在Master端并不care有多少个 slave连上了master端，只要有slave进程通过了连接认证，向他请求binlog信息，他就会按照连接上来的io进程的要求，读取自己的 binlog信息，返回给slave的IO进程。对于slave的配置细节，在Mysql的官方文档上面已经说的很清楚了，甚至介绍了多种实现slave 的配置方法。

Mysql不支持一个Slave instance从属于多个Master的架构。就是说，一个slave instance只能接受一个master的同步源，听说有patch可以改进这样的功能，但没有实践过。Mysql AB之所以不实现这样的功能，主要是考虑到冲突解决的问题。

Mysql也可以搭建成dual master模式，也就是说两个Mysql instance互为对方的Master，也同时为对方的Slave。不过一般这种架构也是只有一端提供服务，避免冲突问题。因为即使在两边执行的修改有 先后顺序，由于复制的异步实现机制，同样会导致即使在晚做的修改也可能会被早做的修改所覆盖，就像如下情形：
时间点   Mysql A                        Mysql B
1    更新x表y记录为10
2                                 更新x表y记录为20
3                                 获取到A日志并应用，更新x表的y记录为10（不符合期望）
4    获取B日志更新x表y记录为20（符合期望）
这样，不仅在B库上面的数据不是用户所期望的结果，A和B两边的数据也出现了不一致的情况。除非能将写操作根据某种条件固定分开在A和B两端，保证不会交叉写入，才能够避免上面的问题。

下面sql查询缓存认为是不同的：
SELECT * FROM tbl_name
Select * from tbl_name
查询缓存相关参数

mysql> SHOW VARIABLES LIKE '%query_cache%';
+------------------------------+---------+
| Variable_name                | Value   |
+------------------------------+---------+
| have_query_cache             | YES     | --查询缓存是否可用
| query_cache_limit            | 1048576 | --可缓存具体查询结果的最大值
| query_cache_min_res_unit     | 4096    |
| query_cache_size             | 599040  | --查询缓存的大小
| query_cache_type             | ON      | --阻止或是支持查询缓存
| query_cache_wlock_invalidate | OFF     |
+------------------------------+---------+

下面是一个简单的例子：

[mysql@csdba1850 ~]$ mysql -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.0.45-community MySQL Community Edition (GPL)
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql> set global query_cache_size = 600000; --设置缓存内存
Query OK, 0 rows affected (0.00 sec)
mysql> set session query_cache_type = ON; --开启查询缓存
Query OK, 0 rows affected (0.00 sec)
mysql> use test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show tables;
+----------------+
| Tables_in_test |
+----------------+
| animals        |
| person         |
+----------------+
5 rows in set (0.00 sec)
mysql> select count(*) from animals;
+----------+
| count(*) |
+----------+
|        6 |
+----------+
1 row in set (0.00 sec)
--Qcache_hits表示sql查询在缓存中命中的累计次数，是累加值。
mysql> SHOW STATUS LIKE 'Qcache_hits';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Qcache_hits   | 0     |  --0次
+---------------+-------+
8 rows in set (0.00 sec)
mysql>  select count(*) from animals;
+----------+
| count(*) |
+----------+
|        6 |
+----------+
1 row in set (0.00 sec)
mysql>  SHOW STATUS LIKE 'Qcache%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Qcache_hits   | 1     | --表示sql在缓存中直接得到结果，不需要再去解析
+---------------+-------+
8 rows in set (0.00 sec)
mysql> select count(*) from animals;
+----------+
| count(*) |
+----------+
|        6 |
+----------+
1 row in set (0.00 sec)
mysql> select count(*) from animals;
+----------+
| count(*) |
+----------+
|        6 |
+----------+
1 row in set (0.00 sec)
mysql> SHOW STATUS LIKE 'Qcache_hits';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Qcache_hits   | 3     |    --上面的sql也是是从缓存中直接取到结果
+---------------+-------+
1 row in set (0.00 sec)
mysql> insert into animals select 9,'testsds' ; --插入数据后，跟这个表所有相关的sql缓存就会被清空掉
Query OK, 1 row affected (0.00 sec)
Records: 1  Duplicates: 0  Warnings: 0
mysql> select count(*) from animals;
+----------+
| count(*) |
+----------+
|        7 |
+----------+
1 row in set (0.00 sec)
mysql> SHOW STATUS LIKE 'Qcache_hits';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Qcache_hits   | 3    |  --还是等于3，说明上一条sql是没有直接从缓存中直接得到的
+---------------+-------+
1 row in set (0.00 sec)
mysql> select count(*) from animals;
+----------+
| count(*) |
+----------+
|        7 |
+----------+
1 row in set (0.00 sec)
mysql> SHOW STATUS LIKE 'Qcache_hits';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Qcache_hits   | 4     |
+---------------+-------+
1 row in set (0.00 sec)

如果在CIB的配置文件中不做出任何配置的话，那么每一个资源的初始分数（resource-stickiness）都会是默认的0，而且每一个资源在每次失败之后所减掉的分数（resource-failure-stickiness）也是0。如此的话，一个资源不论他失败多少次，heartbeat都只是执行restart操作，不会进行节点切换。一般来说，resource-stickiness的值都是正数，resource-failure-stickiness的值都是负数。另外还有一个特殊值那就是正无穷大（INFINITY）和负无穷大（-INFINITY）。如果节点的分数为负分，那么不管什么情况发生，该节点都不会接管资源（冷备节点）。随着资源的各种状态的发生，在各节点上面的分数就会发生变化，随着分数的变化，一旦某节点的分数大于当前运行该资源的节点的分数之后，heartbeat就会做出切换动作，现在运行该资源的节点将释放资源，分数高出的节点将接管该资源。

在CIB的配置中，可以给每个资源定义一个分数，通过resource-stickiness来设置，同样也可以设置一个失败后丢失的分数，通过resource-failure-stickiness来设置。如下：

<primitive id=”mysql_db” class=”ocf” type=”mysql” provider=”heartbeat”>

<meta_attributes id=”mysql_db_meta_attr”>
<attributes>
<nvpair name=”resource_stickiness” id=”mysql_db_meta_attr_1″ value=”100″/>
<nvpair name=”resource_failure_stickiness” id=”mysql_db_meta_attr_2″ value=”-100″/>
</attributes>
</meta_attributes>

…

<primitive />

上面的配置就是给mysql_db这个resource配置了两个分数，成功运行的时候所得到的分数（resource_stickiness）和运行失败会丢失的分数（resource_failure_stickiness），两项分数值一样多，成功则得100分，失败则-100分。

除了可以通过给每个资源单独设置两项的分数之外，也可以将所有的resource设置成相同的分数，如下：

<configuration>
<crm_config>
<cluster_property_set id=”cib-bootstrap-options”>
<attributes>
…

<nvpair id=”default-resource-failure-stickiness” name=”default-resource-failure-stickiness” value=”-100″/>
<nvpair id=”default-resource-stickiness” name=”default-resource-stickiness” value=”100″/>
…

</attributes>
</cluster_property_set>
</crm_config>

…

在这个配置中，就是给所有资源设置了两个默认的分数，省去单独每个资源都设置的麻烦。当然，如果在设置了这个default分数之后，同时也给部分或者全部资源也设置了这两个分数的话，将取单独设置的各个资源设置的分数而不取默认分数。

除了资源的分数之外，节点自身同样也有分数。节点分数可以如下设置：

…

<constraints>
<rsc_location id=”rsc_location_group_mysql” rsc=”group_mysql”>
<rule id=”mysql1_group_mysql” score=”200″>
<expression id=”mysql1_group_mysql_expr” attribute=”#uname” operation=”eq” value=”mysql1″/>
</rule>
<rule id=”mysql2_group_mysql” score=”150″>
<expression id=”mysql2_group_mysql_expr” attribute=”#uname” operation=”eq” value=”mysql2″/>
</rule>
</rsc_location>
</constraints>
…

注意这里节点分数的设置是放在configuration配置项里面的constraints配置项下的，通过rule来设置。这里是通过节点主机名来匹配的（实际上heartbeat的很多配置中对主机名都是很敏感的）。这里的value值就是节点的主机名，rule里面的score就是一个节点的分数。

通过上面的配置，我们可以作出如下计算：

a、在最开始，两边同时启动heartbeat的话，两边都没有开始运行这个resource，resource本身没有分数，那么仅仅计算节点的分数：

mysql1的分数：node+resource+failcount*failure=200+0+(0*(-100))=200

mysql2的分数：node+resource+failcount*failure=150+0+(0*(-100))=150

heartbeat会做出选择在mysql1上面运行mysql_db这个资源，然后mysql1的分数发生变化了，因为有资源自身的分数加入了：

mysql1的分数：node+resource+failcount*failure=200+100+(0*(-100))=300

mysql2的分数：node+resource+failcount*failure=150+0+(0*(-100))=150

b、过了一段时间，heartbeat的monitor发现mysql_db这个资源crash（或者其他问题）了，分数马上会发生变化，如下：

mysql1的分数：node+resource+failcount*failure=200+100+(1*(-100))=200

mysql2的分数：node+resource+failcount*failure=150+0+(0*(-100))=150

heartbeat发现mysql1节点的分数还是比mysql2的高，那么资源不发生迁移，将执行restart类操作。

c、继续运行一段时间发现又有问题（或者是b后面restart没有起来）了，分数又发生变化了：

mysql1的分数：node+resource+failcount*failure=200+100+(2*(-100))=100

mysql2的分数：node+resource+failcount*failure=150+0+(0*(-100))=150

这时候heartbeat发现mysql2节点比mysql1节点的分数高了，资源将发生迁移切换，mysql1释mysql_db相关资源，mysql2接管相关资源，并在mysql2上运行mysql_db这个资源。这时候，节点的分数又会发生变化如下：

mysql1的分数：node+resource+failcount*failure=200+0+(2*(-100))=0

mysql2的分数：node+resource+failcount*failure=150+100+(0*(-100))=250

这时候如果在mysql2上面三次出现问题，那么mysql2的分数将变成-50，又比mysql1少了，资源将迁移回mysql1，mysql1的分数将变成100，而mysql2的分数将变成-150，因为又少了资源所有者的那100分。到这里，mysql2节点的分数已经是负数了。heartbeat还有一个规则，就是资源永远都不会迁移到一个分数分数是负数的节点上面去。也就是说从这以后，mysql1节点上面不管mysql_db这个资源失败多少次，不管这个资源出现什么问题，都不会迁移回mysql2节点了。一个节点的分数会在该节点的heartbeat重启之后被重置为初始状态。或者通过相关命令来对集群中某个节点的某个资源或者资源组来重置或者查看其failcount，如下：

crm_failcount -G -U mysql1 -r mysql_db        #将查看mysql1节点上面的mysql_db这个资源的failcount

crm_failcount -D -U mysql1 -r mysql_db        #将重置mysql1节点上面的mysql_db这个资源的failcount

当然，在实际应用中，我们一般都是将某一些互相关联的资源放到一起组成一个资源组，一旦资源组中某资源有问题的时候，需要迁移整个资源组的资源。这个和上面针对单个资源的情况实际上没有太多区别，只需要将上面mysql_db的设置换到资源组即可，如下：

…

<group id=”group-mysql”>
<meta_attributes id=”group-mysql_meta_attr”>
<attributes>
<nvpair id=”group-mysql_meta_attr-1″ name=”resource_stickiness” value=”100″/>
<nvpair id=”group-mysql_meta_attr-1″ name=”resource_failure_stickiness” value=”-100″/>
</attributes>
</meta_attributes>
<primitive>
…
</primitive>
…
</group>

…

这样，在该资源组中任何一个资源出现问题之后，都会被认为该资源组有问题，当分数低于其他节点出现切换的时候就是整个资源组的切换。

另外，对于INFINITY和-INFINITY这两个值，实际上主要用途就是为了控制永远不切换和只要失败必须切换用的。因为代表的意思就是拥有正无穷大的分数和失败就到负无穷大，主要用来满足极端规则的简单配置项。

总的来说，一项资源（或者资源组）在一个节点运行迁移到另一个节点之前，可以失败的次数的计算公式可以如下表示：

(nodeA score - nodeB score + stickiness)/abs(failure stickiness)，即为A节点分数减去B节点分数，再加上资源运行分数后得到的总分数，除以资源失败分数的绝对值。]]>文档http://blog.bigcomic.com/post/253.html#commenthttp://blog.bigcomic.com/http://blog.bigcomic.com/feed.asp?cmt=253http://blog.bigcomic.com/cmd.asp?act=tb&id=253&key=812b1b93pencat@bigfoot.com (pencat)http://blog.bigcomic.com/post/252.htmlWed, 03 Dec 2008 15:59:15 +0800http://blog.bigcomic.com/post/252.html一、heartbeat模块：

    整个Heartbeat软件的通信模块，各个节点之间的任何通信都是通过这个模块完成。这个模块会根据不同类型的通信启动不同的事件handler，当监听到不同类型的通信请求后会分给不同的handler来处理。这个从整个Heartbeat的启动日志中看出来。

二、CRM：cluster resource manager

    从这个名字就可以看出这个模块基本上就是v2的heartbeat的一个只会中心，整个系统的一个大脑了，他主要负责整个系统的各种资源的当前配置信息，以及各个资源的调度。也就是根据各资源的配置信息，以及当前的运行状况来决定每一个资源（或者资源组）到底该在哪个节点运行。不过这些事情并不是他直接去做的，而是通过调度其他的一些模块来进行。

    他通过heartbeat模块来进行节点之间的通信，调度节点之间的工作协调。随时将通过heartbeat模块收集到的各个成员节点的基本信息转交给CCM某块来更新整个集群的membership信息。他指挥LRM（local resource manager）对当前节点的各资源执行各种相应的操作（如start、stop、restart和monitor等等），同时也接收LRM在进行各种操作的反馈信息并作出相应的决策再指挥后续工作。另外CRM模块还负责将各个模块反馈回来的各种信息通过调用设定的日志记录程序记录到日志文件中。

三、LRM：local resource manager

    LRM是整个Heartbeat系统中直接操作所管理的各个资源的一个模块，负责对资源的监控，启动，停止或者重启等操作。这个模块目前好像支持有四种类型的资源代理（resource agent）：heartbeat自身的，ocf（open cluster framework），lsb（linux standard base，其实就是linux下标准的init脚本），还有一种就是stonith。stonith这种我还不是太清楚是一个什么类型的。

    四种类型的resource agent中的前三种所调用的脚本分别存如下路径：

        heartbeat：/etc/ha.d/resource.d/

        ocf:/usr/lib/resource.d/heartbeat/

        lsb:/etc/init.d/

    LRM就是通过调用以上路径下面的各种脚本来实现对资源的各种操作。每一种类型的脚本都可以由用户自定义，只要支持各类型的标准即可。实际上这里的标准就是接受一个标准的调用命令和参数格式，同时返回符合标准的值即可。至于脚本中的各种操作时如何的LRM并不care。

四、PE：CRM Policy Engine

    他主要负责将CRM发过来的一些信息按照配置文件中的各种设置来进行计算，分析。然后将结果信息按照某种固定的格式通过CRM提交给TE（Transition engine）去分析出后续需要采取的相应的action。PE需要计算分析的信息主要是当前有哪些节点，各节点的状况，当前管理有哪些资源，各资源当前在哪一个节点，在各个节点的状态如何等等。

五、TE：Transition engine

    主要工作是分析PE的计算结果，然后根据配置信息转换成后续所需的相应操作。个人感觉PE和TE组合成一个类似于规则引擎实现的功能，而且PE和TE这两个模块只有在处于active的节点被启动。另外PE和TE并不直接通信，而都是通过Heartbeat的指挥中心CRM来传达信息的。

六、CIB：cluster information base

    CIB在系统中充当的是当前集群中各资源原始配置以及之后动态变化了的状态，统计信息收集分发中心，是一个不断更新的信息库。当他收集到任何资源的变化，以及节点统计信息的变化后，都会集成整合到一起组成当前集群最新的信息，并分发到集群各个节点。分发动作并不是自己和各个节点通信，同样也是通过heartbeat模块来做的。

    CIB收集整理并汇总出来的信息是以一个xml格式保存起来的。实际上Heartbeat v2的资源配置文件也就是从haresources迁移到了一个叫cib.xml文件里面。该文件实际上就是CIB的信息库文件。在运行过程中，CIB可能会常读取并修改该文件的内容，以保证信息的更新。

七、CCM：consensus cluster membership

    CCM的最主要工作就是管理集群中各个节点的成员以及各成员之间的关系。他让集群中各个节点有效的组织称一个整体，保持着稳定的连接。heartbeat模块所担当的只是一个通信工具，而CCM是通过这个通信工具来将各个成员连接到一起成为一个整体。

八、LOGD：logging daemon（non-blocking）

    一个无阻塞的日志记录程序，主要负责接收CRM从各个其他模块所收集的相关信息，然后记录到指定额度日志文件中。当logd接收到日志信息后会立刻返回给CRM反馈。并不是一定要等到将所有信息记录到文件后再返回，日志信息的记录实际上是一个异步的操作。

九、APPHBD：application heartbeat daemon

    apphbd模块实际上是给各个模块中可能需要用到的计时用的服务，是通过watchdog来实现的。这个模块具体的细节我还不是太清楚。

十、RMD：recovery manager daemon

    主要功能是进程恢复管理，接受从apphbd所通知的某个（或者某些）进程异常退出或者失败或者hang住后的恢复请求。RMD在接受到请求后会作出restart（如果需要可能会有kill）操作。

redhat 9.0
mysql3.23.57

mysql数据同步备份

A服务器： 192.168.1.2 主服务器master
B服务器： 192.168.1.3 副服务器slave

A服务器设置

#mysql –u root –p
mysql>GRANT FILE ON *.* TO backup@10.168.2.3 IDENTIFIED BY  'pencat';
mysql>\exit

上面是Master开放一个账号backup密码1234给IP:10.168.2.3有档案处理的权限

mysqladmin –u root –p shutdown

备份Master所有数据库..通常都用tar指令.
#tar –cvf /tmp/mysql.tar /var/lib/mysql
注意:tar的时候,MySQL是要在stop情况下

在A机器上修改/etc/my.cnf
在[mysqld]区段内加入参数
log-bin
server-id=1
sql-bin-update-same
binlog-do-db=vbb

重启A服务器mysql

此时因为有加入log-bin参数,因此开始有index产生了,在/var/lib/mysql目录下有.index档案纪录数据库的异动log.

B服务器设置

设定/etc/my.cnf
在[mysqld]区段加入

master-host=10.168.2.2
master-user=backup
master-password=pencat
master-port=3306
server-id=2
master-connect-retry=60 预设重试间隔60秒
replicate-do-db=pencat_db告诉slave只做pencat_db数据库的更新
log-slave-updates

将A上的mysql.tar copy到B上
用ftp传B的/tmp
9.解压缩
#cd /var/lib/

状况测试
1.A跟B网络及服务都正常情况下,由A端变化数据后,到B端浏览数据,检视是否有进行replication?!
2.模拟B当机,或是B不一定需要一直跟A有连接.
将由A端变化数据后,到B端浏览数据，B点应该是没有数据变化的

#tar xvf /tmp/mysql-snapshot.tar
#chown –R mysql:mysql mysql

1重启B服务器的mysql

这时在/var/lib/mysql目录会出现master.info,此档案纪录了Master MySQL server的信息.

状况测试
1.A跟B网络及服务都正常情况下,由A端变化数据后,到B端浏览数据,检视是否有进行replication?!
2.模拟B当机,或是B不一定需要一直跟A有连接.
将由A端变化数据后,到B端浏览数据，B点应该是没有数据变化的

mysql数据同步小技巧

如果slave服务器出了某种问题，比如数据不同步了，可以检查或者使得master database恢复到某个状态，然后执行：

show master status

看看binlog文件和position是什么，然后在salve上面执行：

stop slave;

change master to master_log_file="", master_log_pos=...

start slave;

即可]]>开发随笔http://blog.bigcomic.com/post/249.html#commenthttp://blog.bigcomic.com/http://blog.bigcomic.com/feed.asp?cmt=249http://blog.bigcomic.com/cmd.asp?act=tb&id=249&key=dc1c46f6pencat@bigfoot.com (pencat)http://blog.bigcomic.com/post/248.htmlTue, 02 Dec 2008 20:39:15 +0800http://blog.bigcomic.com/post/248.html来源:http://www.muduo.net/batch.viewlink.php?itemid=311439 

MySQL本身没有提供replication failover的解决方案(见How can I use replication to provide redundancy or high availability?)

如何使Replication方案具有HA？ 答案是MMM(MySQL Master-Master Replication Manager)

MMM对MySQL Master-Slave Replication绝对是一个很有益的补充!

引言
Master-Slave的数据库机构解决了很多问题，特别是read/write比较高的web2.0应用：
1、写操作全部在Master结点执行，并由Slave数据库结点定时(默认60s)读取Master的bin-log
2、将众多的用户读请求分散到更多的数据库节点，从而减轻了单点的压力
这是对Replication的最基本陈述，这种模式的在系统Scale-out方案中很有引力(如有必要，数据可以先进行Sharding，再使用replication)。

它的缺点是：
1、Slave实时性的保障，对于实时性很高的场合可能需要做一些处理
2、高可用性问题，Master就是那个致命点(SPOF:Single point of failure)

本文主要讨论的是如何解决第2个缺点。

DB的设计对大规模、高负载的系统是极其重要的。高可用性(High availability)在重要的系统(critical System)是需要架构师事先考虑的。存在SPOF:Single point of failure的设计在重要系统中是危险的。

Master-Master Replication
1、使用两个MySQL数据库db01,db02，互为Master和Slave，即：一边db01作为db02的master，一旦有数据写向db01时，db02定时从db01更新 另一边db02也作为db01的master，一旦有数据写向db02时，db01也定时从db02获得更新 (这不会导致循环，MySQL Slave默认不会记录Master同步过来的变化)

2、但从AppServer的角度来说，同时只有一个结点db01扮演Master，另外一个结点db02扮演Slave，不能同时两个结点扮演Master。即AppSever总是把write操作分配某个数据库(db01)，除非db01 failed，被切换。

3、如果扮演Slave的数据库结点db02 Failed了：
     a)此时appServer要能够把所有的read,write分配给db01，read操作不再指向db02
     b)一旦db02恢复过来后，继续充当Slave角色，并告诉AppServer可以将read分配给它了

4、如果扮演Master的数据库结点db01 Failed了
     a)此时appServer要能够把所有的写操作从db01切换分配给db02，也就是切换Master由db02充当
     b)db01恢复过来后，充当Slave的角色，Master由db02继续扮演

难点：
3、4要如何自动进行？

Master-Master with n Slaves Replication

这比上一个还要复杂，即：当一个Master Fail时，所有的Slave不再从原来失败的那个Master(db01)获取更新日志，而应该“自动”切换到最新充当Master角色的数据库db02。

MMM，a greate project!

MMM的基本信息请参考它的网站(见后"参考资料")
MMM有3个重要的器件:
1、mmmd_mon - monitoring script which does all monitoring work and makes all decisions about roles moving and so on.

2、mmmd_agent - remote servers management agent script, which provides monitoring node with simple set of remote services to make servers management easier, more flexible abd highly portable.
3、mmm_control - simple script dedicated to management of the mmmd_mon processes by commands.

每一个MySQL服务器器结点需要运行mmmd_agent，同时在另外的一个机器上(可以是独立的一台机器，也可以是和AppServer共享同一个服务器)运行mmmd_mon。形成1 * mmmd_mon + n * mmmd_agent的部署架构。

MMM利用了虚拟IP的技术：1个网卡可以同时使用多个IP。(所以使用MMM时，需要2*n+1个IP，n为mysql数据库结点个数，包括master,slave)

当有数据库结点fail时，mmmd_mon检测不到mmmd_agent的心跳或者对应的MySQL服务器的状态，mmmd_mon将进行决定，并下指令给某个正常的数据库结点的mmmd_agent，使得该mmmd_agent“篡位”使用(注)刚才fail的那个结点的虚拟IP，使得虚拟IP实际从指向fail的那个机器自动转为此时的这个正常机器。

注：据Qieqie猜测是将获得的虚拟IP设置给网卡，也只能这样了，改天测试验证一下。

repeat: MMM对MySQL Master-Slave Replication绝对是一个很有益的补充!

参考资料
Switching Masters During Failover
http://dev.mysql.com/doc/refman/5.1/en/replication-solutions-switch.html
downpour: 讨论一下基于Master-Slave数据库模式的J2EE开发的框架选择
http://www.javaeye.com/topic/143714
MMM http://blog.kovyrin.net/mysql-master-master-replication-manager/
Project page on Google Code: http://code.google.com/p/mysql-master-master
mmm-devel users group: http://groups.google.com/group/mmm-devel

自动测试：
–auto-generate-sql，自动产生测试SQL
–auto-generate-sql-load-type，测试SQL的类型。类型有mixed，update，write，key，read。
–number-of-queries，执行的SQL总数量
–number-int-cols，表内int列的数量
–number-char-cols，表内char列的数量

例如：
shell>mysqlslap –defaults-file=/u01/mysql1/mysql/my.cnf –concurrency=50,100 –iterations=1 –number-int-cols=4 –auto-generate-sql –auto-generate-sql-load-type=write –engine=myisam –number-of-queries=200 -S/tmp/mysql1.sock
Benchmark
Running for engine myisam
Average number of seconds to run all queries: 0.016 seconds
Minimum number of seconds to run all queries: 0.016 seconds
Maximum number of seconds to run all queries: 0.016 seconds
Number of clients running queries: 50
Average number of queries per client: 4

Benchmark
Running for engine myisam
Average number of seconds to run all queries: 0.265 seconds
Minimum number of seconds to run all queries: 0.265 seconds
Maximum number of seconds to run all queries: 0.265 seconds
Number of clients running queries: 100
Average number of queries per client: 2

指定数据库的测试：
–create-schema，指定数据库名称
–query，指定SQL语句，可以定位到某个包含SQL的文件

例如：
shell>mysqlslap –defaults-file=/u01/mysql1/mysql/my.cnf –concurrency=25,50 –iterations=1 –create-schema=test –query=/u01/test.sql -S/tmp/mysql1.sock
Benchmark
Average number of seconds to run all queries: 0.018 seconds
Minimum number of seconds to run all queries: 0.018 seconds
Maximum number of seconds to run all queries: 0.018 seconds
Number of clients running queries: 25
Average number of queries per client: 1

Benchmark
Average number of seconds to run all queries: 0.011 seconds
Minimum number of seconds to run all queries: 0.011 seconds
Maximum number of seconds to run all queries: 0.011 seconds
Number of clients running queries: 50
Average number of queries per client: 1

HID\{00001124-0000-1000-8000-00805f9b34fb}&VID_045E&PID_0701&Col02

上面的字符就是简报鲨鱼8000的设备ID

二、修改驱动

我安装的是IntelliPoint 6.3， 其他版本的驱动文件名称或路径可能不同。

C:\Program Files\Microsoft IntelliPoint\pnt32uw.inf

搜索

HID\{00001124-0000-1000-8000-00805f9b34fb}_VID&0002045e_PID&0701&Col02

改为

HID\{00001124-0000-1000-8000-00805f9b34fb}&VID_045E&PID_0701&Col02

一共有三处，修改之前注意备份.

三、更新驱动

一定要从列表或指定位置安装，不要自动搜索。

四、重新启动

EOF

TC4200 -> TC4400

价格 7.5K

第二步: 建立vsftp的本地帐户

第三步: 配置vsftp

第四步: 建立虚拟用户

这里需要注意ubuntu 7.10下需要用db3_load, 否则验证是会失败的.

第五步: 建立虚拟用户的目录,以及设置权限

第六步: 完成并测试

[EOF]

# wget http://nchc.dl.sourceforge.net/sourceforge/pptpclient/pptp-1.7.2.tar.gz

2. 编译

# make

3. 安装

# make install

4. 配置

# pptpsetup --create tunnelname --server xxx.xxx.xxx.xxx --username somebody --password sercet

5. 连接

# pppd call tunnelname

6. 断开

# killall pppd

注意事项：

在处理路由的时候采用client to lan方式，需要增加对方lan的路由或者目标网络的路由.

# route add -net 192.168.2.0 netmask 255.255.255.0 dev ppp0

ppp0是pptp连接的名字， 如果不确定 可以使用ifconfig命令查看

Dim linestr As String
Dim x As Integer
Dim y As Integer
Open App.Path & "\z.new.srt" For Append As #2
Open App.Path & "\z.srt" For Input As #1
    Do While Not EOF(1)
        Line Input #1, linestr           '   将数据读入变量。
        If InStr(linestr, "-->") > 0 Then
            Debug.Print linestr
            x = InStr(linestr, ",")
            Time1 = Mid(linestr, 1, x - 1)
            T1 = DateAdd("s", Val(Text1.Text), CDate(Time1))
            linestr = Replace(linestr, Time1, "0" & T1)
            x = InStr(linestr, "--> ")
            y = InStr(x, linestr, ",")
            Time1 = Mid(linestr, x + 4, y - x - 4)
            T1 = DateAdd("s", Val(Text1.Text), CDate(Time1))
            linestr = Replace(linestr, Time1, "0" & T1)
            Debug.Print linestr
            Debug.Print ""
        End If
        Print #2, linestr
        DoEvents
    Loop
Close #1
Close #2

下载编译版本

拓扑如下:

RouterOS 端设置:

policy

[admin@pencat] ip ipsec policy> pr
Flags: X - disabled, D - dynamic, I - invalid
0   src-address=192.168.2.0/24:any dst-address=192.168.1.0/24:any protocol=all
     action=encrypt level=require ipsec-protocols=esp tunnel=yes
     sa-src-address=1.1.1.1 sa-dst-address=2.2.2.2
     proposal=default manual-sa=none dont-fragment=clear

peer

[admin@pencat] ip ipsec peer> pr
Flags: X - disabled
0   address=2.2.2.2/32:500 secret="password"
     generate-policy=yes exchange-mode=main send-initial-contact=yes
     proposal-check=obey hash-algorithm=md5 enc-algorithm=aes-256
     dh-group=modp1536 lifetime=30m lifebytes=0

proposal

[admin@pencat] ip ipsec proposal> pr
Flags: X - disabled
0   name="default" auth-algorithms=sha1 enc-algorithms=3des lifetime=30m
     lifebytes=0 pfs-group=modp1536