mysql

mysql使用存储过程生成测试数据

声明存过

测试使用

生成了100w条数据。还挺快,不到1小时完成。

 

 

 

mysql (登录)权限

对于多个不同机器访问数据库的权限,需要在权限分配时指定其主机名,并同时指定密码。

如:hadoop02、hadoop03两台机器要登录mysql,需要赋权:

使用通配符无效,这一条不太科学。以后有机会再验证:

 

mysql MHA + keepalived 实现高可用

MHA实现了mysql 的自动故障切换,但是切换后还需要手工修改应用的访问ip。

原文:http://bananalighter.com/mysql-master-ha-solution-one-master-one-candidate-master-and-multiple-slaves-configuration/

本文将配置keepalived与MHA一起工作,实现对mysql应用的透明高可用。

一、确定工作模式

MHA是检测mysql进程状态,自动连接备用机进行切换。

keepalived是检测keepalived的进程状态,自动将虚拟IP切换到备机。

因此在故障切换时,需要先切换mysql,等备机的mysql服务可用以后切换虚拟IP。

二、工作方式

MHA完成mysql master的切换后,调用“master_ip_failover”脚本杀死keepalived进程,触发keepalived切换虚拟IP。

1.修改/etc/masterha_default.cnf

2.配置keepalived

直接使用官方源安装keepalived。

编辑/etc/keepalived/keepalived.conf

MASTER的配置文件:

candidate MASTER的配置文件

三、配置masterha的ip failover脚本

新建文件:/script/masterha/master_ip_failover

四、使用测试

1.起keepalived

2.起mysql(注意,mysql的master ip应该配主机地址)

3.停master的mysql

4.测试failover是否成功

使用其他机器通过虚地址228登陆mysql

能登陆,成功了。

5.检查两台备机的情况

candidate master(211):

已经成功升主。

slave(227):

已经将主切换为211.

测试成功,大功告成。

 

 

 

 

 

 

 

 

 

 

【留存】MHA 参数列表详解

参考:http://wubx.net/category/cluster/

官网:

MHA 参数列表

  • Local : 指每一个配置块内部。 Local功能的参数需要放置在[server_xxx] 块下面
  • App : 参数作用于master/slave, 这些参数需要配置在[server_default]块的下面
  • Global : 作用于master/slave, Global级别的参数用于管理多组master/slave结构,可以统一化管理一些参数。

    hostname

    配置MySQL服务器的机器名或是IP地址,这个配置项是必须的,而且只能配置在[server_xxx]这个块下面。
    如:

    参数名 是否必须 作用域 默认值 例子及说明
    hostname Yes Local Only hostname=mysql_server1, hostname=192.168.0.1, etc

    ip

    MySQL服务器的ip地址。 默认从gethostname($hostname)中获得。 默认不用配置这个参数,MHA可以通过hostname自动获取,MHA通过IP地址连接MySQL服务器及SSH连接。
    如:

    参数名 是否必须 作用域 默认值 例子及说明
    ip No Local Only 通过gethostbyname($hostname)获得 ip=192.168.1.3

    port

    MySQL运行的端口号。 默认是3306. MHA使用IP和端口号连接MySQL
    如:

    参数名 是否必须 作用域 默认值 例子及说明
    port No Local/App/Glbal 3306 port=3306

    ssh_host

    (从MHA 0.53后开始支持) MHA要ssh上MySQL目标服务器使用hostname 或是ip地址。这个参数主要用于在使用多个VLAN的环境中。为了安全原因ssh默认不允许。默认这个参数和hostname相同。

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    ssh_host No Local Only 和hostname相同 ssh_host=mysql_server1, ssh_host=192.168.0.1, etc

    ssh_ip

    (从MHA 0.53后开始支持) 和ssh_host作用相同。 默认是gethostname($ssh_host)获得。

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    ssh_ip No Local Only gethostbyname($ssh_host) ssh_ip=192.168.1.3

    ssh_port

    (从MHA 0.53后开始支持) SSH使用的端口号,默认是22.
    如:

    参数名 是否必须 作用域 默认值 例子及说明
    ssh_port No Local/App/Global 22 ssh_port=22

    ssh_connection_timeout

    (从MHA 0.54后支持)默认是5秒。在没添加这个参数之前ssh超时时间是写死的。
    如:

    参数名 是否必须 作用域 默认值 例子及说明
    ssh_connection_timeout No Local/App/Global 5 ssh_connect_timeout=5

    ssh_options

    (从MHA 0.53后支持) 添加ssh命令行的支持参数,例如加上特别文件名的key的支持等。

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    ssh_options No Local/App/Global “” 空的 ssh_options=”-i /root/.ssh/id_dsa2″

    candidate_master

    你可能对于同一组slave中有着不同的规划,有的其望在Master故障时,提升为新的Master(如: Raid1的slave比Raid0的slave更适合做Master)

    这个参数的作用是当设计candidate_master = 1时,这个服务器有较高的优先级提升为新的master(还要具备: 开启binlog, 复制没有延迟)。 所以当设置了candidate_master = 1的机器在master故障时必然成为新的master. 但这是很有用的设置优先级的一个参数。

    如果设置了多台机器的caddidate_master = 1 , 优先策略依赖于块名字([server_xxx]). [server_1] 优衔权高于[server_2].

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    candidate_master No Local Only 0 candidate_mast=1

    no_master

    当设置了no_master = 1的服务器,这个服务器永远不会提升为新的master. 这个参数据对于永远不期望成为master的机器很有用。 如: 你可能需要在使用raid0的机器上设置no_master = 1 或是你希望在远程的idc里运行一个slave. 注意: 当没有可以成为新master的机器是MHA就直接退出来了同时停止监控和master故障切换。

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    no_master No Local Only 0 no_master=1

    ignore_fail

    在默认情况下,MHA manager不会在slave存在故障的情况下(已经不能通过SSH/MySQL进行连接,或是SQL Thread已经停止出错,其它原因)的情况下进行Master的故障切换(当不存在slave时MHA manager也会退出)。 但有些情况下你期望在slave存在问题的情况下,也进行故障切换。 所以当设置了ignore_fail = 1时,MHA会在所有的机器有问题的时间也会进行故障切换。 默认是0.

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    ignore_fail No Local Only 0 ignore_fail=1

    #skip_init_ssh_check#
    在MHA manager启动时跳过ssh检查。

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    skip_init_ssh_check No Local Only 0 skip_init_ssh_check=1

    skip_reset_slave

    (从MHA 0.56开始支持) Master故障切换后新的master上执行RESET SLAVE(ALL).

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    skip_reset_slave No Local/App/Global 0 skip_reset_slave=1

    user

    用于管理MySQL的用户名。这个最后需要root用户,因为它需要执行:stop slave; change master to , reset slave. 默认: root

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    user No Local/App/Global root user=mysql_root

    password

    MySQL的管理用户的密码。 默认是空的

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    password No Local/App/Global 空的 password=rootpass

    repl_user

    MySQL用于复制的用户,也是用于生成CHANGE MASTER TO 每个slave使用的用户。 这个用户必须有REPLICATION SLAVE权限在新的Master上。默认情况下 repl_user会在将来成为master的机器上运行show slave status获取到。

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    repl_user No Local/App/Global 从show slave status repl_user=repl

    repl_password

    MySQL中repl_user用户的密码。 默认是当前复制用的密码。  当你使用online_master_switch时,当使用–orig_master_is_new_slave(原来的Master成为新Master的一个slave)时,如果没有repl_password 开启同步就会失败了。因为当前master上用于复制的用户名和密码都是空的(MHA在原来的Master上执行change master to 时没有带复制的密码,虽然其它slave上设置了复制的密码)

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    repl_password No Local/App/Global 当前复制用的密码 repl_password=replpas

    disable_log_bin

    当设置了这个参数,在slave应用差异的relay log时不会产生二进制日志。 内部实现通过mysqlbinlog的disable-log-bin实现。

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    disable_log_bin No Local/App/Global 0 disable_log_bin=1

    master_pid_file

    指定MySQL的pid文件。 这个参数在一台服务器上运行多个MySQL服务进程时非常有用。

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    master_pid_file No Local/App/Global master_pid_file=/var/lib/mysql/master1.pid

    ssh_user

    MHA Mananger, MHA node系统上的用户。 这个帐号需要在远程机器上有执行权限(Manager->MySQL),在slave成员之间复制差异的relay-log(MySQL->MySQL)

    这个用户必须有读取MySQL的binary/relay日志和relay_log.info的权限,还需要对远程MySQL上remote_workdir目录的写权限。

    这个用户还必须可以直接ssh到远程机顺上, 推荐使用ssh pbulic key . 一般使用的ssh_user也是运行manager那个那个用户。

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    ssh_user No Local/App/Global 当前使用的系统用户 ssh_user=root

    remote_workdir

    MHA node上工作目录的全路径名。如果不存在,MHA node会自动创建,如果不允许创建,MHA Node自动异常退出。 需要注意MHA manager 或是MHA node上需要检查空间是否可用,所以需要注意检查这个。 一般默认, remote_workdir是的”/var/tmp”

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    remote_workdir No Local/App/Global /var/tmp remote_workdir=/var/log/masterha/app1

    master_binlog_dir

    master上用于存储binary日志的全路径。这个参数用于当master上mysql死掉后,通过ssh连到mysql服务器上,找到需要binary日志事件。这个参数可以帮助用于无法找到master进程死掉后binary日志存储位置。

    一般: master_binlog_dir是”/var/lib/mysql/, /var/log/mysql”. “/var/lib/mysql/”是大多数系统发行版本的存放位置,”/var/log/mysql”是ubuntu发行版本的存放位置。 你也可以设置多个存放位置用逗号隔开。

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    master_binlog_dir No Local/App/Gobal /var/lib/mysql master_binlog_dir=/data/mysql1,/data/mysql2

    log_level

    设置MHA manager记录LOG的级别。 默认是info级别而且大多数情况也是比较适合。 同样可以设置为: debug/info/warning/error.

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    log_level No App/Global info log_level=debug

    manager_workdir

    用于指定mha manager产生相关状态文件全路径。 如果没设置 默认是/var/tmp

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    manager_workdir No App /var/tmp manager_workdir=/var/log/masterha

    manager_log

    指定mha manager的绝对路径的文件名日志文件。 如果没设置MHA Manager将打印到STDOUT/STDERR。 当手工执行故障切换(交互模式切换),MHA Manager会忽略manager_log设置直接将日志输出到STDOUT/STDERR.

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    manager_log No App STDERR manager_log=/var/log/masterha/app1.log

    check_repl_delay

    在默认情况下,当一个slave同步延迟超过100M relay log(需要应用超过100M relay log), MHA在做故障切换时不会选择这个slave做为新的master,因为恢复需要经过很长时间.当设置了check_repl_delay = 0, MHA将忽略被选择的slave上的同步延迟。 这个选项在设置了candidate_master = 1特声明的期望这台机器成为master的情况下特别有用。

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    check_repl_delay No App/Golbal 1 check_repl_delay=0

    check_repl_filter

    在默认下情况,当master和slave设置了不同了binary log/replication 过滤规则时,MHA直接报错不会进行监控和故障切换。 这些将会导致出现一些异想不到的错误”Table not exists”。如果你100%确认不同的过滤规则不会导致恢复中的错误,设置check_repl_filter=0。 需要注意: 当使用了check_repl_filter = 0时,MHA不会检查过滤规则在应用差异的relay日志,所以有可能会出现”Table not exists”的错误。当你设置了这个参数请小心处理。

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    check_repl_filter No App/Global 1 check_repl_filter=0

    latest_priority

    在默认情况下,和Master最接近的slave(一个slave从Master上获得了最一个binlog事件)是最有优先权成为新的master。 如果你想控制一下切换的策略(如: 先选择host2,如果不行,选host3;host3不行,选host4…) 那么设置latest_priority = 0 就可以了。

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    latest_priority No App/Global 1 latest_priority=0

    multi_tier_slave

    从MHA 0.52开始, 多层复制可以支持了。在默认情况下,不支持三层或是更多层的复制配置。 如果: host2从host1上复制,host3从host2上复制。 在默认配置的情况下不支持写host{1,2,3},因为这是一个三层的复制,MHA Manager会停止报错。 当设置了multi_tier_slave, MHA Manager就不会在三层复制报错停止。 但是会忽略第三层的机器。也就是如果host1挂了,host2将会成为新的master,host3还是从host2上进行复制。

    这个参数在MHA Manager 0.52后的版开始支持。

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    muli_tier_slave No App/Global 0 multi_tier_slave=1

    ping_interval

    这个参数设置MHA Manager多长时间去ping一下master(执行一些SQL语句). 当失去和master三次偿试,MHA Manager会认为MySQL Master死掉了。也就是说,最大的故障切换时间是4次ping_interval的时间,默认是3秒。

    如果MHA Manager在和MySQL创建连接时都收到多连接错误或是认证错误,这个就不做重试就会认为master已经挂掉。

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    ping_interval No App/Global 3 ping_interval=5

    ping_type

    (从MHA 0.53后开始支持) 在默认情况下, MHA manager和MySQL创建一个连接执行”select 1″(ping_type=select)用于检查master是否健康。 但有一些情况: 每次检测都连接/然后断开会比较好一点,这样对于tcp方面的错误感知更快一点。设置ping_type=CONNECT 就行了。从MHA 0.56后pint_type=INSERT也被添加。

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    ping_type No App/Global SELECT ping_type=CONNECT

    secondary_check_script

    一般来讲, 非常推荐使用更多网络上机器是不同路由策略上的机器来检查MySQL Master是否存活。 默认情况下,只有MHA Manager通过一个路由来检查Master是否存活。这个也是不推荐的。MHA可以通过外部secondary_check_script配置的脚本来做到从多个路由策略下进行检查。

    secondary_check_script = masterha_secondary_check -s remote_host1 -s remote_host2

    secondary_check_script包含在MHA Manager发行包中。 MHA中内置的secondary_check_script在大多数情况下工作良好,但并不是任何地都可以使用这个脚本。

    在上面的例子中, MHA Manager通过Manager->(A)->remote_host1->(B)->master_host 和Manager->(A)-remote_host2->(B)->master_host来检查MySQL master是否存活。如果在连接过程中通过A可以都成功,通过B是都失败,secondary_\check_\script返回0,而且认为master已经死掉,进行故障切换。如果通过A成功,但返回代码为: 2,则MHA manager有会认为是网络问题,则不会进行故障切换。如果A成功,B也成功,masterha_secondary_check 退出返回:3 则MHA Manager就为认为MySQL Master为存活状态, 则不会进行故障切换。

    一般来讲, remote_host1和remote_host2是和MHA Manager及MySQL Server位于不同的网段中。

    MHA会调用secondary_check_script声明的脚本并自动带上一些参数。 masterha_secondary_check在很多场景都是适用的,但是你也可以自已实现这个程序带有更多的功能。

  • –user=(在远程机器上使用的SSH用户名。 ssh_user的值将被使用)
  • –master_host = (master的hostname)
  • –master_ip = (master的ip地址)
  • –master_port = ( master的端口号)注意: 内置的masterha_secondary_check脚本依赖于的Perl的IO::Socket::INET(Perl 5.6.0中是默认支持包含这个模块)。 masterha_secondary_check需要通过ssh连接到远程的机器上,所以需要manager到远程机器上建立public key信任。另外masterha_secondary_check是通过和Master建立TCP的连接测试Master是否存活,所以mysql设置的max_connections不起作用。 但每次TCP连接成功后,MySQL的Aborted_connects 值都会加1。

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    secondary_check_script No App/Global null secondary_check_script= masterha_secondary_check -s remote_dc1 -s remote_dc2

    master_ip_failover_script

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    master_ip_failover_script No App/Global null master_ip_failover_script=/usr/local/custom_script/master_ip_failover

    master_ip_online_changes_script

    这个参数有点类似于master_ip_failover_script,但这个参数不用于master 故障转意,只使用到master在线的切换。

  • 冻结Master写的过程:

    –command=stop or stopssh
    –orig_master_host = (当前master的主机名)
    –orig_master_ip = (当前master的ip地址)
    –orig_master_port = (当前master的port端口号)
    –orig_master_user = (当前master的用户)
    –orig_master_password = (当前master的用户名)
    –orig_master_ssh_user = (从0.56支持,当前master的ssh的用户名)
    –orig_master_is_new_slave =  (从 0.56 ,是否把原Master更改为新的slave)

  • 新的Master接受写的过程:

    –command=start
    –orig_master_host = ( 原master的机器名 )
    –orig_master_ip = ( 原master的ip )
    –orig_master_port = ( 原master的端口号 )
    –new_master_host = (新master的机器名)
    –new_master_ip = (新master的ip)
    –new_master_port = (新master的端口号)
    –new_master_user = (新master上的用户名)
    –new_master_password = (新master上的用户名及密码)
    –new_master_ssh_user = (从0.56支持, 新master上的ssh用户)

    MHA在冻结写的切换过程中会在Master上执行FlUSH TABLES WITH READ LOCK,在这个优雅的切换过程不会有任何写入的。在新的Master在开始授权写的过程中,你可以做和master_ip_failover_script一样的事情。 例如: 创建用户及权限, 执行set global read_only=0, 更新数据库路由表竺。 如果脚本执行退出码不是0 或是10, MHA Manager异常退出并发不会继续进行master切换。

    默认这个参数是空的,所以MHA Manager在默认情况下什么也不做。

    可以在(MHA Manager package)/samples/scripts/master_ip_online_change。里找到例子脚本。例子脚本包含于MHA Manager源文件或是GitHub的分支中。

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    master_ip_online_change_script No App/Global null master_ip_online_change_script= /usr/local/custom_script/master_ip_online_change

    shutdown_script

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    shutdown_script No App/Global null shutdown_script= /usr/local/custom_script/master_shutdown

    report_script

    在Master故障完毕后,也许想发一个送一个报告(如email)报告一下切换完毕或是发生的错误。report_script可以完成这个工作。MHA Manager可以通过以下参数使用:

  • –orig_master_host = (死掉master机器名)
  • –new_master_host = (新的master机器名)
  • –new_slave_hosts = (新的slave机器名列表,用逗号隔开)
  • –subject = (邮件名)
  • –body = (正文)默认这些参数是空的。 所以默认MHA Manager什么事情也不做。

    可以在(MHA Manager package)/samples/scripts/send_report里找到例子脚本。例子脚本包含于MHA Manager源文件或是GitHub的分支中。

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    report_script No App/Global null report_script= /usr/local/custom_script/report

    init_conf_load_script

    这个参数用于不想设置明文在配置文件中(如:密码相关)。 只用返回”name=value”这样的值。 这个可以用来复盖global配置中的一些值。一个例子脚本如下。

    #!/usr/bin/perl

    print “password=$ROOT_PASS\n”;

    print “repl_password=$REPL_PASS\n”;

    如:

    参数名 是否必须 作用域 默认值 例子及说明
    init_conf_load_script No App/Global null report_script= /usr/local/custom_script/init_conf_loader

