博客园_房客的大杂烩

CentOS 安装配置 PPTP VPN 服务器

2012-02-01T05:45:00Z

VPN的英文全称是“Virtual Private Network”，翻译过来就是“虚拟专用网络”。顾名思义，虚拟专用网络我们可以把它理解成是虚拟出来的企业内部专线。它可以通过特殊的加密的通讯协议在连接在Internet上的位于不同地方的两个或多个企业内部网之间建立一条专有的通讯线路，就好比是架设了一条专线一样，但是它并不需要真正的去铺设光缆之类的物理线路。这就好比去电信局申请专线，但是不用给铺设线路的费用，也不用购买路由器等硬件设备。VPN技术原是路由器具有的重要技术之一，目前在交换机，防火墙设备或Windows等软件里也都支持VPN功能，一句话，VPN的核心就是在利用公共网络建立虚拟私有网。

　　虚拟专用网（VPN）被定义为通过一个公用网络（通常是因特网）建立一个临时的、安全的连接，是一条穿过混乱的公用网络的安全、稳定的隧道。虚拟专用网是对企业内部网的扩展。虚拟专用网可以帮助远程用户、公司分支机构、商业伙伴及供应商同公司的内部网建立可信的安全连接，并保证数据的安全传输。虚拟专用网可用于不断增长的移动用户的全球因特网接入，以实现安全连接；可用于实现企业网站之间安全通信的虚拟专用线路，用于经济有效地连接到商业伙伴和用户的安全外联网虚拟专用网。

　　PPTP 全称为 Point to Point Tunneling Protocol -- 点到点隧道协议，是VPN协议中的一种。

　　一、CentOS 下 PPTP VPN 服务器安装

　　1、安装相关软件
　　32位版：

yum install -y ppp iptables
wget http://poptop.sourceforge.net/yum/stable/packages/pptpd-1.3.4-2.rhel5.i386.rpm
rpm -ivh pptpd-1.3.4-2.rhel5.i386.rpm

　　64位版：

yum install -y ppp iptables
wget http://poptop.sourceforge.net/yum/stable/packages/pptpd-1.3.4-2.rhel5.x86_64.rpm
rpm -ivh pptpd-1.3.4-2.rhel5.x86_64.rpm

　　2、配置文件编写
　　①、配置文件/etc/ppp/options.pptpd

mv /etc/ppp/options.pptpd /etc/ppp/options.pptpd.bak
vi /etc/ppp/options.pptpd

　　输入以下内容：

name pptpd
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
require-mppe-128
proxyarp
lock
nobsdcomp
novj
novjccomp
nologfd
idle 2592000
ms-dns 8.8.8.8
ms-dns 8.8.4.4

　　②、配置文件/etc/ppp/chap-secrets

mv /etc/ppp/chap-secrets /etc/ppp/chap-secrets.bak
vi /etc/ppp/chap-secrets

　　输入以下内容

# Secrets for authentication using CHAP
# client server secret IP addresses
myusername pptpd mypassword *

　　注：这里的myusername和mypassword即为PPTP VPN的登录用户名和密码

　　③、配置文件/etc/pptpd.conf

mv /etc/pptpd.conf /etc/pptpd.conf.bak
vi /etc/pptpd.conf

　　输入以下内容：

option /etc/ppp/options.pptpd
logwtmp
localip 192.168.9.1
remoteip 192.168.9.11-30

　　注：为拨入VPN的用户动态分配192.168.9.11～192.168.9.30之间的IP

　　④、配置文件/etc/sysctl.conf

vi /etc/sysctl.conf

　　修改以下内容：

net.ipv4.ip_forward = 1

　　保存、退出后执行：

/sbin/sysctl -p

　　3、启动PPTP VPN 服务器端：

/sbin/service pptpd start

　　4、启动iptables：

/sbin/service iptables start
/sbin/iptables -t nat -A POSTROUTING -o eth0 -s 192.168.9.0/24 -j MASQUERADE

转自：http://blog.s135.com/pptp_vpn/

本文链接

Nginx + fastcgi 处理php

2012-01-07T16:31:00Z

location ~ .*\.(php|php5)?$
   {
     #fastcgi_pass unix:/tmp/php-cgi.sock;
     fastcgi_pass 127.0.0.1:9000;   /*fastcgi监听端口*/
     fastcgi_index index.php;
     include fcgi.conf;       /*fastcgi配置文件，修改为以下内容*/
   }

