高性能Mysql主从架构的复制原理及配置详解

 

1 复制概述

Mysql内建的复制功能是构建大型,高性能应用程序的基础。将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台主机的数据复制到其它主机(slaves)上,并重新执行一遍来实现的。复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新,然后封锁并等待主服务器通知新的更新。

请注意当你进行复制时,所有对复制中的表的更新必须在主服务器上进行。否则,你必须要小心,以避免用户对主服务器上的表进行的更新与对从服务器上的表所进行的更新之间的冲突。

1.1 mysql支持的复制类型:

(1):基于语句的复制:  在主服务器上执行的SQL语句,在从服务器上执行同样的语句。MySQL默认采用基于语句的复制,效率比较高。
一旦发现没法精确复制时,   会自动选着基于行的复制。
(2):基于行的复制:把改变的内容复制过去,而不是把命令在从服务器上执行一遍. 从mysql5.0开始支持
(3):混合类型的复制: 默认采用基于语句的复制,一旦发现基于语句的无法精确的复制时,就会采用基于行的复制。

 1.2 . 复制解决的问题

         MySQL复制技术有以下一些特点:
(1)    数据分布 (Data distribution )
(2)    负载平衡(load balancing)
(3)    备份(Backups)
(4)    高可用性和容错行 High availability and failover

  1.3 复制如何工作

        整体上来说,复制有3个步骤:

(1)    master将改变记录到二进制日志(binary log)中(这些记录叫做二进制日志事件,binary log events);
(2)    slave将master的binary log events拷贝到它的中继日志(relay log);
(3)    slave重做中继日志中的事件,将改变反映它自己的数据。

下图描述了复制的过程:

                                  

          该过程的第一部分就是master记录二进制日志。在每个事务更新数据完成之前,master在二日志记录这些改变。MySQL将事务串行的写入二进制日志,即使事务中的语句都是交叉执行的。在事件写入二进制日志完成后,master通知存储引擎提交事务。
下一步就是slave将master的binary log拷贝到它自己的中继日志。首先,slave开始一个工作线程——I/O线程。I/O线程在master上打开一个普通的连接,然后开始binlog dump process。Binlog dump process从master的二进制日志中读取事件,如果已经跟上master,它会睡眠并等待master产生新的事件。I/O线程将这些事件写入中继日志。
SQL slave thread(SQL从线程)处理该过程的最后一步。SQL线程从中继日志读取事件,并重放其中的事件而更新slave的数据,使其与master中的数据一致。只要该线程与I/O线程保持一致,中继日志通常会位于OS的缓存中,所以中继日志的开销很小。
此外,在master中也有一个工作线程:和其它MySQL的连接一样,slave在master中打开一个连接也会使得master开始一个线程。复制过程有一个很重要的限制——复制在slave上是串行化的,也就是说master上的并行更新操作不能在slave上并行操作。

 2 .复制配置

有两台MySQL数据库服务器Master和slave,Master为主服务器,slave为从服务器,初始状态时,Master和slave中的数据信息相同,当Master中的数据发生变化时,slave也跟着发生相应的变化,使得master和slave的数据信息同步,达到备份的目的。

要点:
负责在主、从服务器传输各种修改动作的媒介是主服务器的二进制变更日志,这个日志记载着需要传输给从服务器的各种修改动作。因此,主服务器必须激活二进制日志功能。从服务器必须具备足以让它连接主服务器并请求主服务器把二进制变更日志传输给它的权限。

环境:
Master和slave的MySQL数据库版本同为5.0.18
操作系统:unbuntu 11.10
IP地址:10.100.0.100

2.1、创建复制帐号

1、在Master的数据库中建立一个备份帐户:每个slave使用标准的MySQL用户名和密码连接master。进行复制操作的用户会授予REPLICATION SLAVE权限。用户名的密码都会存储在文本文件master.info中

命令如下:
mysql > GRANT REPLICATION SLAVE,RELOAD,SUPER ON *.*
TO backup@’10.100.0.200’
IDENTIFIED BY ‘1234’;

建立一个帐户backup,并且只能允许从10.100.0.200这个地址上来登陆,密码是1234。

(如果因为mysql版本新旧密码算法不同,可以设置:set password for ‘backup’@’10.100.0.200’=old_password(‘1234’))

2.2、拷贝数据

(假如是你完全新安装mysql主从服务器,这个一步就不需要。因为新安装的master和slave有相同的数据)

关停Master服务器,将Master中的数据拷贝到B服务器中,使得Master和slave中的数据同步,并且确保在全部设置操作结束前,禁止在Master和slave服务器中进行写操作,使得两数据库中的数据一定要相同!

2.3、配置master

 

接下来对master进行配置,包括打开二进制日志,指定唯一的servr ID。例如,在配置文件加入如下值:

server-id=1
log-bin=mysql-bin

server-id:为主服务器A的ID值
log-bin:二进制变更日值

重启master,运行SHOW MASTER STATUS,输出如下:

 

2.4、配置slave

Slave的配置与master类似,你同样需要重启slave的MySQL。如下:
log_bin           = mysql-bin
server_id         = 2
relay_log         = mysql-relay-bin
log_slave_updates = 1
read_only         = 1
server_id是必须的,而且唯一。slave没有必要开启二进制日志,但是在一些情况下,必须设置,例如,如果slave为其它slave的master,必须设置bin_log。在这里,我们开启了二进制日志,而且显示的命名(默认名称为hostname,但是,如果hostname改变则会出现问题)。
relay_log配置中继日志,log_slave_updates表示slave将复制事件写进自己的二进制日志(后面会看到它的用处)。
有些人开启了slave的二进制日志,却没有设置log_slave_updates,然后查看slave的数据是否改变,这是一种错误的配置。所以,尽量使用read_only,它防止改变数据(除了特殊的线程)。但是,read_only并是很实用,特别是那些需要在slave上创建表的应用。

 

 

2.5、启动slave

接下来就是让slave连接master,并开始重做master二进制日志中的事件。你不应该用配置文件进行该操作,而应该使用CHANGE MASTER TO语句,该语句可以完全取代对配置文件的修改,而且它可以为slave指定不同的master,而不需要停止服务器。如下:

mysql> CHANGE MASTER TO MASTER_HOST=’server1′,

    -> MASTER_USER=’repl’,

    -> MASTER_PASSWORD=’p4ssword’,

    -> MASTER_LOG_FILE=’mysql-bin.000001′,

    -> MASTER_LOG_POS=0;

MASTER_LOG_POS的值为0,因为它是日志的开始位置。

你可以用SHOW SLAVE STATUS语句查看slave的设置是否正确:

mysql> SHOW SLAVE STATUS\G

 

*************************** 1. row ***************************

Slave_IO_State:

Master_Host: server1

Master_User: repl

Master_Port: 3306

Connect_Retry: 60

Master_Log_File: mysql-bin.000001

Read_Master_Log_Pos: 4

Relay_Log_File: mysql-relay-bin.000001

Relay_Log_Pos: 4

Relay_Master_Log_File: mysql-bin.000001

Slave_IO_Running: No

Slave_SQL_Running: No

…omitted…

Seconds_Behind_Master: NULL

 

Slave_IO_State, Slave_IO_Running, 和Slave_SQL_Running是No

表明slave还没有开始复制过程。日志的位置为4而不是0,这是因为0只是日志文件的开始位置,并不是日志位置。实际上,MySQL知道的第一个事件的位置是4。

为了开始复制,你可以运行:

mysql> START SLAVE;

运行SHOW SLAVE STATUS查看输出结果:

mysql> SHOW SLAVE STATUS\G

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Master_Host: server1

Master_User: repl

Master_Port: 3306

Connect_Retry: 60

Master_Log_File: mysql-bin.000001

Read_Master_Log_Pos: 164

Relay_Log_File: mysql-relay-bin.000001

Relay_Log_Pos: 164

Relay_Master_Log_File: mysql-bin.000001

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

…omitted…

Seconds_Behind_Master: 0

在这里主要是看:
                   Slave_IO_Running=Yes
Slave_SQL_Running=Yes

slave的I/O和SQL线程都已经开始运行,而且Seconds_Behind_Master不再是NULL。日志的位置增加了,意味着一些事件被获取并执行了。如果你在master上进行修改,你可以在slave上看到各种日志文件的位置的变化,同样,你也可以看到数据库中数据的变化。

你可查看master和slave上线程的状态。在master上,你可以看到slave的I/O线程创建的连接:

在master上输入show processlist\G;
mysql> show processlist \G
*************************** 1. row ***************************
     Id: 1
   User: root
   Host: localhost:2096
     db: test
Command: Query
   Time: 0
 State: NULL
   Info: show processlist
*************************** 2. row ***************************
     Id: 2
   User: repl
   Host: localhost:2144
     db: NULL
Command: Binlog Dump
   Time: 1838
 State: Has sent all binlog to slave; waiting for binlog to be updated
   Info: NULL
2 rows in set (0.00 sec)

行2为处理slave的I/O线程的连接。

在slave服务器上运行该语句:

mysql> show processlist \G
*************************** 1. row ***************************
     Id: 1
   User: system user
   Host:
     db: NULL
Command: Connect
   Time: 2291
 State: Waiting for master to send event
   Info: NULL
*************************** 2. row ***************************
     Id: 2
   User: system user
   Host:
     db: NULL
Command: Connect
   Time: 1852
 State: Has read all relay log; waiting for the slave I/O thread to update it
   Info: NULL
*************************** 3. row ***************************
     Id: 5
   User: root
   Host: localhost:2152
     db: test
Command: Query
   Time: 0
 State: NULL
   Info: show processlist
3 rows in set (0.00 sec)

行1为I/O线程状态,行2为SQL线程状态。

2.5、添加新slave服务器

假如master已经运行很久了,想对新安装的slave进行数据同步,甚至它没有master的数据。
此时,有几种方法可以使slave从另一个服务开始,例如,从master拷贝数据,从另一个slave克隆,从最近的备份开始一个slave。Slave与master同步时,需要三样东西:
(1)master的某个时刻的数据快照;
(2)master当前的日志文件、以及生成快照时的字节偏移。这两个值可以叫做日志文件坐标(log file coordinate),因为它们确定了一个二进制日志的位置,你可以用SHOW MASTER STATUS命令找到日志文件的坐标;
(3)master的二进制日志文件。

可以通过以下几中方法来克隆一个slave:
(1)    冷拷贝(cold copy)
停止master,将master的文件拷贝到slave;然后重启master。缺点很明显。
(2)    热拷贝(warm copy)
如果你仅使用MyISAM表,你可以使用mysqlhotcopy拷贝,即使服务器正在运行。
(3)    使用mysqldump
使用mysqldump来得到一个数据快照可分为以下几步:
<1>锁表:如果你还没有锁表,你应该对表加锁,防止其它连接修改数据库,否则,你得到的数据可以是不一致的。如下:
mysql> FLUSH TABLES WITH READ LOCK;
<2>在另一个连接用mysqldump创建一个你想进行复制的数据库的转储:
shell> mysqldump –all-databases –lock-all-tables >dbdump.db
<3>对表释放锁。
mysql> UNLOCK TABLES;

 

3、深入了解复制

已经讨论了关于复制的一些基本东西,下面深入讨论一下复制。

3.1、基于语句的复制(Statement-Based Replication)

     MySQL 5.0及之前的版本仅支持基于语句的复制(也叫做逻辑复制,logical replication),这在数据库并不常见。master记录下改变数据的查询,然后,slave从中继日志中读取事件,并执行它,这些SQL语句与master执行的语句一样。
这种方式的优点就是实现简单。此外,基于语句的复制的二进制日志可以很好的进行压缩,而且日志的数据量也较小,占用带宽少——例如,一个更新GB的数据的查询仅需要几十个字节的二进制日志。而mysqlbinlog对于基于语句的日志处理十分方便。但是,基于语句的复制并不是像它看起来那么简单,因为一些查询语句依赖于master的特定条件,例如,master与slave可能有不同的时间。所以,MySQL的二进制日志的格式不仅仅是查询语句,还包括一些元数据信息,例如,当前的时间戳。即使如此,还是有一些语句,比如,CURRENT USER函数,不能正确的进行复制。此外,存储过程和触发器也是一个问题。
另外一个问题就是基于语句的复制必须是串行化的。这要求大量特殊的代码,配置,例如InnoDB的next-key锁等。并不是所有的存储引擎都支持基于语句的复制。

