mysql高可用corosync+pacemaker+drbd
1,安装drbd
drbd共有两部分组成:内核模块和用户空间的管理工具。其中drbd内核模块代码已经整合进Linux内核2.6.33以后的版本中,因此,如果您的内核版本高于此版本的话,你只需要安装管理工具即可;否则,您需要同时安装内核模块和管理工具两个软件包,并且此两者的版本号一定要保持对应。
目前适用CentOS 5的drbd版本主要有8.0、8.2、8.3三个版本,其对应的rpm包的名字分别为drbd, drbd82和drbd83,对应的内核模块的名字分别为kmod-drbd, kmod-drbd82和kmod-drbd83。而适用于CentOS 6的版本为8.4,其对应的rpm包为drbd和drbd-kmdl,但在实际选用时,要切记两点:drbd和drbd-kmdl的版本要对应;另一个是drbd-kmdl的版本要与当前系统的内容版本相对应。各版本的功能和配置等略有差异;我们实验所用的平台为x86_64且系统为CentOS 6.5,因此需要同时安装内核模块和管理工具。我们这里选用最新的8.4的版本(drbd-8.4.3-33.el6.x86_64.rpm和drbd-kmdl-2.6.32-431.el6-8.4.3-33.el6.x86_64.rpm),下载地址为ftp://rpmfind.net/linux/atrpms/,请按照需要下载。
查看当前系统内核版本号
# uname -r
确保drbd版本和内核版本一样
安装drbd
# yum -y install drbd-8.4.3-33.el6.x86_64.rpm drbd-kmdl-2.6.32-358.el6-8.4.3-33.el6.x86_64.rpm
创建一个分区
# fdisk /dev/sda
在另外一个节点上面执行相同的操作,请确保使用了相同大小的分区。
配置DRBD
1,配置/etc/drbd.d/global-common.conf
global {
usage-count no;
# minor-count dialog-refresh disable-ip-verification
}
common {
protocol C;
handlers {
pri-on-incon-degr "/usr/lib/drbd/notify-pri-on-incon-degr.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
pri-lost-after-sb "/usr/lib/drbd/notify-pri-lost-after-sb.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
local-io-error "/usr/lib/drbd/notify-io-error.sh; /usr/lib/drbd/notify-emergency-shutdown.sh; echo o > /proc/sysrq-trigger ; halt -f";
# fence-peer "/usr/lib/drbd/crm-fence-peer.sh";
# split-brain "/usr/lib/drbd/notify-split-brain.sh root";
# out-of-sync "/usr/lib/drbd/notify-out-of-sync.sh root";
# before-resync-target "/usr/lib/drbd/snapshot-resync-target-lvm.sh -p 15 -- -c 16k";
# after-resync-target /usr/lib/drbd/unsnapshot-resync-target-lvm.sh;
}
startup {
#wfc-timeout 120;
#degr-wfc-timeout 120;
}
disk {
on-io-error detach;
#fencing resource-only;
}
net {
protocol C;
cram-hmac-alg "sha1";
shared-secret "redhat";
}
syncer {
rate 1000M;
}
}
2、定义一个资源/etc/drbd.d/web.res,内容如下:
resource sqldrbd {
on node1.xy.com {
device /dev/drbd0;
disk /dev/sda;
address 192.168.100.25:7789;
meta-disk internal;
}
on node2.xy.com {
device /dev/drbd0;
disk /dev/sda;
address 192.168.100.26:7789;
meta-disk internal;
}
}
以上文件在两个节点上必须相同,因此,可以基于ssh将刚才配置的文件全部同步至另外一个节点。
# scp /etc/drbd.d/* node2:/etc/drbd.d/
3、在两个节点上初始化已定义的资源并启动服务:
1)初始化资源,在Node1和Node2上分别执行:
# drbdadm create-md sqldrbd
2)启动服务,在Node1和Node2上分别执行:
/etc/init.d/drbd start
3)查看启动状态:
[root@node2 ~]# cat /proc/drbd
version: 8.4.3 (api:1/proto:86-101)
GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by gardner@, 2013-11-29 12:28:00
0: cs:Connected ro:Secondary/Secondary ds:Inconsistent/Inconsistent C r-----
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:524236
将其中一个节点设置为Primary。在要设置为Primary的节点上执行如下命令:
# drbdadm primary --force sqldrbd
[root@localhost drbd.d]# cat /proc/drbd
version: 8.4.3 (api:1/proto:86-101)
GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by gardner@, 2013-05-27 04:30:21
0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
ns:524236 nr:0 dw:0 dr:524908 al:0 bm:32 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
4、创建文件系统
文件系统的挂载只能在Primary节点进行,因此,也只有在设置了主节点后才能对drbd设备进行格式化
# mke2fs -t ext4 /dev/drbd0
# mkdir /mnt/drbd
# mount /dev/drbd0 /mnt/drbd
5,管理drbd主从切换
1,先在主的上卸载,然后把主的变成从的
# umount /mnt/drbd
# drbdadm secondary all
2,把从的提升为主的
# drbdadm primary all
查看是否改变成功
[root@node2 ~]# cat /proc/drbd
version: 8.4.3 (api:1/proto:86-101)
GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by gardner@, 2013-11-29 12:28:00
0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
ns:0 nr:549321 dw:549321 dr:672 al:0 bm:32 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
ro:Primary/Secondary :primary在前面说明当前主机是主的
现在就可以挂载使用了
# mkdir /mnt/drbd
# mount /dev/drbd0 /mnt/drbd
安装mysql
# yum -y install mysql
修改配置文件确保两个配置文件一样
datadir = /mnt/drbd/mysql
准备datadir
[root@node1 drbd]# mkdir mysql
root@node1 drbd]# chown mysql.mysql mysql -R
配置mysql高可用
安装corosync,pacemaker
# yum -y install corosync pacemaker
配置corosync
# vim /etc/corosync/corosync.conf
totem {
version: 2
secauth: on
threads: 0
interface {
ringnumber: 0
bindnetaddr: 192.168.100.0
mcastaddr: 226.94.1.100
mcastport: 5405
ttl: 1
}
}
service {
ver: 0
name: pacemaker
}
aisexec {
user: root
group: root
}
其他保持不变
# vim /etc/hosts
192.168.100.25 node1.xy.com node1
192.168.100.26 node2.xy.com node2
# scp authkey corosync.conf /etc/hosts node1:/etc/corosync/
安装crmsh
# yum -y install crmsh-1.2.6-4.el6.x86_64.rpm pssh-2.3.1-2.el6.x86_64.rpm
定义资源
1,定义drbd为主资源,再定义为主从资源
2,定义mysql服务,定义mysql的vip
3,定义mysql的datadir
4,把以上资源定义在一起
5,定义启动顺序,先把drbd提升为主的,在挂载文件系统,在启动mysqlvip,最后启动mysql
crm(live)configure# property no-quorum-policy=ignore
crm(live)configure# rsc_defaults resource-stickiness=100
crm(live)configure# property stonith-enabled=false
crm(live)configure# primitive mysqld lsb:mysqld op monitor interval=30s timeout=40s on-fail=restart
crm(live)configure# location mysqld_node1 mysqld inf: node1.xy.com
crm(live)configure# primitive mysqlvip ocf:heartbeat:IPaddr2 params ip=192.168.100.90 cidr_netmask=24 op monitor interval=30s timeout=30s on-fail=restart
crm(live)configure# primitive mysqldir ocf:heartbeat:Filesystem params device="/dev/drbd0" directory="/mnt/drbd" fstype="ext4" op monitor interval=60s timeout=60s op start timeout=60s op stop timeout=60s on-fail=restart
crm(live)configure# primitive drbd0 ocf:linbit:drbd params drbd_resource=sqldrbd op monitor role=Master interval=30s timeout=20s op monitor role=Slave interval=60s timeout=60s op start timeout=240s op stop timeout=100s
crm(live)configure# master ms_drbd drbd0 meta master-max=1 master-node-max=1 clone-max=2 clone-node-max=1 notify=true
crm(live)configure# order mysqldir_after_mysql_drbd inf: ms_drbd:promote mysql
crm(live)configure# order mysqldir_after_mysql_drbd inf: ms_drbd:promote mysqldir:start
crm(live)configure# colocation mysqldir_drbd inf: mysqldir ms_drbd:Master
crm(live)configure# colocation mysql_res inf: mysqlvip mysqld mysqldir
crm(live)configure# verify
crm(live)configure# commit
当node1下线时
当node1上线时
LAMP降级高可用,就当备份数据
mysql参数
1,slow_query_log=YES/NO
用于记录慢查日志的记录可结合explain查看语句执行过程,找出问题,优化查询语句,或者优化
表(表拆分,减少数据冗余),建立合适的索引提高查询效率
skip-name-resolve禁用DNS解析,网络最慢的就是DNS
table_cache = # 表缓存大小,缓存打开过的表,可结合open_tables,opened_tables的值是否调大
thead_cache_size = # 缓存连接线程的个数,可以让mysql不用经常为每个连接创建线程
可查看connections和therads_created状态变量确定,增大可提升性能
query_cache_size = # 查询缓存大小,可根据需要决定是否要开启查询缓存,如果缓存命中率过低
禁用缓存可提升性能,因为,查询要先找缓存,没有就读磁盘,然后先缓存
再才取的数据,多了好几个步骤
max_connections = # 最大连接进程数
tmp_table_size = # 临时表大小,如果超过临时表会写入磁盘
qcache_lownmem_prunes 是一个状态变量,如果过大表示query_cache_size可能过小,缓存经常置换
query_free_blocks 状态变量,如果过大表示缓存碎片过多,可用flush query cache进行碎片整理
参数优化并不能带来性能的很大提升,除非以前设置的很不合理,要从本身的数据结构,架构结构
硬件,业务多方面考虑,结合内核参数。
以下来自http://mageedu.blog.51cto.com/4265610/1062628
2,innodb_buffer_pool_instances=#
设定将InnoDB的buffer pool分隔为多少个区域。对于有着数GB空间的buffer pool来说,将其分隔为多个区域可以降低不同的线程对缓存页面的读写操作时资源争用系数,进行增强其并发能力。在buffer pool中,读取或存入页面时所选择的区域是基于hash算法随机进行的。每个buffer pool管理自己的空闲列表、列表刷写、LRU以及其它跟buffer pool相关的数据结构,并通过各自的互斥锁进行保护。
此变量仅在变量innodb_buffer_pool_size的值大于1G时才能发挥功用,缓冲池的整体空间将由各buffer pool实例分割使用。出于最佳效用的目的,建议配合使用innodb_buffer_pool_instances和innodb_buffer_pool_size变量以使得每个buffer pool实例的都至少有1G的空间。作用范围为全局,可用于选项文件,属非动态变量
3,innodb_buffer_pool_size=#
设定InnoDB缓存表数据和索引的内存缓冲区大小,单位是字节。其默认值为128MB,最大值依赖于CPU架构。在一个较繁忙的服务器上,当缓冲池(buffer pool)大于1G时,设定innodb_buffer_pool_instances的值大于1可提其升伸缩能力。innodb_buffer_pool_size变量的值越大,MySQL服务器完成数据访问时就需要越少的IO,因此,在一个有够较大内存且为MySQL服务专用的服务器上,可以将此值设置为物理内存的80%。但如果出现如下情况,建议缩小此变量的值:(1)物理内存资源紧张导致内存页面换出;(2)InnoDB会为缓冲和控制结构(buffers and control structures)预留额外的内存,因此事实上其占用的内存空间可能会比指定的数值大10%左右,这不可能超出对内存资源分配的预估;(3)内存地址空间必须连续,这在基于DLL库使用特殊地址空间的Windows系统上可能会出现意外情况;(4)缓冲池的初始化所需要时长与为其指定的空间大小成正比,例如有10G缓冲池的x86_64的Linux系统上,初始化时间大约要6秒钟。作用范围为全局,可用于选项文件,属非动态变量。
4,innodb_doublewirte={ON|OFF}
设定InnoDB是否使用双写缓冲。默认为启用。InnoDB在对页面进行部分写入的时候使用双写缓冲,以防止数据损坏。双写缓冲是表空间中一个特殊的保留区域,其大小足够在一个连续区间容纳100个页面。当InnoDB把页面从缓冲池刷写至磁盘时,它会先把这些页面刷到双写缓冲中,然后再保存至真正的目标位置。因此,双写缓冲本质上是最近写入页面的备份,其可确保每次写入的原子性和可持续性。在有些情况下双写缓冲是不必要的,例如在从服务器上就可以将之禁用;此外,一些文件系统(如ZFS)自身也会实现此功能,那么InnoDB就不用做重复的工作了。作用范围为全局,可用于选项文件,属非动态变量。
5,innodb_fast_shutdown={0|1|2}
设定InnoDB关闭模式。其可接受的值中,“0”表示慢速关闭,这意味着InnoDB关闭之前会完成完全清写(full purge)和修改缓冲合并(insert buffer merge)操作;“1”是默认值,它表示InnoDB在关闭时会跳过模式0中进行的这些操作,这也是其之所以称作“快速关闭”的原因;“2”表示InnoDB仅刷写日志信息并执行冷(cold)关闭,此时并没有事务丢失,只是下次启动MySQL服务时需要花费较长的时间进行故障恢复(crash recovery)。
执行慢速关闭时其过程可能会持续数分钟的时间,甚至在有些极端情况下,比如有着大量数据缓冲的场景,此过程时长会以小时来计。一般情况下仅在对MySQL进行主版本升级时才需要进行慢速关闭以使得数据文件能够为完全适应新版本而准备妥当。通常也只能遇到紧急状况或出于调试的目的才需要将此变量的值设定为2,以便让处于有可能损坏风险中的数据执行最快速度的关闭。作用范围为全局,可用于选项文件,属动态变量。
6,innodb_flush_log_at_trx_commit={0|1|2}
设定InnoDB同步日志缓冲区(log buffer)数据至日志文件中的方式,以及刷写日志文件至磁盘的方式。其可接受的值中,“0”表示将日志缓冲区每秒一次地写入日志文件,并同时将日志文件刷写至磁盘中,但事务提交时不会采取任何动作;“1”是默认值,表示在有事务提交时将日志缓冲区写入日志文件,并同时将日志文件刷写至磁盘;“2”表示每事务提交或每秒一次将日志缓冲区写入日志文件,但不会同时执行日志文件的刷写操作。当然,由于操作系统进程调度的原因,每秒一次的日志写入或刷写操作并不能得到100%的保证。
完全兼容ACID的场景需要将此变量值设置为1,由于要执行每事务的日志刷写操作,其会阻止I/O调用,直到写操作完成,故其会显著降低InnoDB每秒钟可以提交的事务数。设置为“2”可获得比“1”更好的性能,而且仅在操作系统崩溃时才会丢失最后一秒钟的数据,因此数据安全性也有着不错的表现。设置为“0”则有可能会导致事务最后一秒钟的数据丢失,于是整个事务的数据安全性将无法保证,但其通常有着最好的性能。为了在最大程序上保证复制的InnoDB事务持久性和一致性,应该设置变量innodb_flush_log_at_trx_commit=1以及设置变量sync_binlog=1。
然而需要注意的是,有些磁盘自身也有缓存,这可能会给事务操作带来额外的潜在风险。可以使用hdparm工具或供应商的自有工具等禁用磁盘自身的缓存。当然,高性能事务的最佳配置是把此变量的值设置为1,并且将日志文件放在有备用电池的写入缓存的RAID上。作用范围为全局,可用于选项文件,属动态变量
7,innodb_strict_mod={ON|OFF}
为防止无视SQL语句书写或语法中的错误或无视操作模式与SQL语句各种组合中的无心之过,InnoDB提供了所谓的严格模式。严格模式中,前述的问题一旦出现将会导致InnoDB产生一个错误,而非警告和一系列特定的处理操作。此参数则正是用于定义是否启用InnoDB的严格模式,默认为OFF。
8,innodb_force_recovery={0|1|2|3|4|5|6}
设定InnoDB的故障恢复模式。InnoDB出现了“页面损坏(page corruption)”时,通常大部分数据仍然完好,于是可以通过SELECT...INTO OUTFILE命令备份出数据以降低损失程度。然而,某些“损坏”类的故障可能会导致SELECT * FROM tbl_name命令无法执行或InnoDB后台操作崩溃,甚至会导致InnoDB的前滚操作。这种情况下,就可以使用innodb_force_recovery变量强制InnoDB存储引擎在启动时不执行后台操作,以便能将数据备份出来。
innodb_force_recovery可接受的值中,“0”为默认值,表示执行正常启动,即不启用“强制修复”模式。而非零值中,某数值会包含比其小的所有数值的预防措施,然而其也较可能给B-tree索引及其它的数据结构带来更多的损坏。故此,在此变量值为非零值时,其会阻止用户使用INSERT、UPDATE或DELETE操作,但是会允许执行SELECT、CREATE TABLE或DROP TABLE类的操作。以下是关于其它非零值功能的说明:
1(SRV_FORCE_IGNORE_CORRUPT):即使出现了页面损坏也照常运行MySQL服务,其会在SELECT * FROM tbl_name语句执行时尝试跳过损坏的索引记录和页面。
2(SRV_FORCE_NO_BACKGROUND):禁止启动主线程(master thread),其会在执行清写(purge)操作时防止出现崩溃(crash)。
3(SRV_FORCE_NO_TRX_UNDO):在故障恢复(crash recovery)后不执行事务的回滚操作。
4(SRV_FORCE_NO_IBUF_MERGE):禁止执行修改缓冲(insert buffer)合并操作。
5(SRV_FORCE_NO_UNDO_LOG_SCAN):在启动数据库服务时不检查撤消日志(undo logs),这会导致InnoDB将未完成的事务视为已提交。
6(SRV_FORCE_NO_LOG_REDO):不执行重做日志(redo log)的前滚操作。此时,仅能执行不带WHERE、ORDER BY或其它子句的SELECT * FROM tbl_name操作,因为复杂查询在遇到损坏的数据结构时会中止并退出。
9,innodb_io_capacity=#
设定InnoDB后台任务(如从缓冲池刷写页面或合并修改缓冲中的数据等)可执行的I/O操作上限。其最小值为100,默认值为200,最大值取决于CPU架构。对于有着较大I/O负载的服务器来讲,应该为其指定更大的值以便能够更好更快的执行后台维护任务。然而,在实践中,此变量的值应该尽可能接近MySQL服务器每秒钟执行的I/O操作数量(即IOPS),甚至于让其低至以不影响后台任务执行为目标的最低限度。因为,如果此值过高的话,数据会被频繁地从缓冲中移入移出,这会降低缓存池的在系统性能提升方面的效用。单个5400RPM或7200RPM磁盘仅能完成大约100个IOPS,因此,此种情况下应该将此变量值降低至100;而对于有着多块磁盘或更强性能的存储设备(如固态磁盘)的应用场景,可以按需提高此变量的值。作用范围为全局,可用于选项文件,属动态变量。
10,innodb_log_buffer_size={262144 .. 4294967295}
设定InnoDB用于辅助完成日志文件写操作的日志缓冲区大小,单位是字节,默认为8MB。较大的事务可以借助于更大的日志缓冲区来避免在事务完成之前将日志缓冲区的数据写入日志文件,以减少I/O操作进而提升系统性能。因此,在有着较大事务的应用场景中,建议为此变量设定一个更大的值。作用范围为全局级别,可用于选项文件,属非动态变量。
innodb_log_file_size={108576 .. 4294967295}
设定日志组中每个日志文件的大小,单位是字节,默认值是5MB。较为明智的取值范围是从1MB到缓存池体积的1/n,其中n表示日志组中日志文件的个数。日志文件越大,在缓存池中需要执行的检查点刷写操作就越少,这意味着所需的I/O操作也就越少,然而这也会导致较慢的故障恢复速度。作用范围为全局级别,可用于选项文件,属非动态变量。