vim /usr/local/nginx/conf/fcgi.conf
fastcgi_param GATEWAY_INTERFACE CGI/1.1;
fastcgi_param SERVER_SOFTWARE nginx;

fastcgi_param QUERY_STRING       $query_string;
fastcgi_param REQUEST_METHOD     $request_method;
fastcgi_param CONTENT_TYPE       $content_type;
fastcgi_param CONTENT_LENGTH     $content_length;

fastcgi_param SCRIPT_FILENAME    $document_root$fastcgi_script_name;
fastcgi_param SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param REQUEST_URI        $request_uri;
fastcgi_param DOCUMENT_URI       $document_uri;
fastcgi_param DOCUMENT_ROOT      $document_root;
fastcgi_param SERVER_PROTOCOL    $server_protocol;

fastcgi_param REMOTE_ADDR        $remote_addr;
fastcgi_param REMOTE_PORT        $remote_port;
fastcgi_param SERVER_ADDR        $server_addr;
fastcgi_param SERVER_PORT        $server_port;
fastcgi_param SERVER_NAME        $server_name;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param REDIRECT_STATUS 200;

本文链接

编译安装php5.3.8(含php-fpm)

2012-01-07T13:54:00Z

#wget http://cn2.php.net/get/php-5.3.8.tar.gz/from/cn.php.net/mirror
#tar -zxvf php-5.3.8.tar.gz
#cd php-5.3.8
#./configure --prefix=/usr/local/php --enable-fpm --with-libevent-dir=/usr --with-mcrypt=/usr/local/libmcrypt --with-zlib --enable-mbstring --with-openssl --with-mysql --with-mysqli --with-mysql-sock --with-gd --with-jpeg-dir=/usr/lib --enable-gd-native-ttf --without-sqlite --enable-pdo --with-pdo-mysql --with-gettext --with-curl --with-pdo-mysql --enable-sockets --enable-bcmath --enable-xml --with-bz2 --with-gettext --with-snmp --enable-zip --with-snmp

我在64位centos上编译的时候报错：configure: error: mysql configure failed. Please check config.log

后来经过搜索得到以下解决方法：

找到/usr/lib64/libltdl.so.3.1.4，在该目录下执行以下命令：

　　ln -sv libltdl.so.3.1.4 libltdl.so

最终将出现如下内容,
+--------------------------------------------------------------------+
| License: |
| This software is subject to the PHP License, available in this |
| distribution in the file LICENSE. By continuing this installation |
| process, you are bound by the terms of this license agreement. |
| If you do not agree with the terms of this license, you must abort |
| the installation process at this point. |
+--------------------------------------------------------------------+
Thank you for using PHP.

安装
#make
#make install
移动php.ini
#cp /usr/local/php-5.3.8/php.ini-development /usr/local/php/lib/php.ini

关于php-fpm
php5.3.8默认包含php-fpm,

php-fpm的配置文件php-fpm.conf在/usr/local/php/etc <========当然要看你装php到了那里
php-fpm.conf的文件名这里为php-fpm.conf.default
#cp php-fpm.conf.default php-fpm.conf <========复制一份并重命名

php-fpm在/usr/local/php/sbin/下
#/usr/local/php/sbin/php-fpm ========启动php-fpm
启动错误解决:
ALERT: [pool www] pm.min_spare_servers(0) must be a positive value
编辑php-fpm.conf找到pm.min_spare_servers 去除;号,注意非注释内容pm.min_spare_servers
ALERT: [pool www] pm.max_spare_servers(0) must be a positive value
编辑php-fpm.conf找到pm.max_spare_servers 去除;号,同样非注释内容pm.max_spare_servers
WARNING: [pool www] pm.start_servers is not set. It's been set to 20.
编辑php-fpm.conf找到pm.start_servers 去除;号,同样非注释内容pm.start_servers
ERROR: bind() for address '127.0.0.1:9000' failed: Address already in use (98)
# netstat -ntlpps -ef|grep php查看进程,有N多进程
nobody 26152 26151 0 15:45 ? 00:00:00 php-fpm: pool www
nobody 26153 26151 0 15:45 ? 00:00:00 php-fpm: pool www
nobody 26154 26151 0 15:45 ? 00:00:00 php-fpm: pool www
nobody 26155 26151 0 15:45 ? 00:00:00 php-fpm: pool www
...........................
#killall php-fpm 结束所有php-fpm进程
再启动php-fpm
#/usr/local/php/sbin/php-fpm
成功