3.2、基于记录的复制(Row-Based Replication)

      MySQL增加基于记录的复制,在二进制日志中记录下实际数据的改变,这与其它一些DBMS的实现方式类似。这种方式有优点,也有缺点。优点就是可以对任何语句都能正确工作,一些语句的效率更高。主要的缺点就是二进制日志可能会很大,而且不直观,所以,你不能使用mysqlbinlog来查看二进制日志。
对于一些语句,基于记录的复制能够更有效的工作,如:
mysql> INSERT INTO summary_table(col1, col2, sum_col3)
-> SELECT col1, col2, sum(col3)
-> FROM enormous_table
-> GROUP BY col1, col2;
假设,只有三种唯一的col1和col2的组合,但是,该查询会扫描原表的许多行,却仅返回三条记录。此时,基于记录的复制效率更高。
另一方面,下面的语句,基于语句的复制更有效:
mysql> UPDATE enormous_table SET col1 = 0;
此时使用基于记录的复制代价会非常高。由于两种方式不能对所有情况都能很好的处理,所以,MySQL 5.1支持在基于语句的复制和基于记录的复制之前动态交换。你可以通过设置session变量binlog_format来进行控制。

3.3、复制相关的文件

除了二进制日志和中继日志文件外,还有其它一些与复制相关的文件。如下:

(1)mysql-bin.index

服务器一旦开启二进制日志,会产生一个与二日志文件同名,但是以.index结尾的文件。它用于跟踪磁盘上存在哪些二进制日志文件。MySQL用它来定位二进制日志文件。它的内容如下(我的机器上):

 (2)mysql-relay-bin.index

该文件的功能与mysql-bin.index类似,但是它是针对中继日志,而不是二进制日志。内容如下:
.\mysql-02-relay-bin.000017
.\mysql-02-relay-bin.000018

(3)master.info

保存master的相关信息。不要删除它,否则,slave重启后不能连接master。内容如下(我的机器上):

I/O线程更新master.info文件,内容如下(我的机器上):

.\mysql-02-relay-bin.000019
254
mysql-01-bin.000010
286
0
52813

 (4)relay-log.info

包含slave中当前二进制日志和中继日志的信息。

 

 

 

3.4、发送复制事件到其它slave

当设置log_slave_updates时,你可以让slave扮演其它slave的master。此时,slave把SQL线程执行的事件写进行自己的二进制日志(binary log),然后,它的slave可以获取这些事件并执行它。如下:

 

 

 

3.5、复制过滤(Replication Filters)

复制过滤可以让你只复制服务器中的一部分数据,有两种复制过滤:在master上过滤二进制日志中的事件;在slave上过滤中继日志中的事件。如下:

 

 

 

4、复制的常用拓扑结构

复制的体系结构有以下一些基本原则:
(1)    每个slave只能有一个master;
(2)    每个slave只能有一个唯一的服务器ID;
(3)    每个master可以有很多slave;
(4)    如果你设置log_slave_updates,slave可以是其它slave的master,从而扩散master的更新。

 

MySQL不支持多主服务器复制(Multimaster Replication)——即一个slave可以有多个master。但是,通过一些简单的组合,我们却可以建立灵活而强大的复制体系结构。

 

4.1、单一master和多slave

由一个master和一个slave组成复制系统是最简单的情况。Slave之间并不相互通信,只能与master进行通信。

在实际应用场景中,MySQL复制90%以上都是一个Master复制到一个或者多个Slave的架构模式,主要用于读压力比较大的应用的数据库端廉价扩展解决方案。因为只要Master和Slave的压力不是太大(尤其是Slave端压力)的话,异步复制的延时一般都很少很少。尤其是自从Slave端的复制方式改成两个线程处理之后,更是减小了Slave端的延时问题。而带来的效益是,对于数据实时性要求不是特别Critical的应用,只需要通过廉价的pcserver来扩展Slave的数量,将读压力分散到多台Slave的机器上面,即可通过分散单台数据库服务器的读压力来解决数据库端的读性能瓶颈,毕竟在大多数数据库应用系统中的读压力还是要比写压力大很多。这在很大程度上解决了目前很多中小型网站的数据库压力瓶颈问题,甚至有些大型网站也在使用类似方案解决数据库瓶颈。

如下:

如果写操作较少,而读操作很时,可以采取这种结构。你可以将读操作分布到其它的slave,从而减小master的压力。但是,当slave增加到一定数量时,slave对master的负载以及网络带宽都会成为一个严重的问题。
这种结构虽然简单,但是,它却非常灵活,足够满足大多数应用需求。一些建议:
(1)    不同的slave扮演不同的作用(例如使用不同的索引,或者不同的存储引擎);
(2)    用一个slave作为备用master,只进行复制;
(3)    用一个远程的slave,用于灾难恢复;

大家应该都比较清楚,从一个Master节点可以复制出多个Slave节点,可能有人会想,那一个Slave节点是否可以从多个Master节点上面进行复制呢?至少在目前来看,MySQL是做不到的,以后是否会支持就不清楚了。

MySQL不支持一个Slave节点从多个Master节点来进行复制的架构,主要是为了避免冲突的问题,防止多个数据源之间的数据出现冲突,而造成最后数据的不一致性。不过听说已经有人开发了相关的patch,让MySQL支持一个Slave节点从多个Master结点作为数据源来进行复制,这也正是MySQL开源的性质所带来的好处。

 

 

4.2、主动模式的Master-Master(Master-Master in Active-Active Mode)

Master-Master复制的两台服务器,既是master,又是另一台服务器的slave。这样,任何一方所做的变更,都会通过复制应用到另外一方的数据库中。

可能有些读者朋友会有一个担心,这样搭建复制环境之后,难道不会造成两台MySQL之间的循环复制么?实际上MySQL自己早就想到了这一点,所以在MySQL的BinaryLog中记录了当前MySQL的server-id,而且这个参数也是我们搭建MySQLReplication的时候必须明确指定,而且Master和Slave的server-id参数值比需要不一致才能使MySQLReplication搭建成功。一旦有了server-id的值之后,MySQL就很容易判断某个变更是从哪一个MySQLServer最初产生的,所以就很容易避免出现循环复制的情况。而且,如果我们不打开记录Slave的BinaryLog的选项(–log-slave-update)的时候,MySQL根本就不会记录复制过程中的变更到BinaryLog中,就更不用担心可能会出现循环复制的情形了。

如图:

 

主动的Master-Master复制有一些特殊的用处。例如,地理上分布的两个部分都需要自己的可写的数据副本。这种结构最大的问题就是更新冲突。假设一个表只有一行(一列)的数据,其值为1,如果两个服务器分别同时执行如下语句:
在第一个服务器上执行:
mysql> UPDATE tbl SET col=col + 1;
在第二个服务器上执行:
mysql> UPDATE tbl SET col=col * 2;
那么结果是多少呢?一台服务器是4,另一个服务器是3,但是,这并不会产生错误。
实际上,MySQL并不支持其它一些DBMS支持的多主服务器复制(Multimaster Replication),这是MySQL的复制功能很大的一个限制(多主服务器的难点在于解决更新冲突),但是,如果你实在有这种需求,你可以采用MySQL Cluster,以及将Cluster和Replication结合起来,可以建立强大的高性能的数据库平台。但是,可以通过其它一些方式来模拟这种多主服务器的复制。

 

4.3、主动-被动模式的Master-Master(Master-Master in Active-Passive Mode)

这是master-master结构变化而来的,它避免了M-M的缺点,实际上,这是一种具有容错和高可用性的系统。它的不同点在于其中一个服务只能进行只读操作。如图:

4.4 级联复制架构 Master –Slaves – Slaves

在有些应用场景中,可能读写压力差别比较大,读压力特别的大,一个Master可能需要上10台甚至更多的Slave才能够支撑注读的压力。这时候,Master就会比较吃力了,因为仅仅连上来的SlaveIO线程就比较多了,这样写的压力稍微大一点的时候,Master端因为复制就会消耗较多的资源,很容易造成复制的延时。

遇到这种情况如何解决呢?这时候我们就可以利用MySQL可以在Slave端记录复制所产生变更的BinaryLog信息的功能,也就是打开—log-slave-update选项。然后,通过二级(或者是更多级别)复制来减少Master端因为复制所带来的压力。也就是说,我们首先通过少数几台MySQL从Master来进行复制,这几台机器我们姑且称之为第一级Slave集群,然后其他的Slave再从第一级Slave集群来进行复制。从第一级Slave进行复制的Slave,我称之为第二级Slave集群。如果有需要,我们可以继续往下增加更多层次的复制。这样,我们很容易就控制了每一台MySQL上面所附属Slave的数量。这种架构我称之为Master-Slaves-Slaves架构

这种多层级联复制的架构,很容易就解决了Master端因为附属Slave太多而成为瓶颈的风险。下图展示了多层级联复制的Replication架构。

当然,如果条件允许,我更倾向于建议大家通过拆分成多个Replication集群来解决

上述瓶颈问题。毕竟Slave并没有减少写的量,所有Slave实际上仍然还是应用了所有的数据变更操作,没有减少任何写IO。相反,Slave越多,整个集群的写IO总量也就会越多,我们没有非常明显的感觉,仅仅只是因为分散到了多台机器上面,所以不是很容易表现出来。

此外,增加复制的级联层次,同一个变更传到最底层的Slave所需要经过的MySQL也会更多,同样可能造成延时较长的风险。

而如果我们通过分拆集群的方式来解决的话,可能就会要好很多了,当然,分拆集群也需要更复杂的技术和更复杂的应用系统架构。

 4.5、带从服务器的Master-Master结构(Master-Master with Slaves)

这种结构的优点就是提供了冗余。在地理上分布的复制结构,它不存在单一节点故障问题,而且还可以将读密集型的请求放到slave上。

 

 

级联复制在一定程度上面确实解决了Master因为所附属的Slave过多而成为瓶颈的问题,但是他并不能解决人工维护和出现异常需要切换后可能存在重新搭建Replication的问题。这样就很自然的引申出了DualMaster与级联复制结合的Replication架构,我称之为Master-Master-Slaves架构

和Master-Slaves-Slaves架构相比,区别仅仅只是将第一级Slave集群换成了一台单独的Master,作为备用Master,然后再从这个备用的Master进行复制到一个Slave集群。

这种DualMaster与级联复制结合的架构,最大的好处就是既可以避免主Master的写入操作不会受到Slave集群的复制所带来的影响,同时主Master需要切换的时候也基本上不会出现重搭Replication的情况。但是,这个架构也有一个弊端,那就是备用的Master有可能成为瓶颈,因为如果后面的Slave集群比较大的话,备用Master可能会因为过多的SlaveIO线程请求而成为瓶颈。当然,该备用Master不提供任何的读服务的时候,瓶颈出现的可能性并不是特别高,如果出现瓶颈,也可以在备用Master后面再次进行级联复制,架设多层Slave集群。当然,级联复制的级别越多,Slave集群可能出现的数据延时也会更为明显,所以考虑使用多层级联复制之前,也需要评估数据延时对应用系统的影响。

转自:http://blog.csdn.net/hguisu/article/details/7325124

Mysql数据库主从心得整理

管理mysql主从有2年多了,管理过200多组mysql主从,几乎涉及到各个版本的主从,本博文属于总结性的,有一部分是摘自网络,大部分是根据自己管理的心得和经验所写,整理了一下,分享给各位同行,希望对大家有帮助,互相交流。

一、mysql主从的原理

1、Replication 线程

Mysql的 Replication 是一个异步的复制过程(mysql5.1.7以上版本分为异步复制和半同步两种模式),从一个 Mysql instace(我们称之为 Master)复制到另一个 Mysql instance(我们称之 Slave)。在 Master 与 Slave 之间的实现整个复制过程主要由三个线程来完成,其中两个线程(Sql线程和IO线程)在 Slave 端,另外一个线程(IO线程)在 Master 端。

