• mysql+heartbeat双主高可用


    wKiom1NY95PxdZryAABkZkymrM8614.png

    说明:1,平时对外提供vip让用户写
         2,两台主的互为主从,都有二进制日志和中继日志
         3,平时只有有vip的主的写,另一台主的只读
         4,主从复制时,一半从的指向一台主的
         5,当有vip的主的下线时,另一台主的把vip抢过来,继续提供写

    优点:1,保证了一定程度的高可用
         2,分担了主从复制时,主服务器的压力
         3,虽然是双主,但是由于一直只有一台提供写,所以一般不会出现数据不一致
         4,解决drbd高可用时,另一台主的只能干备着,不能读也不能写

         5, 没有自动增长的问题

    缺点:1,由于有一半的从服务器指向了一台主的,所以当一台主的下线时
            有一半的从服务器得不到最新的数据()

    以上都是个人见解,如有错误。。

    关于mysql主从复制:
    MySQL使用3个线程来执行复制功能(其中1个在主服务器上,另两个在从服务器上。当发出start slave时,
    从服务器创建一个i/o线程,以连接主服务器并让它发送记录在其二进制日志中的语句。主服务器创建一个线
    程将二进制日志中的内容发送到从服务器。该线程可以识别为主服务器上show processlist的输出中
    的binlog dump线程。从服务器i/o线程读取主服务器binlog dump线程发送的内容并将该数据拷贝到从服务器
    数据目录中的本地文件中,即中继日志。第3个线程是sql线程,是从服务器创建用于读取中继日志并执行日
    志中包含的更新。
    show processlist语句可以提供在主服务器上和从服务器上发生的关于复制的信息

    MySQL 的复制可以是基于一条语句(Statement Level),也可以是基于一条记录(Row
    level),可以在 MySQL 的配置参数中设定这个复制级别,不同复制级别的设置会影响到
    Master 端的 Binary Log 记录成不同的形式。
    1.
    Row Level:Binary Log 中会记录成每一行数据被修改的形式,然后在 Slave 端
    再对相同的数据进行修改。
    优点:在 Row Level 模式下,Binary Log 中可以不记录执行的 sql 语句的上下文相关
    的信息,仅仅只需要记录那一条记录被修改了,修改成什么样了。所以 Row Level 的日志
    内容会非常清楚的记录下每一行数据修改的细节,非常容易理解。而且不会出现某些特定情
    况下的存储过程,或 function,以及 trigger 的调用和触发无法被正确复制的问题。
    缺点:Row Level 下,所有的执行的语句当记录到 Binary Log 中的时候,都将以每行
    记录的修改来记录,这样可能会产生大量的日志内容,比如有这样一条 update 语句:UPDATE
    group_message SET group_id = 1 where group_id = 2,执行之后,日志中记录的不是这
    条 update 语句所对应的事件(MySQL 以事件的形式来记录 Binary Log 日志),而是这条
    语句所更新的每一条记录的变化情况,这样就记录成很多条记录被更新的很多个事件。自然 ,
    Binary Log 日志的量就会很大。尤其是当执行 ALTER TABLE 之类的语句的时候,产生的日
    志量是惊人的。因为 MySQL 对于 ALTER TABLE 之类的 DDL 变更语句的处理方式是重建整个
    表的所有数据,也就是说表中的每一条记录都需要变动,那么该表的每一条记录都会被记录
    到日志中。
    2.
    Statement Level:每一条会修改数据的 Query 都会记录到 Master 的 Binary
    Log 中。Slave 在复制的时候 SQL 线程会解析成和原来 Master 端执行过的相同的 Query
    来再次执行。
    优点:Statement Level 下的优点首先就是解决了 Row Level 下的缺点,不需要记录每
    一行数据的变化,减少 Binary Log 日志量,节约了 IO 成本,提高了性能。因为他只需要
    记录在 Master 上所执行的语句的细节,以及执行语句时候的上下文的信息。
    缺点:由于他是记录的执行语句,所以,为了让这些语句在 slave 端也能正确执行,那
    么他还必须记录每条语句在执行的时候的一些相关信息,也就是上下文信息,以保证所有语
    句在 slave 端杯执行的时候能够得到和在 master 端执行时候相同的结果。另外就是,由于
    Mysql 现在发展比较快,很多的新功能不断的加入,使 mysql 得复制遇到了不小的挑战,自
    然复制的时候涉及到越复杂的内容,bug 也就越容易出现。在 statement level 下,目前已
    经发现的就有不少情况会造成 mysql 的复制出现问题,主要是修改数据的时候使用了某些特
    定的函数或者功能的时候会出现,比如:sleep()函数在有些版本中就不能真确复制,在存
    储过程中使用了 last_insert_id()函数,可能会使 slave 和 master 上得到不一致的 id 等
    等。由于 row level 是基于每一行来记录的变化,所以不会出现类似的问题。

    3,还有一种是混合模式(mixed),即让mysql自己判断语句应该怎么记录

    这个参数就是配置文件的:binlog_format=mixed



    复制时要考虑的几个mysql参数
    “sync_binlog”:这个参数是对于MySQL系统来说是至关重要的,他不仅影响到Binlog对MySQL所
    带来的性能损耗,而且还影响到 MySQL 中数据的完整性。对于“sync_binlog”参数的各种设置的说明如
    下:
    sync_binlog=0,当事务提交之后,MySQL 不做 fsync 之类的磁盘同步指令刷新 binlog_cache中
    的信息到磁盘,而让 Filesystem 自行决定什么时候来做同步,或者 cache 满了之后才同步到磁
    盘。
    sync_binlog=n,当每进行 n 次事务提交之后,MySQL 将进行一次 fsync 之类的磁盘同步指令来
    将 binlog_cache 中的数据强制写入磁盘。
    在 MySQL 中系统默认的设置是 sync_binlog=0,也就是不做任何强制性的磁盘刷新指令,这时候的性
    能是最好的,但是风险也是最大的。因为一旦系统 Crash,在 binlog_cache 中的所有 binlog 信息都会被
    丢失。而当设置为“1”的时候,是最安全但是性能损耗最大的设置。因为当设置为 1 的时候,即使系统
    Crash,也最多丢失 binlog_cache 中未完成的一个事务,对实际数据没有任何实质性影响。从以往经验
    和相关测试来看,对于高并发事务的系统来说,“sync_binlog”设置为 0 和设置为 1 的系统写入性能差
    距可能高达 5 倍甚至更多。

    log-slave-updates、gtid-mode、enforce-gtid-consistency、report-port和report-host:用于启动GTID及满足附属的其它需求;
    master-info-repository和relay-log-info-repository:启用此两项,可用于实现在崩溃时保证二进制及从服务器安全的功能;
    sync-master-info:启用之可确保无信息丢失;
    slave-paralles-workers:设定从服务器的SQL线程数;0表示关闭多线程复制功能;
    binlog-checksum、master-verify-checksum和slave-sql-verify-checksum:启用复制有关的所有校验功能;
    binlog-rows-query-log-events:启用之可用于在二进制日志记录事件相关的信息,可降低故障排除的复杂度;
    log-bin:启用二进制日志,这是保证复制功能的基本前提;
    server-id:同一个复制拓扑中的所有服务器的id号必须惟一;


    服务配置段[mysqld]中于少应该定义如下选项
    1.1、配置master节点:
    [mysqld]
    binlog-format=ROW
    log-bin=master-bin
    log-slave-updates=true
    gtid-mode=on 
    enforce-gtid-consistency=true
    master-info-repository=TABLE
    relay-log-info-repository=TABLE
    sync-master-info=1
    slave-parallel-workers=2
    binlog-checksum=CRC32
    master-verify-checksum=1
    slave-sql-verify-checksum=1
    binlog-rows-query-log_events=1
    server-id=1
    report-port=3306
    port=3306
    datadir=/mydata/data
    socket=/tmp/mysql.sock
    report-host=master.magedu.com

    1.2、配置slave节点:
    [mysqld]
    binlog-format=ROW
    log-slave-updates=true
    gtid-mode=on 
    enforce-gtid-consistency=true
    master-info-repository=TABLE
    relay-log-info-repository=TABLE
    sync-master-info=1
    slave-parallel-workers=2
    binlog-checksum=CRC32
    master-verify-checksum=1
    slave-sql-verify-checksum=1
    relay-log=mysql-relay-bin
    binlog-rows-query-log_events=1
    server-id=11
    report-port=3306
    port=3306
    log-bin=mysql-bin.log
    datadir=/mydata/data
    socket=/tmp/mysql.sock
    report-host=slave.magedu.com
    read_only=on

    配置双主(版本要一样):
    修改my.cnf
    server=1
    log-bin=mysql-bin          二进制日志应该单独存放
    relay-log=mysql-relay-bin

    如果有数据可先备份数据到其他节点
    mysql> flush tables with read lock;
    记录二进制日志位置
    mysql> show master status;
    +-------------------+----------+--------------+------------------+
    | File              | Position | Binlog_Do_DB | Binlog_Ignore_DB |
    +-------------------+----------+--------------+------------------+
    | master-bin.000031 |      284 |              |                  |
    +-------------------+----------+--------------+------------------+
    同步数据文件
    [root@localhost ~]# rsync -av /mysql/ 192.168.100.9:/mysql
    mysql> unlock tables;

    授权复制主机
    mysql> grant replication slave,replication client on *.* to 'repluser'@'192.168.100._' identified by 'redhat';
    ------------
    配置好另一台后连接另一台主的
    mysql> change master to master_host='192.168.100.10',master_user='repluser',master_password='redhat',master_log_file='master-bin.000001',master_log_pos=106;
    -----------
    mysql> start slave ;
    确保都为yes
    mysql> show slave statusG
     Relay_Master_Log_File: master-bin.000001
                Slave_IO_Running: Yes
               Slave_SQL_Running: Yes
    在另一个主的上
    server=2         一定不能和其他节点上的一样,否则主从复制失败
    log-bin=mysql-bin          
    relay-log=mysql-relay-bin
    启动服务
    service mysqld start
    连接主服务器
    mysql> change master to master_host='192.168.100.7',master_user='repluser',master_password='redhat',master_log_file='master-bin.000031',master_log_pos=284;

    mysql> start slave ;
    确保都为yes
    mysql> show slave statusG
     Relay_Master_Log_File: master-bin.000031
                Slave_IO_Running: Yes
               Slave_SQL_Running: Yes

    记录二进制日志位置
    mysql> show master status;
    +-------------------+----------+--------------+------------------+
    | File              | Position | Binlog_Do_DB | Binlog_Ignore_DB |
    +-------------------+----------+--------------+------------------+
    | master-bin.000001 |      106 |              |                  |
    +-------------------+----------+--------------+------------------+
    授权复制主机
    mysql> grant replication slave,replication client on *.* to 'repluser'@'192.168.100._' identified by 'redhat';

    在双主之间配置heartbeat
    安装heartbeat
    主机名,时间,ssh互信

    ha.cf配置文件部分参数:

       autojoin    none
           #集群中的节点不会自动加入
       logfile /var/log/ha-log
           #指名heartbaet的日志存放位置
       keepalive 2
           #指定心跳使用间隔时间为2秒(即每两秒钟在eth1上发送一次广播)
       deadtime 30
           #指定备用节点在30秒内没有收到主节点的心跳信号后,则立即接管主节点的服务资源
       warntime 10
           #指定心跳延迟的时间为十秒。当10秒钟内备份节点不能接收到主节点的心跳信号时,就会往日志中写入一个警告日志,但此时不会切换服务
       initdead 120
           #在某些系统上,系统启动或重启之后需要经过一段时间网络才能正常工作,该选项用于解决这种情况产生的时间间隔。取值至少为deadtime的两倍。
       #mcast eth0 225.0.0.1 694 1 0
           #采用网卡eth0的Udp多播来组织心跳,一般在备用节点不止一台时使用。Bcast、ucast和mcast分别代表广播、单播和多播,是组织心跳的三种方式,任选其一即可。
       auto_failback off
           #用来定义当主节点恢复后,是否将服务自动切回,heartbeat的两台主机分别为主节点和备份节点。主节点在正常情况下占用资源并运行所有的服务,遇到故障时把资源交给备份节点并由备份节点运行服务。在该选项设为on的情况下,一旦主节点恢复运行,则自动获取资源并取代备份节点,如果该选项设置为off,那么当主节点恢复后,将变为备份节点,而原来的备份节点成为主节点,这里设置为off
       ping 192.168.12.237
           #选择ping的节点,ping 节点选择的越好,HA集群就越强壮,可以选择固定的路由器作为ping节点,但是最好不要选择集群中的成员作为ping节点,ping节点仅仅用来测试网络连接
       crm yes
           表示受crm控制
       node node1.magedu.com  
           #主节点主机名,可以通过命令“uanme –n”查看。
       node node2.magedu.com  
           #备用节点主机名
       #下面是对传输的数据进行压缩,是可选项
       compression     bz2
       compression_threshold 2
    在资源文件定义vip
    资源文件(/etc/ha.d/haresources)
    node1   IPaddr::192.168.100.5/24/eth0   

    认证文件(/etc/ha.d/authkeys)
    auth 1
    1 crc
    权限600

    在两个节点同样配置确保一样
    scp /etc/ha.d/authkeys /etc/ha.d/harsources /etc/ha.d/ha.cf 192.168.100.10:/etc/ha.d/
    启动服务
    service heartbeat start;ssh node2 'service heartbeat start'

    测试vip是否转移

    如果master意外崩溃导致二进制日志中的某事件损坏,可以在从服务器使用如下参数忽略:

                stop slave;
           set global     sql_slave_skip_counter = 1;

            start slave;

       复制相关的文件:
           master.info: 文本文件,保存从服务器连接至主服务时所需要的信息,每行一个值;
           relay-log.info: 文本文件,保存了复制位置:包括二进制日志和中继日志的文件及位置;

           为了复制的安全性:
               sync_master_info = 1    
               sync_relay_log = 1   
               sync_relay_log_info = 1

    从服务器意外崩溃时,建议使用pt-slave-start命令来启动slave; 
    从服务器落后于主服务器:
           Seconds_Behind_Master: 0

       评估主从服务表中的数据是否一致:
           pt-table-checksum

           如果数据不一致,解决办法
               1、重新备份并在从服务器导入数据;
               2、pt-table-sync 
    pt开头的工具由:percona-toolkit-2.2.4-1.noarch.rpm

    监控mysql服务器状态
    [root@localhost ~]# vmstat 2
    procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
    r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
    0  0    780 177488 152496 397160    0    0     4     9   21   15  0  0 100  0  0    
    0  0    780 177472 152500 397188    0    0     0    12   32   30  0  0 100  0  0    

    procs r:等待cpu时间片的进程数,一般不能大于cpu的物理核心数
    procs b:有多少进程已经进入了不可中断式睡眠,比如等待io,网络

    swpd:从内存交换到swpd的大小,通常是在内存中好久不用的,系统自动交换出去的,以保证有更多的内存给其他的进程
    free:剩余内存
    buff:缓冲
    cache:缓存
    swap si so:内存不够用了,在交换分区进进出出的量
    io bi bo:磁盘io
    system in cs:每秒中断和上下文切换
    cpu:表示cpu的时间都花在哪了
            us:用户空间
            sy:内核空间
            id:剩余
            wa:等待io
            st:被偷走的

    [root@localhost ~]# iostat -x -k /dev/sda
    Linux 2.6.32-358.el6.x86_64 (localhost.localdomain)     02/22/2014     _x86_64_    (2 CPU)

    avg-cpu:  %user   %nice %system %iowait  %steal   %idle
              0.07    0.01    0.17    0.11    0.00   99.64

    Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
    sda               0.04     3.56    0.32    0.72     5.34    17.16    43.52     0.02   17.79   3.09   0.32

    rrqm/s wrqm/s:每秒读写合并数
    r/s w/s:每秒读写
    rkB/s    wkB/s:每秒读写千字节数
    await:磁盘排队所花的时间,单位毫秒(发起了一个读磁盘的请求,过了这么久才看到硬盘)
    svctm:服务所用的时间,不包括排队 单位毫秒
    %util:磁盘利用率

    使用sar gnuplot监控系统
    1,生成信息文件
    [root@localhost ~]# LANG=C sar -q |awk '/^[^[:alpha:]]+$/{print $1,$(NF-2),$(NF-1),$NF}' >~/cpu.info

    2,写一个生成图片的文件
    [root@localhost ~]# vim gnuplot.cpu
    set xdata time
    set timefmt "%H:%M:%S"
    set term png size 1024,768
    set output "/var/www/html/cpu.png"
    plot '~/cpu.info' using 1:2 title 'min/1' with line,'~/cpu.info' using 1:3 title 'min/5' with line

    3,画图
    [root@localhost ~]# gnuplot gnuplot.cpu
    查看
    wKioL1NY94nTdbUoAADDD0auoHk809.png

  • 相关阅读:
    1.时间复杂度与空间复杂度分析
    数据结构与算法之重头再来
    MySQL时间字段与业务代码取出的时间不一致问题
    [redtiger]在线靶场level3
    win10 卡顿 MsMpEng.exe进程
    react 笔记 局部打印 print
    react table td 自动换行
    kali apt-get update release文件过期
    ubuntu怎么切换到root用户,切换到root账号方法
    winscp连接kali 使用预置密码验证 拒绝访问
  • 原文地址:https://www.cnblogs.com/lidabo/p/14254503.html
Copyright © 2020-2023  润新知