mysql 数据库崩溃无法启动

兴高采烈的登陆机器测master HA,结果mysql竟然挂了。

那就重启吧

我裤子都脱了,结果他给我看这个:

找了半天找到日志目录:/app/mysql/mysqld.log

查找./mysql-bin.000001,发现这个文件不在mysql lib目录(/var/lib/mysql)下面。

于是:

参考:http://blog.csdn.net/lxpbs8851/article/details/8101462

 

 

 

mysql master HA solution: one master, one candidate master, and multiple slaves configuration

环境:

三台percona server:210, 211, 227。

210为M——master,211为M2——candidate master ,227为S——slave。

整体架构为:

M(读写)  —  M2(只读)
|
S(只读)

实际配置上,M2与S是两个平行的slave(从机)。

唯一区别:在master HA的配置中,配置M2为candidate master。当master宕机时,优先将M2升级为新master。

 

一、配master

可以参考主从配置的blog:http://bananalighter.com/mysql-master-slaver-replication/

dump出数据供slave建库使用。

二、配candidate master和slave(注意只读)

1.candidate master(211机器,已经在主从模式中配置过my.cnf,不赘述)

 

2.slave

(1)创建数据库

(2)导入前述步骤导出的数据库数据。

 

(3)配置my.cnf

重启数据库