要实现 MySQL 的 Replication ,首先必须打开 Master 端的Binary Log(mysql-bin.xxxxxx)功能,否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全 顺序的执行日志中所记录的各种操作。打开 MySQL 的 Binary Log 可以通过在启动 MySQL Server 的过程中使用 “—log-bin” 参数选项,或者在 my.cnf 配置文件中的 mysqld 参数组([mysqld]标识后的参数部分)增加 “log-bin” 参数项。

2、MySQL 复制的基本过程如下:
2.1Slave 上面的IO线程连接上 Master,并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容;

2.2. Master 接收到来自 Slave 的 IO 线程的请求后,通过负责复制的 IO 线程根据请求信息读取指定日志指定位置之后的日志信息,返回给 Slave 端的 IO 线程。返回信息中除了日志所包含的信息之外,还包括本次返回的信息在 Master 端的 Binary Log 文件的名称以及在 Binary Log 中的位置;

2.3. Slave 的 IO 线程接收到信息后,将接收到的日志内容依次写入到 Slave 端的Relay Log文件(mysql-relay-bin.xxxxxx)的最末端,并将读取到的Master端的bin-log的文件名和位置记录到master- info文件中,以便在下一次读取的时候能够清楚的高速Master“我需要从某个bin-log的哪个位置开始往后的日志内容,请发给我”

2.4. Slave 的 SQL 线程检测到 Relay Log 中新增加了内容后,会马上解析该 Log 文件中的内容成为在 Master 端真实执行时候的那些可执行的 Query 语句,并在自身执行这些 Query。这样,实际上就是在 Master 端和 Slave 端执行了同样的 Query,所以两端的数据是完全一样的。

 

3、Mysql复制的几种模式

3.1.从 MySQL 5.1.12 开始,可以用以下三种模式来实现:
– 基于SQL语句的复制(statement-based replication, SBR),
– 基于行的复制(row-based replication, RBR),
– 混合模式复制(mixed-based replication, MBR)。
相应地,binlog的格式也有三种:STATEMENT,ROW,MIXED。 MBR 模式中,SBR 模式是默认的。
在运行时可以动态改动 binlog的格式,除了以下几种情况:
1.存储流程或者触发器中间
2.启用了NDB
3.当前会话试用 RBR 模式,并且已打开了临时表

如果binlog采用了 MIXED 模式,那么在以下几种情况下会自动将binlog的模式由 SBR 模式改成 RBR 模式:
1.当DML语句更新一个NDB表时
2.当函数中包含 UUID() 时
3.2个及以上包含 AUTO_INCREMENT 字段的表被更新时
4.行任何 INSERT DELAYED 语句时
5.用 UDF 时
6.视图中必须要求运用 RBR 时,例如建立视图是运用了 UUID() 函数

3.2.设定主从复制模式:

log-bin=mysql-bin
#binlog_format="STATEMENT"
#binlog_format="ROW"
binlog_format="MIXED"
也可以在运行时动态修改binlog的格式。例如
mysql> SET SESSION binlog_format = 'STATEMENT';
mysql> SET SESSION binlog_format = 'ROW';
mysql> SET SESSION binlog_format = 'MIXED';
mysql> SET GLOBAL binlog_format = 'STATEMENT';
mysql> SET GLOBAL binlog_format = 'ROW';
mysql> SET GLOBAL binlog_format = 'MIXED';

3.3.两种模式各自的优缺点:

SBR 的优点:
历史悠久,技能成熟
binlog文件较小
binlog中包含了所有数据库修改信息,可以据此来审核数据库的安全等情况
binlog可以用于实时的还原,而不仅仅用于复制
主从版本可以不一样,从服务器版本可以比主服务器版本高

SBR 的缺点:
不是所有的UPDATE语句都能被复制,尤其是包含不确定操作的时候。
调用具有不确定因素的 UDF 时复制也可能出疑问
运用以下函数的语句也不能被复制:
* LOAD_FILE()
* UUID()
* USER()
* FOUND_ROWS()
* SYSDATE() (除非启动时启用了 –sysdate-is-now 选项)
INSERT … SELECT 会产生比 RBR 更多的行级锁
复制须要执行 全表扫描(WHERE 语句中没有运用到索引)的 UPDATE 时,须要比 RBR 请求更多的行级锁
对于有 AUTO_INCREMENT 字段的 InnoDB表而言,INSERT 语句会阻塞其他 INSERT 语句
对于一些复杂的语句,在从服务器上的耗资源情况会更严重,而 RBR 模式下,只会对那个发生变化的记录产生影响
存储函数(不是存储流程 )在被调用的同时也会执行一次 NOW() 函数,这个可以说是坏事也可能是好事
确定了的 UDF 也须要在从服务器上执行
数据表必须几乎和主服务器保持一致才行,否则可能会导致复制出错
执行复杂语句如果出错的话,会消耗更多资源

RBR 的优点:
任何情况都可以被复制,这对复制来说是最安全可靠的
和其他大多数数据库系统的复制技能一样
多数情况下,从服务器上的表如果有主键的话,复制就会快了很多
复制以下几种语句时的行锁更少:
* INSERT … SELECT
* 包含 AUTO_INCREMENT 字段的 INSERT
* 没有附带条件或者并没有修改很多记录的 UPDATE 或 DELETE 语句
执行 INSERT,UPDATE,DELETE 语句时锁更少
从服务器上采用多线程来执行复制成为可能

RBR 的缺点:
binlog 大了很多
复杂的回滚时 binlog 中会包含大量的数据
主服务器上执行 UPDATE 语句时,所有发生变化的记录都会写到 binlog 中,而 SBR 只会写一次,这会导致频繁发生 binlog 的并发写疑问
UDF 产生的大 BLOB 值会导致复制变慢
不能从 binlog 中看到都复制了写什么语句(加密过的)
当在非事务表上执行一段堆积的SQL语句时,最好采用 SBR 模式,否则很容易导致主从服务器的数据不一致情况发生
另外,针对系统库 mysql 里面的表发生变化时的处理准则如下:
如果是采用 INSERT,UPDATE,DELETE 直接操作表的情况,则日志格式根据 binlog_format 的设定而记录
如果是采用 GRANT,REVOKE,SET PASSWORD 等管理语句来做的话,那么无论如何 都采用 SBR 模式记录。
注:采用 RBR 模式后,能处理很多原先出现的主键重复问题。实例:
对于insert into db_allot_ids select * from db_allot_ids 这个语句:
在BINLOG_FORMAT=STATEMENT 模式下:
BINLOG日志信息为:

BEGIN
/*!*/;
# at 173
#090612 16:05:42 server id 1 end_log_pos 288 Query thread_id=4 exec_time=0 error_code=0
SET TIMESTAMP=1244793942/*!*/;
insert into db_allot_ids select * from db_allot_ids
/*!*/;

 

在BINLOG_FORMAT=ROW 模式下:

BINLOG日志信息为:

BINLOG '
hA0yShMBAAAAMwAAAOAAAAAAAA8AAAAAAAAAA1NOUwAMZGJfYWxsb3RfaWRzAAIBAwAA
hA0yShcBAAAANQAAABUBAAAQAA8AAAAAAAEAAv/8AQEAAAD8AQEAAAD8AQEAAAD8AQEAAAA=
'/*!*/;

 

4、Mysql主从的优缺点

MySQL的主从同步是一个很成熟的架构,优点为:①在从服务器可以执行查询工作(即我们常说的读功能),降低主服 务器压力;②在从主服务器进行备份,避免备份期间影响主服务器服务;③当主服务器出现问题时,可以切换到从服务器。所以我在项目部署和实施中经常会采用这种方案;鉴于生产环境下的mysql的严谨性。

实际上,在老版本中,MySQL 的复制实现在 Slave 端并不是由 SQL 线程和 IO 线程这两个线程共同协作而完成的,而是由单独的一个线程来完成所有的工作。但是 MySQL 的工程师们很快发现,这样做存在很大的风险和性能问题,主要如下:

首先,如果通过一个单一的线程来独立实现这个工作的话,就使复制 Master 端的,Binary Log日志,以及解析这些日志,然后再在自身执行的这个过程成为一个串行的过程,性能自然会受到较大的限制,这种架构下的 Replication 的延迟自然就比较长了。

其次,Slave 端的这个复制线程从 Master 端获取 Binary Log 过来之后,需要接着解析这些内容,还原成 Master 端所执行的原始 Query,然后在自身执行。在这个过程中,Master端很可能又已经产生了大量的变化并生成了大量的 Binary Log 信息。如果在这个阶段 Master 端的存储系统出现了无法修复的故障,那么在这个阶段所产生的所有变更都将永远的丢失,无法再找回来。这种潜在风险在Slave 端压力比较大的时候尤其突出,因为如果 Slave 压力比较大,解析日志以及应用这些日志所花费的时间自然就会更长一些,可能丢失的数据也就会更多。

所以,在后期的改造中,新版本的 MySQL 为了尽量减小这个风险,并提高复制的性能,将 Slave 端的复制改为两个线程来完成,也就是前面所提到的 SQL 线程和 IO 线程。最早提出这个改进方案的是Yahoo!的一位工程师“Jeremy Zawodny”。通过这样的改造,这样既在很大程度上解决了性能问题,缩短了异步的延时时间,同时也减少了潜在的数据丢失量。

当然,即使是换成了现在这样两个线程来协作处理之后,同样也还是存在 Slave 数据延时以及数据丢失的可能性的,毕竟这个复制是异步的。只要数据的更改不是在一个事务中,这些问题都是存在的。

如果要完全避免这些问题,就只能用 MySQL 的 Cluster 来解决了。不过 MySQL的 Cluster 知道笔者写这部分内容的时候,仍然还是一个内存数据库的解决方案,也就是需要将所有数据包括索引全部都 Load 到内存中,这样就对内存的要求就非常大的大,对于一般的大众化应用来说可实施性并不是太大。MySQL 现在正在不断改进其 Cluster 的实现,其中非常大的一个改动就是允许数据不用全部 Load 到内存中,而仅仅只是索引全部 Load 到内存中,我想信在完成该项改造之后的 MySQL Cluster 将会更加受人欢迎,可实施性也会更大。

5、Mysql的半同步模式(Semisynchronous Replication)

我们知道在5.5之前,MySQL的复制其实是异步操作,而不是同步,也就意味着允许主从之间的数据存在一定的延迟,mysql当初这样设计的目的可能也是基于可用性的考虑,为了保证master不受slave的影响,并且异步复制使得master处于一种性能最优的状态:写完binlog后即可提交而不需要等待slave的操作完成。这样存在一个隐患,当你使用slave作为备份时,如果master挂掉,那么会存在部分已提交的事务未能成功传输到slave的可能,这就意味着数据丢失!

在MySQL5.5版本中,引入了半同步复制模式(Semi-synchronous Replication)能够成功(只是相对的)避免上述数据丢失的隐患。在这种模式下:master会等到binlog成功传送并写入至少一个slave的relay log之后才会提交,否则一直等待,直到timeout(默认10s)。当出现timeout的时候,master会自动切换半同步为异步,直到至少有一个slave成功收到并发送Acknowledge,master会再切换回半同步模式。结合这个新功能,我们可以做到,在允许损失一定的事务吞吐量的前提下来保证同步数据的绝对安全,因为当你设置timeout为一个足够大的值的情况下,任何提交的数据都会安全抵达slave。

mysql5.5 版本支持半同步复制功能(Semisynchronous Replication),但还不是原生的支持,是通过plugin来支持的,并且默认是没有安装这个插件的。不论是二进制发布的,还是自己源代码编译的,都会默认生成这个插件,一个是针对master 的一个是针对slave的,在使用之前需要先安装这俩plugins。