修改来源: http://www.linuxdiyf.com/viewarticle.php?id=217611

本文链接

CentOS 安装eaccelerator PHP加速

2011-12-21T03:49:00Z

1.编译eaccelerator

Warning: Unknown: open_basedir restriction in effect. File() is not within the allowed path(s): (.:/tmp/) in Unknown on line 0
Fatal error: Can’t load /XX/index.php, open_basedir restriction. in Unknown on line 0
出现了很多次这样的问题了，感觉都无从下手，总觉得与系统和php有关，今天又出现了，想来想去都觉得不奇怪，后面开始重新编译php， php的扩展都没编译，发现设置open_basedir的时候，却没有出错^^^ , 从这个信息觉得有些可以利用的，把自己方案所需的扩展都安装进去，重启apache的时候，却发现有出现这个错误，把php.ini中设置的扩展一个一个的关闭，开始排查，后面吧eaccelerator注释掉后，重启apache并没有出现错误，定位问题出现eaccelerator，在用google查了下，发现eaccelerator 0.9.6后的版本跟以前的有些改变，把open_basedir给限制了，这时我们要把限制去掉才行
下载eaccelerator 0.9.6后先不要安装，解包后找到eaccelerator.c这个文件，打开第1156行，这样的：
if (PG(open_basedir) && php_check_open_basedir(realname TSRMLS_CC)) {
修改成：
if (PG(open_basedir) && php_check_open_basedir(file_handle->filename TSRMLS_CC)) {
修改后在进行编译，就ok了

phpize
./configure
make

2.安装

make install
会将eaccelerator编译到目标路径

3.设置
拷贝eaccelerator.ini到 /etc/php.d/eaccelerator.ini

extension=”eaccelerator.so”
eaccelerator.shm_size=”16″
eaccelerator.cache_dir=”/tmp/eaccelerator”
eaccelerator.enable=”1″
eaccelerator.optimizer=”1″
eaccelerator.check_mtime=”1″
eaccelerator.debug=”0″
eaccelerator.filter=”"
eaccelerator.shm_max=”0″
eaccelerator.shm_ttl=”0″
eaccelerator.shm_prune_period=”0″
eaccelerator.shm_only=”0″
eaccelerator.compress=”1″
eaccelerator.compress_level=”9″

本文链接

设置全屏

2011-12-16T14:27:00Z

网上搜到的2种方法，分析一下：

1、在ContentView初始化之前，使用代码设置：

1 requestWindowFeature(Window.FEATURE_NO_TITLE); //设置没有标题栏，这个可以根据需要来设置
2 getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN, WindowManager.LayoutParams.FLAG_FULLSCREEN); //设置窗口全屏,没有系统通知栏

2、在配置文件中声明theme，告诉系统此Activity运行时使用的style

1 <activity android:name=".AndtestActivity"
2                   android:launchMode="singleInstance"
3                   android:theme="@android:style/Theme.NoTitleBar.Fullscreen"
4                   android:label="@string/app_name">
5             <intent-filter>
6                 <action android:name="android.intent.action.MAIN" />
7                 <category android:name="android.intent.category.LAUNCHER" />
8             </intent-filter>
9 </activity>

本文链接

Ubuntu下安装可视化SVN客户端Rabbitvcs

2011-10-24T01:59:00Z

如果你用过Windows下的tortoisesvn，肯定会感叹，同样是开源程序，为什么这些开源的东西不在开源的系统上先跑呢？不用着急，那边有个乌龟，这篇有只兔子，只是看了太多的龟兔赛跑的故事，不知到最后谁会赢。那就有你评判了，先安装再说吧！

下面是它的屏幕截图

由于这个目前还没有在安装中心里面，所以只能是手动安装。

你可以参考这里自己安装，也可以按照我的方法在Ubuntu下进行安装，因为里面没有中文。

下载压缩包，进入解压后的目录:
http://code.google.com/p/rabbitvcs/downloads/list

$sudo apt-get install python-nautilus python-configobj python-gtk2 python-glade2 python-svn python-dbus subversion meld
$sudo python setup.py install

确定你用的是什么文件系统，方法是随便打开一个文件夹，到帮助(Help)菜单里面找到关于(about)。这里我用的是Nautilus，所以到你解压的目录里面找到 clients/nautilus/RabbitVCS.py 。复制到/usr/lib/nautilus/extensions-2.0/python，重启你的电脑或者Java代码。
重启文件管理系统：

$nautilus -q
$pgrep -f service.py | xargs kill
$nohup nautilus > /dev/null &

好了现在一个文件夹里面试下右键，看有没似曾相识的菜单啊！！好好享受吧！

get from: http://www.linuxidc.com/Linux/2011-08/40156.htm

本文链接

Android中事件监听示例

2011-10-06T16:19:00Z

监视来电状态
AudioFocus是Android2.2以后才有的功能，对于比2.2低得版本，用的是另一种方法，就是监听电话的状态。最起码在电话打进来是能够暂停音乐的播放。
实现这一功能的第一步是在AndroidManifest.xml中声明用于接收PHONE_STATE通知的receiver
<receiver android:name=".PhoneStateReceiver">
    <intent-filter>
        <action android:name="android.intent.action.PHONE_STATE"/>
    </intent-filter>
</receiver>
第二步是定义一个对应的PhoneStateReceiver，代码如下
package LyricPlayer.xwg;

import android.content.BroadcastReceiver;
import android.content.Context;
import android.content.Intent;
import android.telephony.TelephonyManager;

public class PhoneStateReceiver extends BroadcastReceiver {
    @Override
    public void onReceive(Context context, Intent intent) {
        //if android.os.Build.VERSION.SDK_INT >= 8 we use audio focus.
        if (android.os.Build.VERSION.SDK_INT < 8){
            TelephonyManager tm = (TelephonyManager)context.getSystemService(Context.TELEPHONY_SERVICE);
            if(tm.getCallState() != TelephonyManager.CALL_STATE_IDLE){
                context.startService(new Intent(MediaPlayerService.ACTION_PAUSE));
            }
        }
    }
}
这就够了。
监视耳机插头拔出
如果在音乐播放过程中拔出耳机，音乐就会通过扬声器播放出来。为了避免这种尴尬局面，我们会监视耳机拔出状态，并在耳机拔出时暂停播放。
首先是在AndroidManifest.xml中声明用于接收AUDIO_BECOMING_NOISY通知的receiver
<receiver android:name=".MusicIntentReceiver">
    <intent-filter>
        <action android:name="android.media.AUDIO_BECOMING_NOISY" />
    </intent-filter>
</receiver>
然后就是定义用于处理通知的receiver，类名要和AndroidManifest.xml中声明的一样。
package LyricPlayer.xwg;

import android.content.BroadcastReceiver;
import android.content.Context;
import android.content.Intent;

public class MusicIntentReceiver extends BroadcastReceiver {
    @Override
    public void onReceive(Context ctx, Intent intent) {
        if (intent.getAction().equals(android.media.AudioManager.ACTION_AUDIO_BECOMING_NOISY)) {
            ctx.startService(new Intent(LyricPlayerService.ACTION_PAUSE));
        }
    }
}
MEDIA_BUTTON处理
在讨论处理方法之前，必须先明确：那些键属于MEDIA_BUTTON？根据我的试验，MEDIA_BUTTON好像就是线控上面的上个按钮。网上也有用同样的方法取得音量键动作的内容，但是我没有试出来。
继续我们的话题，为了检测MEDIA_BUTTON需要一些准备工作。
首先是在AndroidManifest.xml中声明用于接收MEDIA_BUTTON通知的receiver
<receiver android:name="MediaButtonReceiver">
    <intent-filter>
        <action android:name="android.intent.action.MEDIA_BUTTON" />
    </intent-filter>
</receiver>
当然需要定义真正的receiver，名字要和AndroidManifest.xml中的一样。
package LyricPlayer.xwg;

import android.content.BroadcastReceiver;
import android.content.Context;
import android.content.Intent;
import android.util.Log;
import android.view.KeyEvent;

public class MediaButtonReceiver extends BroadcastReceiver {
    private static final String TAG = new String("LyricVolumeKeyReceiver");
    @Override
    public void onReceive(Context context, Intent intent) {
        //MusicPlaybackService service = (MusicPlaybackService)context;
         if (Intent.ACTION_MEDIA_BUTTON.equals(intent.getAction())) {
             KeyEvent key = (KeyEvent)intent.getParcelableExtra(Intent.EXTRA_KEY_EVENT);
             if(key.getAction() == KeyEvent.ACTION_DOWN){
                 Log.i(TAG, "OnReceive, getKeyCode = " + key.getKeyCode());
                 switch(key.getKeyCode()){
                 case KeyEvent.KEYCODE_HEADSETHOOK :
                     context.startService(new Intent(MediaPlayerService.ACTION_PLAY_PAUSE));
                     break;
                 case KeyEvent.KEYCODE_MEDIA_PREVIOUS:
                     context.startService(new Intent(MediaPlayerService.ACTION_PREVIOUS));
                     break;
                 case KeyEvent.KEYCODE_MEDIA_NEXT:
                     context.startService(new Intent(MediaPlayerService.ACTION_NEXT));
                     break;
                 }
             }
        }
    }
}
比较特别的是中间的键的键值不是KEYCODE_PLAY_PAUSE而是KEYCODE_HEADSETHOOK。想想也是，接电话也用这个键。
准备工作的最后一步就是要把通过MediaButtonReceiver来接受MEDIA_BUTTON这件事报告给AudioMenager，由于这也是Android2.2及以后版本才有的功能，也需要做版本判断。
if (android.os.Build.VERSION.SDK_INT >= 8){
            mReceiverName = new ComponentName(getPackageName(),MediaButtonReceiver.class.getName());
            mAudioManager = (AudioManager)getSystemService(Context.AUDIO_SERVICE);
            mAudioManager.registerMediaButtonEventReceiver(mReceiverName);
        }
当然在结束的时候我们也会保持取消登录的良好习惯。
if(mAudioManager != null && mReceiverName != null){
            mAudioManager.unregisterMediaButtonEventReceiver(mReceiverName);
        }
Notification表示
Notification表示首先取得NotificationManager
mNotificationManager = (NotificationManager)getSystemService(NOTIFICATION_SERVICE);
在需要表示的时候调用showNotification()方法。和showNotification()方法有关的代码：
public interface NotificationProvider{
        public Notification createNotification(Context context);
    }

    NotificationProvider mNotificationProvider = null;

    public void setNotificationProvider(NotificationProvider provider){
        mNotificationProvider = provider;
    }

    /** * Show a notification while this service is running.     */
    private void showNotification() {
        if(mNotificationProvider != null){
        // Send the notification.
            mNotificationManager.notify(NOTIFICATION, mNotificationProvider.createNotification(this));
        }
    }
已经用了N次的办法了。不用再解释了吧。当然，看看实现侧的做法还有必要的。
mProxy.setNotificationProvider(new MediaPlayerService.NotificationProvider(){
            @Override
            public Notification createNotification(Context context) {
                Notification notification = new Notification(R.drawable.button_blue_play, mProxy.getTitle(), System.currentTimeMillis());
                // The PendingIntent to launch our activity if the user selects this notification
                PendingIntent contentIntent = PendingIntent.getActivity(context, 0, new Intent(context, LyricMain.class), 0);
                // Set the info for the views that show in the notification panel.
                notification.setLatestEventInfo(context, getText(R.string.media_player_label), mProxy.getTitle(), contentIntent);
                return notification;
            }
        });

全文摘抄自：http://www.2cto.com/kf/201109/103784.html

本文链接

mysql replication 基本原理,mysql主从配置原理

2011-09-26T10:17:00Z

1、复制进程
Mysql的复制（Replication）是一个异步的复制，从一个Mysql instace（称之为Master）复制到另一个Mysql instance（称之Slave）。实现整个复制操作主要由三个进程完成的，其中两个进程在Slave（Sql进程和IO进程），另外一个进程在 Master（IO进程）上。
要实施复制，首先必须打开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两端，保证不会交叉写入，才能够避免上面的问题。

from:http://apps.hi.baidu.com/share/detail/31069143

本文链接

修复upstream sent too big header while reading response header from upstream

2011-09-15T16:14:00Z

在nginx的http节点下增加：

proxy_buffer_size 64k;

proxy_buffers 32 32k;

proxy_busy_buffers_size 128k;

即可解决。网上大多数说的增加：

client_header_buffer_size 64k;

large_client_header_buffers 4 64k;

其实是解决不了的。

本文链接

nginx优化突破十万并发

2011-09-15T15:44:00Z

一、一般来说nginx 配置文件中对优化比较有作用的为以下几项：

1. worker_processes 8;

nginx 进程数，建议按照cpu 数目来指定，一般为它的倍数 (如,2个四核的cpu计为8)。

2. worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;

为每个进程分配cpu，上例中将8 个进程分配到8 个cpu，当然可以写多个，或者将一
个进程分配到多个cpu。

3. worker_rlimit_nofile 65535;

这个指令是指当一个nginx 进程打开的最多文件描述符数目，理论值应该是最多打开文
件数（ulimit -n）与nginx 进程数相除，但是nginx 分配请求并不是那么均匀，所以最好与ulimit -n 的值保持一致。

现在在linux 2.6内核下开启文件打开数为65535，worker_rlimit_nofile就相应应该填写65535。

这是因为nginx调度时分配请求到进程并不是那么的均衡，所以假如填写10240，总并发量达到3-4万时就有进程可能超过10240了，这时会返回502错误。

查看linux系统文件描述符的方法：

[root@web001 ~]# sysctl -a | grep fs.file

fs.file-max = 789972

fs.file-nr = 510 0 789972

4. use epoll;

使用epoll 的I/O 模型

(

补充说明:

与apache相类，nginx针对不同的操作系统，有不同的事件模型

      A）标准事件模型
       Select、poll属于标准事件模型，如果当前系统不存在更有效的方法，nginx会选择select或poll
      B）高效事件模型
Kqueue：使用于 FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 和 MacOS X. 使用双处理器的MacOS X系统使用kqueue可能会造成内核崩溃。
Epoll: 使用于Linux内核2.6版本及以后的系统。

/dev/poll：使用于 Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ 和 Tru64 UNIX 5.1A+。

Eventport：使用于 Solaris 10. 为了防止出现内核崩溃的问题，有必要安装安全补丁。

)

5. worker_connections 65535;

每个进程允许的最多连接数，理论上每台nginx 服务器的最大连接数为worker_processes*worker_connections。

6. keepalive_timeout 60;

keepalive 超时时间。

7. client_header_buffer_size 4k;

客户端请求头部的缓冲区大小，这个可以根据你的系统分页大小来设置，一般一个请求头的大小不会超过1k，不过由于一般系统分页都要大于1k，所以这里设置为分页大小。

分页大小可以用命令getconf PAGESIZE 取得。

[root@web001 ~]# getconf PAGESIZE

4096

但也有client_header_buffer_size超过4k的情况，但是client_header_buffer_size该值必须设置为“系统分页大小”的整倍数。

8. open_file_cache max=65535 inactive=60s;

这个将为打开文件指定缓存，默认是没有启用的，max 指定缓存数量，建议和打开文件数一致，inactive 是指经过多长时间文件没被请求后删除缓存。

9. open_file_cache_valid 80s;

这个是指多长时间检查一次缓存的有效信息。

10. open_file_cache_min_uses 1;

open_file_cache 指令中的inactive 参数时间内文件的最少使用次数，如果超过这个数字，文件描述符一直是在缓存中打开的，如上例，如果有一个文件在inactive 时间内一次没被使用，它将被移除。

二、关于内核参数的优化：

net.ipv4.tcp_max_tw_buckets = 6000

timewait 的数量，默认是180000。

net.ipv4.ip_local_port_range = 1024 65000

允许系统打开的端口范围。

net.ipv4.tcp_tw_recycle = 1

启用timewait 快速回收。

net.ipv4.tcp_tw_reuse = 1

开启重用。允许将TIME-WAIT sockets 重新用于新的TCP 连接。

net.ipv4.tcp_syncookies = 1

开启SYN Cookies，当出现SYN 等待队列溢出时，启用cookies 来处理。

net.core.somaxconn = 262144

web 应用中listen 函数的backlog 默认会给我们内核参数的net.core.somaxconn 限制到128，而nginx 定义的NGX_LISTEN_BACKLOG 默认为511，所以有必要调整这个值。

net.core.netdev_max_backlog = 262144

每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。

net.ipv4.tcp_max_orphans = 262144

系统中最多有多少个TCP 套接字不被关联到任何一个用户文件句柄上。如果超过这个数字，孤儿连接将即刻被复位并打印出警告信息。这个限制仅仅是为了防止简单的DoS 攻击，不能过分依靠它或者人为地减小这个值，更应该增加这个值(如果增加了内存之后)。

net.ipv4.tcp_max_syn_backlog = 262144

记录的那些尚未收到客户端确认信息的连接请求的最大值。对于有128M 内存的系统而言，缺省值是1024，小内存的系统则是128。

net.ipv4.tcp_timestamps = 0

时间戳可以避免序列号的卷绕。一个1Gbps 的链路肯定会遇到以前用过的序列号。时间戳能够让内核接受这种“异常”的数据包。这里需要将其关掉。

net.ipv4.tcp_synack_retries = 1

为了打开对端的连接，内核需要发送一个SYN 并附带一个回应前面一个SYN 的ACK。也就是所谓三次握手中的第二次握手。这个设置决定了内核放弃连接之前发送SYN+ACK 包的数量。

net.ipv4.tcp_syn_retries = 1

在内核放弃建立连接之前发送SYN 包的数量。

net.ipv4.tcp_fin_timeout = 1

如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2 状态的时间。对端可以出错并永远不关闭连接，甚至意外当机。缺省值是60 秒。2.2 内核的通常值是180 秒，3你可以按这个设置，但要记住的是，即使你的机器是一个轻载的WEB 服务器，也有因为大量的死套接字而内存溢出的风险，FIN- WAIT-2 的危险性比FIN-WAIT-1 要小，因为它最多只能吃掉1.5K 内存，但是它们的生存期长些。

net.ipv4.tcp_keepalive_time = 30

当keepalive 起用的时候，TCP 发送keepalive 消息的频度。缺省是2 小时。

三、下面贴一个完整的内核优化设置:

vi /etc/sysctl.conf CentOS5.5中可以将所有内容清空直接替换为如下内容:

net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
net.ipv4.tcp_max_tw_buckets = 6000
net.ipv4.tcp_sack = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_rmem = 4096 87380 4194304
net.ipv4.tcp_wmem = 4096 16384 4194304
net.core.wmem_default = 8388608
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.netdev_max_backlog = 262144
net.core.somaxconn = 262144
net.ipv4.tcp_max_orphans = 3276800
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_mem = 94500000 915000000 927000000
net.ipv4.tcp_fin_timeout = 1
net.ipv4.tcp_keepalive_time = 30
net.ipv4.ip_local_port_range = 1024 65000

使配置立即生效可使用如下命令：
/sbin/sysctl -p

四、下面是关于系统连接数的优化

linux 默认值 open files 和 max user processes 为 1024

#ulimit -n

1024

#ulimit –u

1024

问题描述： 说明 server 只允许同时打开 1024 个文件，处理 1024 个用户进程

使用ulimit -a 可以查看当前系统的所有限制值，使用ulimit -n 可以查看当前的最大打开文件数。

新装的linux 默认只有1024 ，当作负载较大的服务器时，很容易遇到error: too many open files 。因此，需要将其改大。

解决方法：

使用 ulimit –n 65535 可即时修改，但重启后就无效了。（注ulimit -SHn 65535 等效 ulimit -n 65535 ，-S 指soft ，-H 指hard)