(4)新建同步用户,配权限及master

(5)在这里有个问题,困扰我一下午。

show slave status\G报错:

Last_Error: Error ‘Duplicate entry ‘7’ for key ‘PRIMARY” on query. Default database: ‘test’. Query: ‘insert into test (id,value) values (7,77)’

我理解,这是由于slave同步到了不够新的relay log,有些重做的sql数据其实已经dump出来了,就不能再插一次。思路是清一清master的log。

不过下文的哥们通过让slave跳过这些sql绕开了这些问题。

参考:http://blog.sina.com.cn/s/blog_502c8cc401010p4b.html

注:只读的概念参见文章:http://bananalighter.com/mysql-variables-read-only/

(6)三个服务器的同步测试

在master插入一条数据,两个从机同步更新,不赘述。

三、配置master HA

(1)编辑master HA 配置文件/etc/masterha/test_MMS.cnf

注:

candidate_master
You might use different kinds of machines between slaves, and want to promote the most reliable machine to the new master (i.e. promoting a RAID1+0 slave rather than RAID0 slaves).
By setting candidate_master to 1, the server is prioritized to the new master, as long as it meets conditions to be the new master (i.e. binary log is enabled, it does not delay replication significantly, etc). So candidate_master=1 does not mean that the specified host always becomes new master when the current master crashes, but is helpful to set priority.
If you set candidate_master=1 on multiple servers, priority is decided by sort order by block name ([server_xxx]). [server_1] will have higher priority than [server_2].
no_master
By setting no_master=1 on the target server, the server never becomes the new master. This is useful if you have some servers that should not become the new master. For example, you may want to set no_master=1 when you run slaves on unreliable (RAID0) machine, or when you run a slave at a remote data center. Note that if none of the slaves can be new master, MHA aborts and does not start monitoring/failover.