二、Mysql主从复制的过滤
复制的过滤主要有2种方式:
1、在主服务器在把事件从进二制日志中过滤掉,相关的参数是:binlog_do_db和binlog_ignore_db。
2、在从服务器上把事件从中继日志中过滤掉,相关的参数是replicate_*。
复制只能扩展读取,不能扩展写入,对数据进行分区可以进行扩展写入。
复制的优化:
在mysql复制环境中,有8个参数可以让我们控制,需要复制或需要忽略不进行复制的DB或table分别为:
下面二项需要在Master上设置:
Binlog_Do_DB:设定哪些数据库需要记录Binlog
Binlog_Ignore_DB:设定哪里数据库不需要记录Binlog
优点是Master端的Binlog记录所带来的Io量减少,网络IO减少,还会让slave端的IO线程,SQL线程减少,从而大幅提高复制性能,
缺点是mysql判断是否需要复制某个事件不是根据产生该事件的查询所在的DB,而是根据执行查询时刻所在的默认数据库(也就是登录时指定的库名或运行”use database”中指定的DB),只有当前默认DB和配置中所设定的DB完全吻合时IO线程才会将该事件读取给slave的IO线程.所以,如果在默认DB和设定须要复制的DB不一样的情况下改变了须要复制的DB中某个Table中的数据,该事件是不会被复制到Slave中去的,这样就会造成Slave端的数据和Master的数据不一致.同样,在默认的数据库下更改了不须要复制的数据库中的数据,则会被复制到slave端,当slave端并没有该数据库时,则会造成复制出错而停止。

下面六项需要在slave上设置:
Replicate_Do_DB:设定需要复制的数据库,多个DB用逗号分隔
Replicate_Ignore_DB:设定可以忽略的数据库.
Replicate_Do_Table:设定需要复制的Table
Replicate_Ignore_Table:设定可以忽略的Table
Replicate_Wild_Do_Table:功能同Replicate_Do_Table,但可以带通配符来进行设置。
Replicate_Wild_Ignore_Table:功能同Replicate_Do_Table,功能同Replicate_Ignore_Table,可以带通配符。
优点是在slave端设置复制过滤机制,可以保证不会出现因为默认的数据库问题而造成Slave和Master数据不一致或复制出错的问题.
缺点是性能方面比在Master端差一些.原因在于:不管是否须要复制,事件都会被IO线程读取到Slave端,这样不仅增加了网络IO量,也给Slave端的IO线程增加了Relay Log的写入量。
注:在实际的生产应用中发现,在mysql5.0以前的版本,mysql的这个过滤设置几乎是形同虚设,不起作用:不管你在主库或是从库上设置了忽略某个数据库或是表,他依然会进行同步,所以在做5.0以前版本的主从同步时,一定保持主从数据库的一致性,主上有的库或是表从上一定要有,否则在同步的过程会出错。

三、Mysql主从同步的配置

主库IP:192.168.1.2
从库IP:192.168.1.3
添加一个用于主从同步的用户:
GRANT REPLICATION SLAVE ON *.* TO ‘repl’@’%’ IDENTIFIED BY ‘1q2w3e4r’;
如果监控mysql主从的话,请加上一个super权限:
GRANT SUPER, REPLICATION SLAVE ON *.* TO ‘repl’@’%’ IDENTIFIED BY ’1q2w3e4r’;

1、主库的配置
1.1.mysql5.0以下版本的配置

修改主库mysql配置配置文件,在[mysqld]段添加以下内容:

server-id = 1
log-bin=/home/mysql/logs/binlog/bin-log
max_binlog_size = 500M
binlog_cache_size = 128K
binlog-do-db = adb
binlog-ignore-db = mysql
log-slave-updates

 

1.2. mysql5.0以上版本的配置

修改主库mysql配置配置文件,在[mysqld]段添加以下内容:

server-id = 1
log-bin=/home/mysql/logs/binlog/bin-log
max_binlog_size = 500M
binlog_cache_size = 128K
binlog-do-db = adb
binlog-ignore-db = mysql
log-slave-updates
expire_logs_day=2
binlog_format="MIXED"

 

1.3.各个参数的含义和相关注意项:

server-id = 1 #服务器标志号,注意在配置文件中不能出现多个这样的标识,如果出现多个的话mysql以第一个为准,一组主从中此标识号不能重复。
log-bin=/home/mysql/logs/binlog/bin-log #开启bin-log,并指定文件目录和文件名前缀。
max_binlog_size = 500M #每个bin-log最大大小,当此大小等于500M时会自动生成一个新的日志文件。一条记录不会写在2个日志文件中,所以有时日志文件会超过此大小。
binlog_cache_size = 128K #日志缓存大小
binlog-do-db = adb #需要同步的数据库名字,如果是多个,就以此格式在写一行即可。
binlog-ignore-db = mysql  #不需要同步的数据库名字,如果是多个,就以此格式在写一行即可。
log-slave-updates  #当Slave从Master数据库读取日志时更新新写入日志中,如果只启动log-bin 而没有启动log-slave-updates则Slave只记录针对自己数据库操作的更新。
expire_logs_day=2 #设置bin-log日志文件保存的天数,此参数mysql5.0以下版本不支持。
binlog_format=”MIXED”   #设置bin-log日志文件格式为:MIXED,可以防止主键重复。

2、从库的配置
2.1.mysql5.1.7以前版本
修改从库mysql配置配置文件,在[mysqld]段添加以下内容:

server-id=2
master-host=192.168.1.2
master-user=repl
master-password=1q2w3e4r
master-port=3306
master-connect-retry=30
slave-skip-errors=1062
replicate-do-db = adb
replicate-ignore-db = mysql
slave-skip-errors=1007,1008,1053,1062,1213,1158,1159
master-info-file = /home/mysql/logs/master.info
relay-log = /home/mysql/logs/relay-bin
relay-log-index = /home/mysql/logs/relay-bin.index
relay-log-info-file = /home/mysql/logs/relay-log.info

 

如果修改了连接主库相关信息,重启之前一定要删除master.info文件,否则重启之后由于连接信息改变从库而不会自动连接主库,造成同步失败。此文件是保存连接主库信息的。

2.2.mysql5.1.7以后版本

Mysql5.1.7版本在丛库上面的配置很少,主要是采用了新的同步信息记录方式,他不在支持在配置文件中配置连接主库的相关信息,而是把连接等相关信息记录在master-info-file = /home/mysql/logs/master.info文件中,如果入库变了,直接在mysql命令行执行连接信息的改变即可生效,比较灵活了,而不用去重启mysql。修改从库mysql配置配置文件,在[mysqld]段添加以下内容:
slave-skip-errors=1007,1008,1053,1062,1213,1158,1159

2.3. 各个参数的含义和相关注意项
这里只讲一下2个参数,其他全部是从库连接主库的信息和中间日志relay-log的设置。
master-connect-retry=30 #这个选项控制重试间隔,默认为60秒。
slave-skip-errors=1007,1008,1053,1062,1213,1158,1159 #这个是在同步过程中忽略掉的错误,这些错误不会影响数据的完整性,有事经常出现的错误,一般设置忽略。其中1062为主键重复错误。

3、实现主从同步
3.1.实现数据库的统一
检查主从数据库的配置文件,查看是否已正确配置。首次实现 同步要备份主库上需要同步的数据库,然后完整的导入到从库中。注:mysql5.0之前的版本涉及到mysql本身复制过滤存在问题,需要把所有的数据库都备份导入到丛库,保持。

3.2.查看并记录主库bin-log信息
进入主库mysql中,执行:show master status;显示信息如下:
mysql> show master status;
+————-+———-+————–+——————+
| File        | Position | Binlog_do_db | Binlog_ignore_db |
+————-+———-+————–+——————+
| bin-log.003 | 4        | adb          | mysql            |
+————-+———-+————–+——————+
1 row in set (0.00 sec)
记录File 和Position信息;
3.3.在从库上执行同步语句
进入mysql,执行以下语句:

slave stop;
change master to
master_host='192.168.1.2',
master_user='repl',
master_password='1q2w3e4r',
master_port=3306,
master_log_file='bin-log.003',
master_log_pos=4;
slave start;

 

3.4.查看主从同步状态

进入mysql,执行show slave status\G;显示如下(mysql版本不同查询的结果不同,但是重要的指标还是一样的):
Mysql5.0之前的版本如下:

123459386

Mysql5.5之前的版本如下:

8

Mysql5.5的版本如下:
9

重要的指标为:
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Master_Log_File: bin-log.003
Relay_Master_Log_File: bin-log.003
Read_Master_Log_Pos: 4
Exec_master_log_pos: 4
Seconds_Behind_Master: 0(5.0之前版本没有这个选项)
以上选项是两两对应的,只要结果是一致的,就说明主从同步成功。

3.5.同步中的常见的错误和处理
1、现象:在从库上面show slave status\G;出现下列情况,
Slave_IO_Running: Yes
Slave_SQL_Running: No
Seconds_Behind_Master: NULL
原因:
a.程序可能在slave上进行了写操作;
b.也可能是slave机器重起后,事务回滚造成的;
c.有可能是在同步过程中遇到某种错误,这个会在查看从库中状态时看到错误提示,最少见的就是主键重复1062的错误。
解决方法:
进入master
mysql> show master status;
+———————-+———-+————–+——————+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+———————-+———-+————–+——————+
| mysql-bin.000040 | 324 |adb | mysql|
+———————-+———-+————–+——————+
然后到slave服务器上执行手动同步

 

slave stop;
change master to
master_host='10.14.0.140',
master_user='repl',
master_password='1q2w3e4r',
master_port=3306,
master_log_file='mysql-bin.000040',
master_log_pos=324;
slave start;
show slave status\G;

 

2、现象:从数据库无法同步,show slave status显示:

Slave_IO_Running: No
Slave_SQL_Running: Yes
Seconds_Behind_Master: NULL

 

解决:首先查看数据库的err日志,查看是什么错误提示,看从库连接主库的IP、用户、密码等相关信息是否有误,如果有误,重新执行同步;如果确认无误,重启主数据库。

mysql> show master status;
+——————+———-+————–+——————+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+——————+———-+————–+——————+
| mysql-bin.000001 | 98 | adb| mysql|
+——————+———-+————–+——————+
进入从库mysql,执行:

slave stop;
change master to Master_Log_File='mysql-bin.000001',Master_Log_Pos=98;
slave start;

或是这样:

slave stop;
change master to Master_Log_File='mysql-bin.000001',Master_Log_Pos=98;
slave start;

 

这个现象主要是master数据库存在问题,由于连接主库信息错误、主库数据库挂掉如果说常见错等原因引起的,我在实际的操作中先重启master后重启slave即可解决这问题,出现此问题,必须要要重启master数据库。

四、mysql主主和主主集群

1、mysql主主的实现
在实际的生产应用中,为了在主库出现崩溃或是主服务器出现严重故障时快速的恢复业务,会直接切换到从库上,当主库故障处理完成后让他直接作为丛库来运行,此时主主就是一个不错的选择。

五、mysql主从的监控
在mysql主从的应用中,只要进行了合理设置,基本上不会出现问题,但是对他的监控是必不可少的,以免由于真的出现问题又不知道而造成不必要的数据损失。
1、mysql主从监控的主要思路
Mysql主从的监控,其主要是监控从库上的一些重要参数:
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Master_Log_File: bin-log.003
Relay_Master_Log_File: bin-log.003
Read_Master_Log_Pos: 4
Exec_master_log_pos: 4
Seconds_Behind_Master: 0(5.0之前版本没有这个选项)
通过以上的参数可以反映出主库和从库状态是否正常,从库是否落后于主库等。值得一提的是在mysql5.0以前的版本,Slave_IO_Running这个状态指标不可靠,会在主库直接挂掉的情况下不会变成NO,Seconds_Behind_Master参数也不存在。监控以上参数即可监控mysql主从。

2、mysql主从监控的实现
不管mysql是那个版本,其中的从库上的Exec_master_log_pos、Exec_master_log_pos;主库上的 Master上的Log_File, Position,这四个参数可以判断出当前主从的状态。以下是适用于mysql所有版本的主从监控shell脚本:

#/bin/sh
user=repl
passwd=123415
master_ip="192.168.1.2"
log="/data3/check_repl.log"
value()
{
 master=`/usr/local/mysql/bin/mysql -u$user -p$passwd -h$master_ip -e "show master status\G;"|egrep "File|Position"`
 #mysql 4.0
 slave=`/usr/local/mysql/bin/mysql -u$user -p$passwd -h127.0.0.1 -e "show slave status\G;"|egrep "Relay_Master_Log_File|Exec_master_log_pos"`
 #mysql 5.0
 #slave=`mysql -u$user -p$passwd -e "show slave status\G;"|egrep "Relay_Master_Log_File|Exec_Master_Log_Pos"`
 #取主库上的bin-log号及写入的当前日志位置   
 Master_Log=`echo $master |awk '{print $2}'|awk -F "." '{print $2}'`
 Master_Log_Pos=`echo $master |awk '{print $4}'`
 #取从库上当前同步主库的位置
 Relay_Master_Log_File=`echo $slave |awk '{print $2}'|awk -F "." '{print $2}'`
 Exec_Master_Log_Pos=`echo $slave |awk '{print $4}'`
 echo "Master_Log:"$Master_Log>>$log
 echo "Master_Log_Pos:"$Master_Log_Pos>>$log
 echo "Relay_Master_Log_File:"$Relay_Master_Log_File>>$log
 echo "Exec_Master_Log_Pos:"$Exec_Master_Log_Pos>>$log
}
for((i=1;i<=10;i++));
do
 echo "#################################">>$log
 value
 time=`date +"%Y-%m-%d %H:%M:%S"`
 if [ $Master_Log -eq $Relay_Master_Log_File ];then
       A=`expr $Master_Log_Pos - $Exec_Master_Log_Pos`
       if [ $A -lt 0 ];then
             A=`expr 0 - $A`
       fi
       echo $A>>$log
       if [ $A -lt 10000 ];then
             echo "$time Master-Slave is OK.">>$log
             #echo "$i"
             break
       else
             if [ $i ge 3 ];then              
                  echo "$time Warning:Slave-Master lag $A " >>$log
                  echo "$i"
             fi
             sleep 30
             continue
       fi
 else
       sleep 60
       fi
       if [ $i -eq 10 ];then
             echo "$i"
             echo "$time Error:Slave-Master must be check !" >>$log
       fi
done

在mysql5.0以后的版本,mysql主从已经相当的成熟了,可以只监控Slave_IO_Running,Slave_SQL_Running,Seconds_Behind_Master状态就可以了,这里不再做说明。

转自:http://blog.sae.sina.com.cn/archives/4666

Haproxy+keepalived实现sphinx高可用负载均衡

 

环境如下:
【node3】
haproxy:192.168.1.189
【node4】
haproxy:192.168.1.103
vip:192.168.1.222/192.168.1.223

# apt-get install ipvsadm
# apt-get install linux-headers-$(uname -r)
# ln -s /usr/src/linux-headers-2.6.32-33 /usr/src/linux
# wget http://www.keepalived.org/software/keepalived-1.2.2.tar.gz
# tar zxvf keepalived-1.2.2.tar.gz -C ../software/
# ./configure –prefix=/usr/local/keepalived-1.2.2
configure: error:!!! OpenSSL is not properly installed on your system. !!!!!! Can not include OpenSSL headers files.解决办法:
# apt-get install libssl-dev
configure: error: Popt libraries is required
解决办法:
# apt-get install libpopt-dev
configure: WARNING: keepalived will be built without libnl support.
解决办法:
# apt-get install libnl-dev
/usr/include/stdint.h:41: error: conflicting types for ‘int64_t’
/usr/src/linux/include/linux/types.h:125: error: previous declaration of ‘int64_t’ was here
/usr/include/stdint.h:56: error: conflicting types for ‘uint64_t’
解决办法:
# vim ./keepalived/libipvs-2.6/ip_vs.h
将#include <linux/types.h>移动到#include <sys/types.h>后面去。

# ./configure –prefix=/usr/local/keepalived-1.2.2
Keepalived configuration
————————
Keepalived version       : 1.2.2
Compiler                 : gcc
Compiler flags           : -g -O2
Extra Lib                : -lpopt -lssl -lcrypto  -lnl
Use IPVS Framework       : Yes
IPVS sync daemon support : Yes
IPVS use libnl           : Yes
Use VRRP Framework       : Yes
Use Debug flags          : No
# make
# make install

# vim /etc/sysctl.conf

net.ipv4.ip_nonlocal_bind=1

# sysctl -p

【node3】

global_defs {
router_id LVS_DEVEL
}

vrrp_script chk_haproxy {
script “/usr/local/scripts/chk_haproxy.sh”
interval 2
weight 2
}

vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 76
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass 123456
}
track_script {
chk_haproxy
}
virtual_ipaddress {
192.168.1.222
}
}

vrrp_instance VI_2 {
state BACKUP
interface eth0
virtual_router_id 77
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 123456
}
track_script {
chk_haproxy
}
virtual_ipaddress {
192.168.1.223
}
}

 

【node4】

global_defs {
router_id LVS_DEVEL
}

vrrp_script chk_haproxy {
script “/usr/local/scripts/chk_haproxy.sh”
interval 2
weight 2
}

vrrp_instance VI_1 {
state BACKUP
interface eth0
virtual_router_id 76
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 123456
}
track_script {
chk_haproxy
}
virtual_ipaddress {
192.168.1.222
}
}

vrrp_instance VI_2 {
state MASTER
interface eth0
virtual_router_id 77
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass 123456
}
track_script {
chk_haproxy
}
virtual_ipaddress {
192.168.1.223
}
}

 

# vim chk_haproxy.sh

#!/bin/bash

STATUS=`netstat -nptl | grep haproxy | grep 3312 | wc -l`

if [ "$STATUS" -eq "0" ]; then
/usr/local/haproxy-1.4.18/sbin/haproxy -f /usr/local/haproxy-1.4.18/haproxy.conf
STATUS2=`netstat -nptl | grep haproxy | grep 3312 | wc -l`
if [ "$STATUS2" -eq "0"  ]; then
kill -9 $(ps -ef | grep keepalived | grep -v grep | awk ‘{print $2}’)
fi
fi

 

转自: http://www.ttlsa.com/sphinx/haproxy-keepalived-sphinx/

 

试试Linux下的ip命令,ifconfig已经过时了

linux的ip命令和ifconfig类似,但前者功能更强大,并旨在取代后者。使用ip命令,只需一个命令,你就能很轻松地执行一些网络管理任务。ifconfig是net-tools中已被废弃使用的一个命令,许多年前就已经没有维护了。iproute2套件里提供了许多增强功能的命令,ip命令即是其中之一。

Net tools vs Iproute2

要安装ip,请点击这里下载iproute2套装工具 。不过,大多数Linux发行版已经预装了iproute2工具。

你也可以使用git命令来下载最新源代码来编译:

$ git clone https://kernel.googlesource.com/pub/scm/linux/kernel/git/shemminger/iproute2.git

iproute2 git clone

设置和删除Ip地址

要给你的机器设置一个IP地址,可以使用下列ip命令:

$ sudo ip addr add 192.168.0.193/24 dev wlan0

请注意IP地址要有一个后缀,比如/24。这种用法用于在无类域内路由选择(CIDR)中来显示所用的子网掩码。在这个例子中,子网掩码是255.255.255.0。

在你按照上述方式设置好IP地址后,需要查看是否已经生效。

$ ip addr show wlan0

set ip address

你也可以使用相同的方式来删除IP地址,只需用del代替add。

$ sudo ip addr del 192.168.0.193/24 dev wlan0

delete ip address

列出路由表条目

ip命令的路由对象的参数还可以帮助你查看网络中的路由数据,并设置你的路由表。第一个条目是默认的路由条目,你可以随意改动它。

在这个例子中,有几个路由条目。这个结果显示有几个设备通过不同的网络接口连接起来。它们包括WIFI、以太网和一个点对点连接。

$ ip route show

ip route show

假设现在你有一个IP地址,你需要知道路由包从哪里来。可以使用下面的路由选项(译注:列出了路由所使用的接口等):

$ ip route get10.42.0.47

ip route get

更改默认路由

要更改默认路由,使用下面ip命令:

$ sudo ip route add default via 192.168.0.196

default route

显示网络统计数据

使用ip命令还可以显示不同网络接口的统计数据。

ip statistics all interfaces

当你需要获取一个特定网络接口的信息时,在网络接口名字后面添加选项ls即可。使用多个选项-s会给你这个特定接口更详细的信息。特别是在排除网络连接故障时,这会非常有用。

$ ip -s -s link ls p2p1

ip link statistics

ARP条目

地址解析协议(ARP)用于将一个IP地址转换成它对应的物理地址,也就是通常所说的MAC地址。使用ip命令的neigh或者neighbour选项,你可以查看接入你所在的局域网的设备的MAC地址。

$ ip neighbour

ip neighbour

监控netlink消息

也可以使用ip命令查看netlink消息。monitor选项允许你查看网络设备的状态。比如,所在局域网的一台电脑根据它的状态可以被分类成REACHABLE或者STALE。使用下面的命令:

$ ip monitor all

ip monitor all

激活和停止网络接口

你可以使用ip命令的up和down选项来激某个特定的接口,就像ifconfig的用法一样。

在这个例子中,当ppp0接口被激活和在它被停止和再次激活之后,你可以看到相应的路由表条目。这个接口可能是wlan0或者eth0。将ppp0更改为你可用的任意接口即可。

$ sudo ip link set ppp0 down 
$ sudo ip link set ppp0 up

ip link set up and down

获取帮助

当你陷入困境,不知道某一个特定的选项怎么用的时候,你可以使用help选项。man页面并不会提供许多关于如何使用ip选项的信息,因此这里就是获取帮助的地方。

比如,想知道关于route选项更多的信息:

$ ip route help

ip route help

小结

对于网络管理员们和所有的Linux使用者们,ip命令是必备工具。是时候抛弃ifconfig命令了,特别是当你写脚本时。

转自 http://linux.cn/article-3144-1.html

WordPress建站必备实用插件

1、百度sitemap:向百度提交sitemap,可以缩短百度收录网站的时间,提高收录的效率。

2、Google Analytics for WordPress:Google Analytics,Google统计非常好用,只是国内Google已经被禁用,但这不影响统计数据的提交,统计功能还是可以正常使用。必要时可以采取特殊手段查看统计结果,可以参考这里。毕竟目前在国内,Google Analytics还是无法替代的。

3、Google XML Sitemaps v3 for qTranslate:生成Google能识别的站点地图,有一些配置,可以在网站搜索具体的配置方法,同样可以提高Google的收录效率,可以结合Google站长工具,同样需要参考这里访问。

4、SyntaxHighlighter++:代码高亮插件,经常在博客中贴代码的同学必备。

5、UpdraftPlus – Backup/Restore:非常好用的站点备份工具,最新版本已经限制了非常多的功能,笔者一直在用老版本,还能使用GDrive作为远端的存储服务器,有非常多的定制化备份方案,当数据库操作出现失误,代码文件修改无法回退时,或者博客、插件和主题误升级之后,找不回之前的老版本时,这个插件备份下来的数据都可以起作用。即使笔者在本地为博客的代码建立了SVN,但是还是因为没有与本地做好同步,最终还是借助于这个插件备份的数据找回了丢失的代码。

6、WP-PageNavi分页导航:如果厌倦了只有“下一页”,“上一页”两个链接来翻页的话,可以试一下这个插件。

7、WP-PostRatings:Google在给出搜索结果时,会抓取网页的投票数据,这个插件提供多种可定制风格的打分按钮,非常趱。

8、WP-PostViews:显示文章被访问的次数,实时将文章的热度展现给访客。

9、WPJAM 七牛镜像存储:七牛的镜像存储功能插件,可以托管博客的静态资源。之前有写过一篇博客专门介绍:七牛镜像存储试用手记

10、WP SMTP:对于主机商不提供邮箱服务时,可以使用该插件绑定自己的私有邮箱来实现站点发信。能解决实际问题。当评论被回复时,自动发送邮件给评论者前来查看回复内容,非常实用。

11、WPtouch Mobile Plugin:试过很多移动主题插件,最终还是发现这一款是最好用的。

12、Yet Another Related Posts Plugin:相关日志列表实现插件。有写过一篇针对这个插件的加强方案,参见这里:WordPress “相关阅读”插件功能增强

13、简单算术题评论验证码插件:解决垃圾评论的问题,非常有效。参考这里:彻底解决WordPress博客垃圾评论的问题

转自:http://shentar.me/wordpress建站必备实用插件/

Apache安全配置

0x00 测试环境

centos6.5+apache2.2.15+php5.3.3

0x01 php的运行模式介绍


php的运行模式分四种:

1. CGI通用网关接口 
2. fast-cgi常驻型的CGI 
3. cli命令行运行 
4. web模块模式 