有如下三种修改方式：

1. 在/etc/rc.local 中增加一行 ulimit -SHn 65535
2. 在/etc/profile 中增加一行 ulimit -SHn 65535
3. 在/etc/security/limits.conf 最后增加：

* soft nofile 65535
* hard nofile 65535
* soft nproc 65535
* hard nproc 65535

具体使用哪种，在 CentOS 中使用第1 种方式无效果，使用第3 种方式有效果，而在Debian 中使用第2 种有效果

# ulimit -n

65535

# ulimit -u

65535

备注：ulimit 命令本身就有分软硬设置，加-H 就是硬，加-S 就是软默认显示的是软限制

soft 限制指的是当前系统生效的设置值。 hard 限制值可以被普通用户降低。但是不能增加。 soft 限制不能设置的比 hard 限制更高。只有 root 用户才能够增加 hard 限制值。

五、下面是一个简单的nginx 配置文件：

user www www;
worker_processes 8;
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000
01000000;
error_log /www/log/nginx_error.log crit;
pid /usr/local/nginx/nginx.pid;
worker_rlimit_nofile 204800;
events
{
use epoll;
worker_connections 204800;
}
http
{
include mime.types;
default_type application/octet-stream;
charset utf-8;
server_names_hash_bucket_size 128;
client_header_buffer_size 2k;
large_client_header_buffers 4 4k;
client_max_body_size 8m;
sendfile on;
tcp_nopush on;
keepalive_timeout 60;
fastcgi_cache_path /usr/local/nginx/fastcgi_cache levels=1:2
keys_zone=TEST:10m
inactive=5m;
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 4k;
fastcgi_buffers 8 4k;
fastcgi_busy_buffers_size 8k;
fastcgi_temp_file_write_size 8k;
fastcgi_cache TEST;
fastcgi_cache_valid 200 302 1h;
fastcgi_cache_valid 301 1d;
fastcgi_cache_valid any 1m;
fastcgi_cache_min_uses 1;
fastcgi_cache_use_stale error timeout invalid_header http_500;
open_file_cache max=204800 inactive=20s;
open_file_cache_min_uses 1;
open_file_cache_valid 30s;
tcp_nodelay on;
gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1.0;
gzip_comp_level 2;
gzip_types text/plain application/x-javascript text/css application/xml;
gzip_vary on;
server
{
listen 8080;
server_name backup.aiju.com;
index index.php index.htm;
root /www/html/;
location /status
{
stub_status on;
}
location ~ .*\.(php|php5)?$
{
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fcgi.conf;
}
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf|js|css)$
{
expires 30d;
}
log_format access '$remote_addr -- $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" $http_x_forwarded_for';
access_log /www/log/access.log access;
}
}