(2)配各个机器的hosts文件和ssh免密登陆

(3)检查并运行masterHA

各种mysql同步的错误和状态解释: http://www.jb51.net/article/27221.htm

卧槽,MHA就没生效啊! 啊啊啊!尼玛

反复检查了好多遍,费了两天时间,终于知道为啥了。

原因是在masterha的默认配置文件中添加了master_ip_failover_script的配置(抄的官网),但是并没有编写对应的脚本。所以调用出错。太脑残了。

注释掉相关配置就好啦。

以下是测试,还特么的有错:

检查slave机的mysql日志:

被这个问题刷屏了。搜索发现大部分人报告的问题是server_id相同导致的master端识别slave混乱。但我的是不同的。

再深度搜索,终于被一文章救命了:http://www.2cto.com/database/201405/305269.html

还是master对slave的识别混乱问题,不过这次搞相同了的是server_uuid

查看如下。

修复手段:修改/mysql_data_dir/auto.cnf

重启数据库,重启slave。

done!!!

终于ok了,从部署好至此过了3天。神坑爹。

四、failover测试

场景——M跪,M2起,S挂到M2

以下是各种输入输出:

M(210):

M2(211):

S(227):

明显master切到了211。

五、复原

将M先设为M2 的slave

使用masterHA自带的切换工具masterha_master_switch