一般情况下,apache使用web模块模式运行php

0x02 Apache运行原理介绍


Apache是基于模块化设计的,各个模块在系统启动的时候按需载入。Apache对于php的解析,就是通过众多Module中的php Module来完成的。

2014080322524877722.png

所以,php加载成为了apache的一个模块,可以把apache和php当成一个整体看待。

当浏览器请求一个php文件时,我们可以理解为apache直接处理返回给浏览器结果,服务器上也只会有httpd进程,而不会有php进程。

apache的一些配置主要是通过httpd.conf来实现的,但是可以在httpd.conf中开启对.htaccess的支持,然后在.htaccess中进行配置。不过一般情况下,不应该使用.htaccess文件,除非你对主配置文件没有访问权限。.htaccess文件应该被用在内容提供者需要针对特定目录改变服务器的配置而又没有root权限的情况下。如果服务器管理员不愿意频繁修改配置,则可以允许用户通过.htaccess文件自己修改配置。

0x03 Apache安全配置方案


1. 选择漏洞较少的apache版本,并打上安全补丁

查看apache版本号:httpd -v

然后在sebug上搜索该版本号有什么漏洞,可根据提示提升版本或者打上补丁

2. 关闭一些不使用的模块及功能

可在LoadModule前加#,来注释掉一些不使用的模块

3. 隐藏banner信息

ServerTokens OS  修改为:ServerTokens Prod (在出现错误页的时候不显示服务器操作系统的名称)

ServerSignature On 修改为:ServerSignature Off(不回显apache版本信息)

4. 删除默认网站及页面

删除默认的页面,防止泄露服务器信息

5. 可修改banner信息

6. 配置http.conf禁止目录浏览

将Options Indexes FollowSymLinks改为Options -Indexes FollowSymLinks

7. 配置http.conf设置默认文档

DirectoryIndex index.html

8. 合理配置apache的运行账户

为apache单独建立一个运行账户及账户组,并在httpd.conf配置

User apache
Group apache

9. 合理控制apache运行账户对磁盘的写入,执行权限

取消apache运行账户对网站目录的写入权限,上传目录除外,其他非网站目录尽量不给权限

10. 合理控制apache运行账户对sh等的执行权限

取消掉了运行账户对sh等的执行权限后能够防止webshell通过默认的sh执行命令

11. 配置http.conf取消对上传目录的php执行权限

<Directory "/var/www/html/aaa">     
    <FilesMatch ".(php|php5)$">     
        Deny from all     
    </FilesMatch> 
</Directory> 

12. 配置http.conf限制禁止访问的文件夹,例如后台目录

<Directory "/var/www/html/aaa">     
        Deny from all     
</Directory> 

13. 配置http.conf限制一些特殊目录的特定ip访问,如内部接口等。

<Directory "/var/www/html/aaa">     
    Order Deny,Allow
    Deny from all
    Allow from 192.168.1.111    
</Directory> 

14. 配置http.conf限制一些文件类型的访问,如txt的日志

<Files ~ ".txt$"> 
    Order allow,deny 
    Deny from all 
</Files> 

15.配置http.conf修改修改监听端口来防止一些内部系统被扫描

这样可以防止一些直接扫描80端口的黑客

Listen 12345 

16. 关闭对.htaccess的支持

AllowOverride All 

改为

AllowOverride None 

17. 配置http.conf记录访问日志

0x04 .htaccess常见配置方法参考


首先,不建议使用.htaccess,其次,使用.htaccess需要在httpd.conf中开启,最后,开始.htaccess支持后需要在httpd.conf中配置防止.htaccess文件被下载,下面介绍几个基本配置方法不全,更多的可以参考其他网站专门针对.htaccess 的配置方法。

1. 定制目录的默认文档

DirectoryIndex index.html index.php index.htm 

2. 定制错误页面

ErrorDocument 404 errors/404.html 

3. 控制访问文件和目录的级别

order deny,allow  
deny from all  
allow from 192.168.0.0/24 

4. 防止列目录

Options -Indexes 

0x05 总结


其实一个web服务器的保护是分几个层次的(暂不考虑程序的漏洞):

1. 隐藏自己

要保护一个web服务器首先得学会隐藏自己,对于一些内部系统,如后台,内部接口等,我们可以通过改端口,限制ip等方式来不让黑客发现。

2. 隐藏身份

对于多数web系统来说,都是提供给外面的访问的,所以想隐藏自己其实是很难的。但是我们还是要学会隐藏身份,可以通过改banner,该返回信息来隐藏身份来加大黑客攻击的难度。

3. 选用安全的版本及修补一些已知的漏洞

其实前面两步都是很容易突破,然后获知一个web系统所使用的web服务器版本的,此时我们能做的就是选择一个少漏洞的版本,及打上安全补丁。

4. 做好安全配置

做好基础的安全配置,禁止目录浏览,设定默认文档,上传目录限制php执行等等,来阻挡黑客的入侵。

5. 合理配置web服务进程账户的权限

当黑客已经通过程序漏洞上传了一个webshell并且已经成功执行了,此时,就只能很好的配置服务进程的账户权限,包括磁盘的读取写入,特殊程序如sh的执行,等等,这样可以讲危害降到最低。

6. 记录日志

最后,当黑客已经光顾之后,我们也只能通过日志来分析,看问题出在哪里了。

转自 http://drops.wooyun.org/运维安全/2727

Nginx/LVS/HAProxy负载均衡软件的优缺点详解

PS:Nginx/LVS/HAProxy是目前使用最广泛的三种负载均衡软件,本人都在多个项目中实施过,参考了一些资料,结合自己的一些使用经验,总结一下。

一般对负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术。具体的应用需求还得具体分析,如果是中小型的Web应用,比如日PV小于1000万,用Nginx就完全可以了;如果机器不少,可以用DNS轮询,LVS所耗费的机器还是比较多的;大型网站或重要的服务,且服务器比较多时,可以考虑用LVS。

一种是通过硬件来进行进行,常见的硬件有比较昂贵的F5和Array等商用的负载均衡器,它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大,所以对于规模较小的网络服务来说暂时还没有需要使用;另外一种就是类似于Nginx/LVS/HAProxy的基于Linux的开源免费的负载均衡软件,这些都是通过软件级别来实现,所以费用非常低廉。

目前关于网站架构一般比较合理流行的架构方案:Web前端采用Nginx/HAProxy+Keepalived作负载均衡器;后端采用MySQL数据库一主多从和读写分离,采用LVS+Keepalived的架构。当然要根据项目具体需求制定方案。
下面说说各自的特点和适用场合。

Nginx的优点是:

1、工作在网络的7层之上,可以针对http应用做一些分流的策略,比如针对域名、目录结构,它的正则规则比HAProxy更为强大和灵活,这也是它目前广泛流行的主要原因之一,Nginx单凭这点可利用的场合就远多于LVS了。
2、Nginx对网络稳定性的依赖非常小,理论上能ping通就就能进行负载功能,这个也是它的优势之一;相反LVS对网络稳定性依赖比较大,这点本人深有体会;
3、Nginx安装和配置比较简单,测试起来比较方便,它基本能把错误用日志打印出来。LVS的配置、测试就要花比较长的时间了,LVS对网络依赖比较大。
3、可以承担高负载压力且稳定,在硬件不差的情况下一般能支撑几万次的并发量,负载度比LVS相对小些。
4、Nginx可以通过端口检测到服务器内部的故障,比如根据服务器处理网页返回的状态码、超时等等,并且会把返回错误的请求重新提交到另一个节点,不过其中缺点就是不支持url来检测。比如用户正在上传一个文件,而处理该上传的节点刚好在上传过程中出现故障,Nginx会把上传切到另一台服务器重新处理,而LVS就直接断掉了,如果是上传一个很大的文件或者很重要的文件的话,用户可能会因此而不满。
5、Nginx不仅仅是一款优秀的负载均衡器/反向代理软件,它同时也是功能强大的Web应用服务器。LNMP也是近几年非常流行的web架构,在高流量的环境中稳定性也很好。
6、Nginx现在作为Web反向加速缓存越来越成熟了,速度比传统的Squid服务器更快,可以考虑用其作为反向代理加速器。
7、Nginx可作为中层反向代理使用,这一层面Nginx基本上无对手,唯一可以对比Nginx的就只有lighttpd了,不过lighttpd目前还没有做到Nginx完全的功能,配置也不那么清晰易读,社区资料也远远没Nginx活跃。
8、Nginx也可作为静态网页和图片服务器,这方面的性能也无对手。还有Nginx社区非常活跃,第三方模块也很多。

Nginx的缺点是:
1、Nginx仅能支持http、https和Email协议,这样就在适用范围上面小些,这个是它的缺点。
2、对后端服务器的健康检查,只支持通过端口来检测,不支持通过url来检测。不支持Session的直接保持,但能通过ip_hash来解决。

LVS:使用Linux内核集群实现一个高性能、高可用的负载均衡服务器,它具有很好的可伸缩性(Scalability)、可靠性(Reliability)和可管理性(Manageability)。

LVS的优点是:
1、抗负载能力强、是工作在网络4层之上仅作分发之用,没有流量的产生,这个特点也决定了它在负载均衡软件里的性能最强的,对内存和cpu资源消耗比较低。
2、配置性比较低,这是一个缺点也是一个优点,因为没有可太多配置的东西,所以并不需要太多接触,大大减少了人为出错的几率。
3、工作稳定,因为其本身抗负载能力很强,自身有完整的双机热备方案,如LVS+Keepalived,不过我们在项目实施中用得最多的还是LVS/DR+Keepalived。
4、无流量,LVS只分发请求,而流量并不从它本身出去,这点保证了均衡器IO的性能不会收到大流量的影响。
5、应用范围比较广,因为LVS工作在4层,所以它几乎可以对所有应用做负载均衡,包括http、数据库、在线聊天室等等。

LVS的缺点是:
1、软件本身不支持正则表达式处理,不能做动静分离;而现在许多网站在这方面都有较强的需求,这个是Nginx/HAProxy+Keepalived的优势所在。
2、如果是网站应用比较庞大的话,LVS/DR+Keepalived实施起来就比较复杂了,特别后面有Windows Server的机器的话,如果实施及配置还有维护过程就比较复杂了,相对而言,Nginx/HAProxy+Keepalived就简单多了。

HAProxy的特点是:
1、HAProxy也是支持虚拟主机的。
2、HAProxy的优点能够补充Nginx的一些缺点,比如支持Session的保持,Cookie的引导;同时支持通过获取指定的url来检测后端服务器的状态。
3、HAProxy跟LVS类似,本身就只是一款负载均衡软件;单纯从效率上来讲HAProxy会比Nginx有更出色的负载均衡速度,在并发处理上也是优于Nginx的。
4、HAProxy支持TCP协议的负载均衡转发,可以对MySQL读进行负载均衡,对后端的MySQL节点进行检测和负载均衡,大家可以用LVS+Keepalived对MySQL主从做负载均衡。
5、HAProxy负载均衡策略非常多,HAProxy的负载均衡算法现在具体有如下8种:
① roundrobin,表示简单的轮询,这个不多说,这个是负载均衡基本都具备的;
② static-rr,表示根据权重,建议关注;
③ leastconn,表示最少连接者先处理,建议关注;
④ source,表示根据请求源IP,这个跟Nginx的IP_hash机制类似,我们用其作为解决session问题的一种方法,建议关注;
⑤ ri,表示根据请求的URI;
⑥ rl_param,表示根据请求的URl参数’balance url_param’ requires an URL parameter name;
⑦ hdr(name),表示根据HTTP请求头来锁定每一次HTTP请求;
⑧ rdp-cookie(name),表示根据据cookie(name)来锁定并哈希每一次TCP请求。