六、关于FastCGI 的几个指令：

fastcgi_cache_path /usr/local/nginx/fastcgi_cache levels=1:2 keys_zone=TEST:10minactive=5m;

这个指令为FastCGI 缓存指定一个路径，目录结构等级，关键字区域存储时间和非活动删除时间。

fastcgi_connect_timeout 300;

指定连接到后端FastCGI 的超时时间。

fastcgi_send_timeout 300;

向FastCGI 传送请求的超时时间，这个值是指已经完成两次握手后向FastCGI 传送请求的超时时间。

fastcgi_read_timeout 300;

接收FastCGI 应答的超时时间，这个值是指已经完成两次握手后接收FastCGI 应答的超时时间。

fastcgi_buffer_size 4k;

指定读取FastCGI 应答第一部分需要用多大的缓冲区，一般第一部分应答不会超过1k，由于页面大小为4k，所以这里设置为4k。

fastcgi_buffers 8 4k;

指定本地需要用多少和多大的缓冲区来缓冲FastCGI 的应答。

fastcgi_busy_buffers_size 8k;

这个指令我也不知道是做什么用，只知道默认值是fastcgi_buffers 的两倍。

fastcgi_temp_file_write_size 8k;

在写入fastcgi_temp_path 时将用多大的数据块，默认值是fastcgi_buffers 的两倍。