注:这里

对于生产系统还是要先把数据刷到盘里的,这里测试就不费劲了。

 

mysql 只读配置的含义

【转载】:http://blog.csdn.net/cindy9902/article/details/5886355

  –read_only         Make all non-temporary tables read-only, with the
exception for replication (slave) threads and users with
the SUPER privilege

SUPER privilege :

The SUPER privilege enables an account to use CHANGE MASTER TO , KILL or mysqladmin kill to kill threads belonging to other accounts (you can always kill your own threads), PURGE BINARY LOGS , configuration changes using SET GLOBAL to modify global system variables, the mysqladmin debug command, enabling or disabling logging, performing updates even if the read_only system variable is enabled, starting and stopping replication on slave servers, specification of any account in the DEFINER attribute of stored programs and views, and enables you to connect (once) even if the connection limit controlled by the max_connections system variable is reached.

To create or alter stored routines if binary logging is enabled, you may also need the SUPER privilege, as described in Section 18.6, “Binary Logging of Stored Programs” .

 

read-only选项:对所有的非临时表进行只读控制。但是有两种情况例外:

1. 对replication threads例外,以保证slave能够正常的进行replication。

2. 对于拥有super权限的用户,可以ignore这个选项。

SUPER 权限 : 1. 可以有change master to, kill其他用户的线程的权限。

2. Purge binary logs 来删除binary log, set global来动态设置变量的权限。