Nginx和LVS对比的总结:
1、Nginx工作在网络的7层,所以它可以针对http应用本身来做分流策略,比如针对域名、目录结构等,相比之下LVS并不具备这样的功能,所以Nginx单凭这点可利用的场合就远多于LVS了;但Nginx有用的这些功能使其可调整度要高于LVS,所以经常要去触碰触碰,触碰多了,人为出问题的几率也就会大。
2、Nginx对网络稳定性的依赖较小,理论上只要ping得通,网页访问正常,Nginx就能连得通,这是Nginx的一大优势!Nginx同时还能区分内外网,如果是同时拥有内外网的节点,就相当于单机拥有了备份线路;LVS就比较依赖于网络环境,目前来看服务器在同一网段内并且LVS使用direct方式分流,效果较能得到保证。另外注意,LVS需要向托管商至少申请多一个ip来做Visual IP,貌似是不能用本身的IP来做VIP的。要做好LVS管理员,确实得跟进学习很多有关网络通信方面的知识,就不再是一个HTTP那么简单了。
3、Nginx安装和配置比较简单,测试起来也很方便,因为它基本能把错误用日志打印出来。LVS的安装和配置、测试就要花比较长的时间了;LVS对网络依赖比较大,很多时候不能配置成功都是因为网络问题而不是配置问题,出了问题要解决也相应的会麻烦得多。
4、Nginx也同样能承受很高负载且稳定,但负载度和稳定度差LVS还有几个等级:Nginx处理所有流量所以受限于机器IO和配置;本身的bug也还是难以避免的。
5、Nginx可以检测到服务器内部的故障,比如根据服务器处理网页返回的状态码、超时等等,并且会把返回错误的请求重新提交到另一个节点。目前LVS中 ldirectd也能支持针对服务器内部的情况来监控,但LVS的原理使其不能重发请求。比如用户正在上传一个文件,而处理该上传的节点刚好在上传过程中出现故障,Nginx会把上传切到另一台服务器重新处理,而LVS就直接断掉了,如果是上传一个很大的文件或者很重要的文件的话,用户可能会因此而恼火。
6、Nginx对请求的异步处理可以帮助节点服务器减轻负载,假如使用apache直接对外服务,那么出现很多的窄带链接时apache服务器将会占用大 量内存而不能释放,使用多一个Nginx做apache代理的话,这些窄带链接会被Nginx挡住,apache上就不会堆积过多的请求,这样就减少了相当多的资源占用。这点使用squid也有相同的作用,即使squid本身配置为不缓存,对apache还是有很大帮助的。
7、Nginx能支持http、https和email(email的功能比较少用),LVS所支持的应用在这点上会比Nginx更多。在使用上,一般最前端所采取的策略应是LVS,也就是DNS的指向应为LVS均衡器,LVS的优点令它非常适合做这个任务。重要的ip地址,最好交由LVS托管,比如数据库的 ip、webservice服务器的ip等等,这些ip地址随着时间推移,使用面会越来越大,如果更换ip则故障会接踵而至。所以将这些重要ip交给 LVS托管是最为稳妥的,这样做的唯一缺点是需要的VIP数量会比较多。Nginx可作为LVS节点机器使用,一是可以利用Nginx的功能,二是可以利用Nginx的性能。当然这一层面也可以直接使用squid,squid的功能方面就比Nginx弱不少了,性能上也有所逊色于Nginx。Nginx也可作为中层代理使用,这一层面Nginx基本上无对手,唯一可以撼动Nginx的就只有lighttpd了,不过lighttpd目前还没有能做到 Nginx完全的功能,配置也不那么清晰易读。另外,中层代理的IP也是重要的,所以中层代理也拥有一个VIP和LVS是最完美的方案了。具体的应用还得具体分析,如果是比较小的网站(日PV小于1000万),用Nginx就完全可以了,如果机器也不少,可以用DNS轮询,LVS所耗费的机器还是比较多的;大型网站或者重要的服务,机器不发愁的时候,要多多考虑利用LVS。

现在对网络负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术:

第一阶段:利用Nginx或HAProxy进行单点的负载均衡,这一阶段服务器规模刚脱离开单服务器、单数据库的模式,需要一定的负载均衡,但是仍然规模较小没有专业的维护团队来进行维护,也没有需要进行大规模的网站部署。这样利用Nginx或HAproxy就是第一选择,此时这些东西上手快, 配置容易,在七层之上利用HTTP协议就可以。这时是第一选择。

第二阶段:随着网络服务进一步扩大,这时单点的Nginx已经不能满足,这时使用LVS或者商用Array就是首要选择,Nginx此时就作为LVS或者Array的节点来使用,具体LVS或Array的是选择是根据公司规模和预算来选择,Array的应用交付功能非常强大,本人在某项目中使用过,性价比也远高于F5,商用首选!但是一般来说这阶段相关人才跟不上业务的提升,所以购买商业负载均衡已经成为了必经之路。

第三阶段:这时网络服务已经成为主流产品,此时随着公司知名度也进一步扩展,相关人才的能力以及数量也随之提升,这时无论从开发适合自身产品的定制,以及降低成本来讲开源的LVS,已经成为首选,这时LVS会成为主流。
最终形成比较理想的基本架构为:Array/LVS — Nginx/Haproxy — Squid/Varnish — AppServer

转自http://www.ha97.com/5646.html

真实的云计算什么样

真实的云计算什么样?

Cloud

云计算对普通用户来说,总是一个云里雾里的话题。本文从最基础的概念开始科普,说明了四个常见的错误理解,和作者的四个猜想。

IaaS(Infrastructure as a Service),指基础设施即服务,消费者通过Internet可以从完善的计算机基础设施获得服务。基于Internet的服务(如存储和数据库)是IaaS的一部分。Internet上其他类型的服务包括平台即服务(Platform as a Service,PaaS)和软件即服务(Software as a Service,SaaS)。PaaS提供了用户可以访问的完整或部分的应用程序开发,SaaS则提供了完整的可直接使用的应用程序,比如通过Internet管理企业资源。

误解一:IaaS就是卖资源

现在流行的一个观点:IaaS就是卖资源,传统IDC是卖带宽和机架,云计算加上服务器,最多就是把这些资源通过虚拟化技术拆成散了零卖。

在我们看来,云计算分为3个层次:

1、 资源层:这是IaaS提供服务的物理基础,主要包括计算资源、存储资源和网络资源,以及必要的电力资源、IP资源等。这一层主要通过规模采购和资源复用的模式来赚钱利润,利润不高。

2、 产品层:这是IaaS的核心,IaaS运营商根据客户的各种不同需求,在资源层的基础上,开发出各种各样的产品。比如存储产品、消息产品、CDN(内容分发网络)产品、监控产品,而每一种产品又会根据场景和需求的不一样,做针对性的改造优化,形成特定类型的产品。产品层是不同IaaS的竞争力体现之处,这些产品在不同角度满足了用户的不同需求。这些产品是IaaS利润的主要来源,也是IaaS的重要黏性。像国内的阿里云就提供了云服务器和负载均衡、云监控等产品,Ucloud提供了块设备存储的UDisk、云数据库的UDB等产品。

3、 服务层:在产品层之上,IaaS运营商还会根据用户的需求提供一些更多的增值服务,这部分从商业角度不一定赚钱,但却是用户使用IaaS的重要条件。比如为用户提供数据快递服务,在中国则必须包含网站备案服务,还有安全服务等等。

误解二:IaaS没有什么技术含量

在各种媒体的宣传把云计算神话了,认为云计算无所不能,把云计算的技术看的很高端,技术含量特别特别高。而不少从事过技术的人呢,则认为云计算没有什么技术含量,已经有类似OpenstackEucalyptuscloudstack等不少开源系统可以直接部署使用,或者基于KVM、XEN等开源虚拟化系统上做一套管理系统。

的确,随着云计算的快速发展,已经涌现出一大批开源的云计算平台,各大公司也都在积极支持开源软件的发展。但是即使发展快如Openstack,目前也没有很成熟的成功案例,因为IaaS的技术复杂度很高。

1、从基础上看,IaaS要实现多租户,弹性,稳定可靠和安全,必须要进行资源的池化管理,也就是把资源通过虚拟化技术形成资源池,然后根据用户的需求弹性分配,同时确保安全和隔离。之前提到资源主要包括计算、存储和网络,因此这里要做计算的虚拟化、存储的虚拟化和网络的虚拟化。

计算的虚拟化目前主要是通过XEN、KVM、Vmware等软件实现,相对比较成熟,但是在性能优化、稳定性方面还有很多工作需要完善。

存储的虚拟化目前还没有一个比较成熟的开源系统,如果文件型存储,则主要根据GFS的思路进行编码实现,必然Openstack的swift,而块设备存储则各显神通了,有nova-volume,国内盛大云、UCloud都各自实现了块设备存储。另外最近国际上非常流行的是SDS(软件定义存储),实际上也是实现了存储的虚拟化。

2、在虚拟化管理之上,是大规模的调度管理,如何能快速找到合适的资源满足用户的需求,如何能根据监测的数据,动态调整资源,如何能动态迁移业务,如何防止雪崩。如果是10台机器,这可能很容易,如果是1000台机器,这是一个问题,如果是10000台以上的机器,那就是个大挑战了。而云计算,要实现解决规模化的能力,就必须解决大规模的调度问题。这里的难度和挑战相当的大。

3、性能和安全问题同样也是IaaS的挑战,如何确保一个用户的高需求不影响其他用户,如何防范一个租户入侵其他租户,如何防止一个用户被攻击不影响其他用户,这里需要我们更加深入的研究。

更多的产品研发,如上所说,IaaS除了资源之外,更关键的是产品,必须根据用户的需求研发出更多满足特定需求的产品。这就会涉及到系统、网络、数据库、应用和安全的方方面面,对IaaS开发和运维的要求都非常高。

综上所述,IaaS的技术门槛是比较高的,并不是没有技术含量。

误解三:IaaS是不安全的

业界都在质疑云计算的安全性,特别是Evernote的安全事故让更多人担心IaaS的安全问题。

以我十多年的安全从业经验来看:

1、 没有绝对的安全,任何系统都有可能会被入侵;

2、 安全是相对的,关键要看IaaS模式下和传统托管模式下哪种更安全。因此假设一个公司规模很大,有专业的安全团队,比如腾讯、阿里、百度等公司,则肯定他们自己部署会安全很多,但是如果假设是一个小的创业公司,不可能有很专业的安全人员,IaaS的服务提供商则可以更专业的提供安全保障。

误解四:公有云只能服务中小企业

由于大企业对稳定性的追求,以及对旧有投资的保护,的确公有云的用户大部分都是从小企业开始的。目前不管是国内还是国外,中小企业还是云计算的主要用户。

但是随着云计算的发展,我们也发现了几个趋势:

1、一些在公有云上成长起来的公司,长成大型企业后也依然在使用公有云,比如Netflex,因为他们发现如果自己要建立基础架构所需要的人力物力依然很大,困难依旧很多,还不如将精力投入在他们自己擅长的领域内。

2、传统的一些大公司,他们也逐步开始尝试将一些非核心业务或者新业务部署在公有云上,甚至将IT部门裁员,全部转移到公有云平台。比如兰博基尼、宝马等汽车公司,他们已经借助云计算来降低成本,借助云计算提高他们的设计渲染能力。

其实从电力发展的情况来看也是这样的,在现代这样的社会,我们很少看到有企业会自己建立发电厂,而不使用电网。相信随着云计算的发展,云计算取代IDC或者取代自己运营也是必然的趋势。

四个猜想:

一、IaaS增长快速

IaaS公共云服务将是增长最快的公共云服务类别。预计全球2013年IaaS的市场规模将达到80亿美元,其中AWS(amazon web services,亚马逊公有云服务)预计能达到25-28亿美元,Rackspace收入16-19亿左右,IaaS占35%,超过6亿美元,而被Verizon收购的Terremark收入将超过4.5亿以上,另外像Joyent,Savvis,GoGrid,Dimension Data等公司都会有一定的收入增长。

相比全球,中国的IaaS市场基数小,但增长速度更快,预计13年中国纯粹IaaS市场规模将会超过1亿美元,并逐步形成3-4家规模比较大的IaaS运营商。

二、大中型企业将开始接受云计算

正如上面所说,大中型企业已经开始尝试将一些非核心业务部署在公有云上。从AWS的客户列表中,我们可以看到财富500强企业或多或少都在使用亚马逊的公有云进行测试或者开发,其中有些公司在上面运行真正的应用,比如纳斯达克,兰博基尼等公司。

这种变化将会对传统的IT厂商,IBM、HP、Oracle产生很大的威胁,因为传统大中型企业是这些IT厂商的大客户。