fastcgi_cache TEST

开启FastCGI 缓存并且为其制定一个名称。个人感觉开启缓存非常有用，可以有效降低CPU 负载，并且防止502 错误。

fastcgi_cache_valid 200 302 1h;
fastcgi_cache_valid 301 1d;
fastcgi_cache_valid any 1m;

为指定的应答代码指定缓存时间，如上例中将200，302 应答缓存一小时，301 应答缓存1 天，其他为1 分钟。

fastcgi_cache_min_uses 1;

缓存在fastcgi_cache_path 指令inactive 参数值时间内的最少使用次数，如上例，如果在5 分钟内某文件1 次也没有被使用，那么这个文件将被移除。

fastcgi_cache_use_stale error timeout invalid_header http_500;

不知道这个参数的作用，猜想应该是让nginx 知道哪些类型的缓存是没用的。以上为nginx 中FastCGI 相关参数，另外，FastCGI 自身也有一些配置需要进行优化，如果你使用php-fpm 来管理FastCGI，可以修改配置文件中的以下值：

<value name="max_children">60</value>

同时处理的并发请求数，即它将开启最多60 个子线程来处理并发连接。

<value name="rlimit_files">102400</value>

最多打开文件数。

<value name="max_requests">204800</value>

每个进程在重置之前能够执行的最多请求数。

转自：http://blog.sina.com.cn/s/blog_7429b9c80100s1xz.html

本文链接

博客园_房客 的大杂烩

CentOS 安装配置 PPTP VPN 服务器

Nginx + fastcgi 处理php

编译安装php5.3.8(含php-fpm)

CentOS 安装eaccelerator PHP加速

设置全屏

Ubuntu下安装可视化SVN客户端Rabbitvcs

Android中事件监听示例

mysql replication 基本原理,mysql主从配置原理

修复upstream sent too big header while reading response header from upstream

nginx优化 突破十万并发

博客园_房客的大杂烩

nginx优化突破十万并发