3. 执行mysqladmin debug命令,开启或者关闭log,在read-only打开时执行update/insert操作。

4. 执行start slave, stop slave.

5. 当连接数已经达到max_connections的最大值时,也可以连接到server。

【翻译】mysql master HA other solutions

参考:https://code.google.com/p/mysql-master-ha/wiki/Other_HA_Solutions#Other_Solutions_and_Issues

mysql master HA各种解决方案:

手动解决

mysql复制是异步或者半同步的。当master崩溃时,一些slave很有可能尚未接收到最新的relay log事件,这就可能导致slave之间可能处于不同的状态。手动解决一致性问题并不繁杂,但若不解决一致性问题,主从复制将无法启动。手动重启主从复制往往需要花费一小时的时间。

只有一个master并只挂一个slave

只有一个master和一个slave时,不会发生一些slave过时于某一slave的情况。当master崩溃时,只要使应用将所有流量发送到slave转成的新master上即可。故障切换很简单。

M(RW)
|                          –(master crash)–>             M(RW), promoted from S
S(R)

主(读写)
|                          –(master崩溃)–>               新主(读写), 由从机生格而来
从(读)

但是本节方案有严重的问题。

首先,无法水平扩展读流量。当在一个slave运行诸如备份、分析查询、脚本任务等重量级操作时可能带来性能问题。当这个唯一的slave宕机时,master需要处理slave的所有流量。

其次是可用性,当master宕机时,只剩新主机成为单一故障点。创建新slave需要作在线备份,将数据转储到新硬件并立即开启slave。这些操作通常需要花费几个小时的时间。一些关键应用不允许数据库成为单一故障点并持续几个小时的时间。在线备份数据库会造成额外的i/o负担,所以在使用高峰时期备份也是危险的。

第三个问题是缺乏扩展性。例如,如果想要在远程数据中心建立一个只读数据库,需要至少两个slave,一个位于本地数据中心,另一个slave位于远程数据中心。只有一个slave无法建立前述架构。

单一slave在许多场景中都无法满足要求。

 一个master一个候选master及多个slave

使用标题所述架构非常常见。在当前master宕机时,候选master具有较高优先级成为新的master。有些情况下候选master配置成只读master:譬如多master的配置。

 

M(RW)—–M2(R)                                            M(RW), promoted from M2
|                                                                           |
+—-+—-+                –(master crash)–>                  +-x–+–x-+
S(R) S2(R)                                                           S(?)      S(?)
(From which position should S restart replication?)

 

M(读写)—–M2(只读)                                            M(读写), 由 M2 升格成为新master
|                                                                           |
+—-+—-+                –(master 宕机)–>                   +-x–+–x-+
S(只读) S2(只读)                                                   S(?)      S(?)
(slave应该从哪一点开始复制?)

但是前述方案作为master的灾备方案不总是可行的。当master宕机时,其余salve可能没有接收到全部的relay log时间,因此还是需要解决salve之间的一致性问题。

既不能接受一致性问题,又想立即恢复服务怎么办:将候选master升格为新master,丢弃全部slave。然后通过在线备份新master建立新的slave。这种方案与上一节“单主单从”的问题一样,剩余的slave不能用于扩展读流量,也不能用于冗余。在恢复slave规模之前,将会产生故障单点问题。

这种架构使用非常广泛,但只有少数人能够全面了解前述的潜在问题:当master宕机时,其挂载的slave变得不一致;试图直接将slave挂到新master上开启复制也会失败。如果想要保证一致性,必须舍弃全部原有的slave。

还有一种架构:两个master,一个只读。每个master都至少挂一个slave。

M(RW)–M2(R)
|           |
S(R)    S2(R)

M(读写)  —  M2(只读)
|                |
S(只读)      S2(只读)

当当前master宕机时,至少有一个slave可以继续复制。但是这种方案使用不多,它最大的缺点是太复杂。三层复制(主主从,M->M2->S2)采用了这种架构,但是管理三层复制比较复杂。例如,如果中层的服务器(M2)宕机,第三层的slave(S2)无法继续复制。在许多情况下,需要重新配置M2和S2,因此这种架构至少需要4台机器(一台空白机用于出现问题时顶上)。

(待续)