而从AWS的发展来看,这也必然是云计算公司的发展目标,我相信在未来的3-5年内,云计算将会开始蚕食传统IT厂商的市场,而2013年就是一个开始。

三、SDX技术(软件定义一切)将会快速发展

传统的硬件厂商采用卖盒子的模式,设备是不开放,无法动态管理的,因此造成了很大的浪费和管理成本。

而软件定义的思想(Software Defined Everything)将黑盒子开放出来,使得数据和控制分开,能够更灵活的管理和调度,会成为后续发展的主流。

2013年的开始,我们就看到了软件定义存储(Software Defined Storage),软件定义网络(Software Defined Network),软件定义数据中心(Software Defined Datacenter)等一系列大的投资和收购行为。

我预计在2013年,SDS、SDN的产品和方案将会开始落地,相关的技术将会快速发展。

四、云计算改变相关产业链

随着云计算技术的发展,特别是应用的不断落地,云计算已经在很多行业发生了影响和变革,主要包括:

1、创业者:云计算极大地降低了创业者的基础设施门槛,使得创业者只需要关注他们的核心优势,发挥他们的核心优势。这对于一些原来不从事互联网的团队非常方便利用互联网创业,将会催生很多内容型、O2O型的创业公司。特别是2013年,国家降低注册公司的门槛后,越来越多的创业公司将会成批出现。

2、投资行业:由于云计算降低了一次性的服务器网络投入,使得创业者对天使的资金需求降低,可以很迅速的开发产品试水。如果产品好,则利用云计算可以快速成长,如果产品不好,则可以马上转行。因此投资的模式从传统的天使转向超天使,甚至可能不需要A轮,业务发展好就可以直接进入B轮。

3、服务器产业:传统模式下,服务器通过渠道销售给中小企业,渠道会是其中很重要的一环。在云计算模式下,中小企业将不用采购服务器。因此IaaS运营商将取代中小企业成为服务器的采购者,这对传统的服务器厂商和渠道产生较大的影响。

转自:http://tech.sina.com.cn/it/csj/2013-03-18/10238156116.shtml

在服务器上排除问题的头五分钟

  我们团队为上一家公司承担运维、优化和扩展工作的时候,我们碰到了各种不同规模的性能很差的系统和基础设备(大型系统居多,比如 CNN 或者世界银行的系统)。要是再赶上修复时间紧、奇葩的技术平台、缺少信息和文档,基本上这过程都会惨痛到让我们留下深刻的记忆。

遇到服务器故障,问题出现的原因很少可以一下就想到。我们基本上都会从以下步骤入手:

一、尽可能搞清楚问题的前因后果

不要一下子就扎到服务器前面,你需要先搞明白对这台服务器有多少已知的情况,还有故障的具体情况。不然你很可能就是在无的放矢。

必须搞清楚的问题有:

  • 故障的表现是什么?无响应?报错?
  • 故障是什么时候发现的?
  • 故障是否可重现?
  • 有没有出现的规律(比如每小时出现一次)
  • 最后一次对整个平台进行更新的内容是什么(代码、服务器等)?
  • 故障影响的特定用户群是什么样的(已登录的, 退出的, 某个地域的…)?
  • 基础架构(物理的、逻辑的)的文档是否能找到?
  • 是否有监控平台可用? (比如 Munin、Zabbix、 Nagios、 New Relic… 什么都可以)
  • 是否有日志可以查看?. (比如 Loggly、Airbrake、 Graylog…)

最后两个是最方便的信息来源,不过别抱太大希望,基本上它们都不会有。只能再继续摸索了。

 

二、有谁在?

用这两个命令看看都有谁在线,有哪些用户访问过。这不是什么关键步骤,不过最好别在其他用户正干活的时候来调试系统。有道是一山不容二虎嘛。(ne cook in the kitchen is enough.)

  三、之前发生了什么?

查看一下之前服务器上执行过的命令。看一下总是没错的,加上前面看的谁登录过的信息,应该有点用。另外作为 admin 要注意,不要利用自己的权限去侵犯别人的隐私哦。

到这里先提醒一下,等会你可能会需要更新 HISTTIMEFORMAT 环境变量来显示这些命令被执行的时间。对要不然光看到一堆不知道啥时候执行的命令,同样会令人抓狂的。

四、现在在运行的进程是啥?

这都是查看现有进程的。 ps aux 的结果比较杂乱, pstree -a 的结果比较简单明了,可以看到正在运行的进程及相关用户。

  五、监听的网络服务

$ netstat -ntlp
$ netstat -nulp
$ netstat -nxlp

我一般都分开运行这三个命令,不想一下子看到列出一大堆所有的服务。netstat -nalp 倒也可以。不过我绝不会用 numeric 选项 (鄙人一点浅薄的看法:IP 地址看起来更方便)。

找到所有正在运行的服务,检查它们是否应该运行。查看各个监听端口。在 netstat 显示的服务列表中的 PID 和 ps aux 进程列表中的是一样的。

如果服务器上有好几个 Java 或者 Erlang 什么的进程在同时运行,能够按 PID 分别找到每个进程就很重要了。

通常我们建议每台服务器上运行的服务少一点,必要时可以增加服务器。如果你看到一台服务器上有三四十个监听端口开着,那还是做个记录,回头有空的时候清理一下,重新组织一下服务器。

六、CPU 和内存

$ free -m
$ uptime
$ top
$ htop

注意以下问题:

  • 还有空余的内存吗? 服务器是否正在内存和硬盘之间进行 swap?
  • 还有剩余的 CPU 吗? 服务器是几核的? 是否有某些 CPU 核负载过多了?
  • 服务器最大的负载来自什么地方? 平均负载是多少?

七、硬件

$ lspci
$ dmidecode
$ ethtool

有很多服务器还是裸机状态,可以看一下:

  • 找到 RAID 卡 (是否带 BBU 备用电池?)、 CPU、空余的内存插槽。根据这些情况可以大致了解硬件问题的来源和性能改进的办法。
  • 网卡是否设置好? 是否正运行在半双工状态? 速度是 10MBps? 有没有 TX/RX 报错?

八、IO 性能

$ iostat -kx 2
$ vmstat 2 10
$ mpstat 2 10
$ dstat --top-io --top-bio

这些命令对于调试后端性能非常有用。

  • 检查磁盘使用量:服务器硬盘是否已满?
  • 是否开启了 swap 交换模式 (si/so)?
  • CPU 被谁占用:系统进程? 用户进程? 虚拟机?
  • dstat 是我的最爱。用它可以看到谁在进行 IO: 是不是 MySQL 吃掉了所有的系统资源? 还是你的 PHP 进程?

九、挂载点和文件系统

$ mount
$ cat /etc/fstab
$ vgs
$ pvs
$ lvs
$ df -h
$ lsof +D / /* beware not to kill your box */
  • 一共挂载了多少文件系统?
  • 有没有某个服务专用的文件系统? (比如 MySQL?)
  • 文件系统的挂载选项是什么: noatime? default? 有没有文件系统被重新挂载为只读模式了?
  • 磁盘空间是否还有剩余?
  • 是否有大文件被删除但没有清空?
  • 如果磁盘空间有问题,你是否还有空间来扩展一个分区?

十、内核、中断和网络

$ sysctl -a | grep ...
$ cat /proc/interrupts
$ cat /proc/net/ip_conntrack /* may take some time on busy servers */
$ netstat
$ ss -s
  • 你的中断请求是否是均衡地分配给 CPU 处理,还是会有某个 CPU 的核因为大量的网络中断请求或者 RAID 请求而过载了?
  • SWAP 交换的设置是什么?对于工作站来说 swappinness 设为 60 就很好, 不过对于服务器就太糟了:你最好永远不要让服务器做 SWAP 交换,不然对磁盘的读写会锁死 SWAP 进程。
  • conntrack_max 是否设的足够大,能应付你服务器的流量?
  • 在不同状态下(TIME_WAIT, …) TCP 连接时间的设置是怎样的?
  • 如果要显示所有存在的连接,netstat 会比较慢, 你可以先用 ss 看一下总体情况。

你还可以看一下 Linux TCP tuning 了解网络性能调优的一些要点。

十一、系统日志和内核消息

$ dmesg
$ less /var/log/messages
$ less /var/log/secure
$ less /var/log/auth
  • 查看错误和警告消息,比如看看是不是很多关于连接数过多导致?
  • 看看是否有硬件错误或文件系统错误?
  • 分析是否能将这些错误事件和前面发现的疑点进行时间上的比对。

十二、定时任务

$ ls /etc/cron* + cat
$ for user in $(cat /etc/passwd | cut -f1 -d:); do crontab -l -u $user; done
  • 是否有某个定时任务运行过于频繁?
  • 是否有些用户提交了隐藏的定时任务?
  • 在出现故障的时候,是否正好有某个备份任务在执行?

十三、应用系统日志

这里边可分析的东西就多了, 不过恐怕你作为运维人员是没功夫去仔细研究它的。关注那些明显的问题,比如在一个典型的 LAMP(Linux+Apache+Mysql+Perl)应用环境里:

  • Apache & Nginx; 查找访问和错误日志, 直接找 5xx 错误, 再看看是否有 limit_zone 错误。
  • MySQL; 在mysql.log 找错误消息,看看有没有结构损坏的表, 是否有 innodb 修复进程在运行,是否有 disk/index/query 问题.
  • PHP-FPM; 如果设定了 php-slow 日志, 直接找错误信息 (php, mysql, memcache, …),如果没设定,赶紧设定。
  • Varnishvarnishlog 和 varnishstat 里, 检查 hit/miss 比. 看看配置信息里是否遗漏了什么规则,使最终用户可以直接攻击你的后端?
  • HA-Proxy; 后端的状况如何?健康状况检查是否成功?是前端还是后端的队列大小达到最大值了?

  结论

经过这 5 分钟之后,你应该对如下情况比较清楚了:

  • 在服务器上运行的都是些啥?
  • 这个故障看起来是和 IO/硬件/网络或者系统配置 (有问题的代码、系统内核调优, …)相关。
  • 这个故障是否有你熟悉的一些特征?比如对数据库索引使用不当,或者太多的 apache 后台进程。

你甚至有可能找到真正的故障源头。就算还没有找到,搞清楚了上面这些情况之后,你现在也具备了深挖下去的条件。继续努力吧!

转自 http://news.cnblogs.com/n/173803/

sqlite表结构和数据的导出

全部导出

sqlite3 data.db
>.output dd.sql
>.dump

全部导入
sqlite3 mydb.db
>.read dd.sql

平时使用官方提供的sqlite3.exe工具来操作 sqlite的数据库
进入管理:
sqlite3.exe d:\test.db //假设数据是 d:\test.db
>.databases //显示所有数据库 和 mysql的 show databases;
>.tables //显示当前数据库的表格 和 mysql 的show tables;
>.schment tablename;  //显示表格结构 和mysql的 SHOW Create TABLE tbl_name
>.output c:\\1.sql  //导出当前数据库的 sql语句 和mysql的 mysqldump
>.dump
>.import c:\\1.sql //导入 //mysql 用source
===================
导入
命令: .import
sqlite> .import 文件名 表名
注1: 不要忘了开头的点
注2: 这条语句不能用分号结束. 非SQL不需要分号结束.
注3: 需要查看默认的分隔符separator. 必须一致. 如果不一致可能导致sqlite字段分割错误.
查看分隔符使用命令  .show , 如果不一致可直接修改, 比如:
sqlite>.separator “,”
将分隔符转为逗号.
举例1:
将文件a.csv中的数据导入表 tab_xx. (a.csv中字段以逗号分割)
sqlite> .separator “,”
sqlite> .import a.csv tab_xx
sqlite>
导入结束.

导出
实现方式: 将输出重定向至文件.
命令: .output
sqlite> .output a.txt
然后输入sql语句, 查询出要导的数据. 查询后,数据不会显示在屏幕上,而直接写入文件.
结束后,输入
sqlite> .output stdout
将输出重定向至屏幕.
举例2:
将 tab_xx 中的数据导出到文件a.txt
sqlite> .output a.txt
sqlite> select * from tab_xx;
sqlite> .output stdout
导出完毕.

转自  http://javachs.iteye.com/blog/649538