本帖最后由 buptdream 于 2012-11-7 10:58 编辑
1.怎样强制主服务器阻塞更新直到从服务器同步?
复制是将主数据库的DML 操作通过日志传到从服务器上,使得从服务器实现了对主服务器的远程备份,并且可以通过应用使得在主服务器繁忙的时候分担一部分负载。mysql 支持同时向多台从服务器进行复制。 缺点:不能保证主从同步,只能实现异步复制。 在复制的过程中,需要经常查看slave状态 mysql> SHOW SLAVE STATUS\G; Slave_IO_Running: Yes Slave_SQL_Running: Yes 1 row in set (0.00 sec) 主要检查Slave_IO_Running 和Slave_SQL_Running 这两个进程状态是否是yes,这两个进程的含义如下: Slave_IO_Running:此进程负责slave 从master 服务器上读取binlog 日志,并写入 slave 服务器上的中继日志中 Slave_SQL_Running:此进程负责读取并且执行中继日志中的binlog 日志 只要其中有一个进程的状态是no,则表示复制进程停止,错误原因可以从Last_Errno后面看到。 如果两边不一致的情况下,可以先关闭掉主服务器产生日志到从服务器上,具体的操作步骤如下:
1. 在主服务器上,执行这些语句:
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;
记录SHOW 语句的输出的日志名和偏移量。这些是复制坐标。
2. 在从服务器上,发出下面的语句,其中Master_POS_WAIT()函数的参量是前面步骤中
的得到的复制坐标值:
mysql> SELECT MASTER_POS_WAIT('log_name', log_offset);
SELECT 语句阻塞直到从服务器达到指定的日志文件和偏移量。此时,从服务器与主服
务器同步,语句返回。
3. 在主服务器上,发出下面的语句允许主服务器重新开始处理更新:
mysql> UNLOCK TABLES;
在这个过程中,可以查看SHOW SLAVE STATUS 语句的Seconds_Behind_Master 列的结果。
2.MySQL复制能够何时和多大程度提高系统性能?
我们可以通过mysql复制来提高系统的性能,应将一个服务器设置为主服务器并且将所有写指向该服务器。然后根据预算配置尽可能多的从服务器以及栈空间,并且在主服务器和从服务器之间分发读取操作。可以用--skip-innodb、--skip-bdb、--low-priority-updates以及--delay-key-write=ALL选项启动从服务器,以便在从服务器端提高速度。在这种情况下,为了提高速度,从服务器使用非事务MyISAM表来代替InnoDB和BDB表。
为了使用高性能的复制,可以使用replace工具自动进行转换,该工具随标准MySQL一起发布,或可以自己编写转换脚本。理想情况,代码使用一致的程序转换风格。
MySQL复制对于频繁读和频繁写的系统具有最大好处。理论上,通过使用单个主服务器/多从服务器设置,可以通过添加更多的从服务器来扩充系统,直到用完网络带宽,或者你的更新负载已经增长到主服务器不能处理的点。
在获得的收益开始吃平之前,为了确定可以有多少从服务器,以及可以将你的站点的性能提高多少,需要知道查询模式,并且要通过基准测试并根据经验确定一个典型的主服务器和从服务器中的读取(每秒钟读取量,或者max_reads)吞吐量和写(max_writes)吞吐量的关系。通过一个假设的带有复制的系统,我们给出了一个非常简单的计算结果。
假设系统负载包括10%的写和90%的读取,并且我们通过基准测试确定max_reads是1200 –2 × max_writes。换句话说,如果没有写操作,系统每秒可以进行1,200次读取操作,平均写操作是平均读操作所用时间的两倍,并且关系是线性的。我们假定主服务器和每个从服务器具有相同的性能,并且我们有一个主服务器和N个从服务器。那么,对于每个服务器(主服务器或从服务器),我们有:
reads = 1200 – 2 × writes
reads = 9 × writes / (N + 1) (读取是分离的, 但是写入所有服务器)
9 × writes / (N + 1) + 2 × writes = 1200
writes = 1200 / (2 + 9/(N+1))
最后的等式表明了N个从服务器的最大写操作数,假设最大可能的读取速率是每分钟1,200次,读操作与写操作的比率是9。
如上分析可以得到下面的结论:
如果N = 0(这表明没有复制),系统每秒可以处理大约1200/11 = 109个写操作。
如果N = 1,每秒得到184个写操作。
如果N = 8,每秒得到400个写操作。
如果N = 17,每秒得到480个写操作。
最后,当 N 趋于无穷大(以及我们预算的负无穷大)时,可以得到非常接近每秒600个写操作,系统吞吐量增加将近5.5倍。然而,如果只用8个服务器,增加接近4倍。
请注意,这些计算假设网络带宽无穷大并忽略掉了其它一些因素,那些因素可能对系统产生重要的影响。在许多情况下,不能执行与刚才类似的计算,即如果添加N台复制从服务器,应该准确预报系统将发生哪些影响。回答下面的问题应能够帮助你确定复制是否和在多大程度上能够提高系统的性能:
1:系统上的读取/写比例是什么?
2:如果减少读取操作,一个服务器可以多处理多少写负载?
3:网络带宽可满足多少从服务器的需求?
3.如何使用复制来提供冗余/高可用性?
利用目前的可用特性,必须设置一个主服务器和一个从服务器(或多个从服务器),以及写一个脚本来监视主服务器是否启动。如果主服务器失败,通知应用程序和从服务器切换主服务器。下面是一些建议:
1:告知从服务器更改其主服务器,使用CHANGE MASTER TO语句。
2:通知应用程序主服务器位置的一个很好的方法是对主服务器提供动态DNS入口。用bind可以使用nsupdate动态更新DNS。
3:应该用--logs-bin选项而不用 --logs-slave-updates选项运行从服务器。这样,一旦你在其它从服务器上发出STOP SLAVE; RESET MASTER, 以及CHANGE MASTER TO语句,该从服务器可以切换为主服务器。
下面通过例子来说明一下:
Master代表主服务器,Slave代表从服务器,用户代表发出数据库写和读取操作的客户;只发出数据库读取操作的客户没有给出,因为它们不需要切换。Slave1、Slave2以及Slave3是从服务器,用--logs-bin选项而没有用--logs-slave-updates运行。因为从服务器收到的主服务器的更新没有记录在二进制日志中,除非指定 --logs-slave-updates选项,每个从服务器上的二进制日志是空的。如果因为某些原因M 变得不可用,你可以选取一个从服务器变为新的主服务器。例如,如果你选取了Slave1,所有用户应该重新指向Slave1和Slave2,并且Slave3然后应从S1复制。
确保所有从服务器已经处理了中继日志中的所有语句。在每个从服务器上,发出STOP SLAVE IO_THREAD语句,然后检查SHOW PROCESSLIST语句的输出,直到你看到Has read all relay log。当所有从服务器都执行完这些,它们可以被重新配置为一个新的设置。在被提升为主服务器的从服务器Slave1上,发出STOP SLAVE和RESET MASTER语句。
在其它从服务器Slave2和Slave3上,使用STOP SLAVE和CHANGE MASTER TO MASTER_HOST='S1'(其中'S1'表示S1实际的主机名)。为CHANGE MASTER添加关于从Slave2或Slave3如何连接到Slave1的所有信息(user、password、port)。在CHANGE MASTER命令中,不需要指定从其读取的Slave1的二进制日志名或二进制日志位置:我们知道它是第1个二进制日志,位置是4,这是CHANGE MASTER命令的默认值。最后,在Slave2和Slave3上使用START SLAVE 命令。
然后,指示所有用户 把它们的语句指向Slave1。此后用户发出的所有发送到Slave1的更新语句被写入Slave1 二进制日志,Slave1则包含Master死掉之后的发送到 Slave1的每一个更新语句。
结果是下面的配置:
当 Master重新启动后,你必须在Master上发出相同的CHANGE MASTER语句,与在Slave2和Slave3上发出的语句一样,以便Master变为Slave1的从服务器并且恢复在它宕机后丢失的所有用户写操作。要把 Master 再次作为主服务器(例如,因为它是功能最强的机器),使用前面的步骤,好像Slave1不可用并且Master变为一个新的主服务器一样。在这个过程中,在Slave1、Slave2以及Slave3作为Mster的从服务器之前,不要忘记在Master上运行RESET MASTER。否则,它们可能拾取Master变得不可用之前的旧用户写操作。
目前正在MySQL集成自动主服务器选择系统,但在准备好之前,你必须创建自己的监控工具。
|