数据库集群的现状
数据库集群是将计算机集群技术引入到数据库中来实现的，有数据库厂商自己开发的；也有第三方的集群公司开发的；还有数据库厂商与第三方集群公司合作开发的，各类集群实现的功能及架构也不尽相同
Oracle’s Real Application Cluster (RAC)
Microsoft SQL Cluster Server (MSCS)
IBM’s DB2 UDB High Availability Cluster(UDB)
Sybase ASE High Availability Cluster (ASE)
MySQL High Availability Cluster (MySQL CS)
Mysql主从的优缺点： Mysql的主从同步是一个成熟的架构。优点：1.在从服务器上可以执行查询工作，降低主服务器压力。2.在从服务器中备份，避免备份期间影响主服务器服务。3.当主服务器出现问题时，可以切换到从服务器
单线程危害： 实际上，在老版本中，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 线程。通过这样的改造，这样既在很大程度上解决了性能问题，缩短了异步的延时时间，同时也减少了潜在的数据丢失量
问题：即使是换成了现在这样两个线程来协作处理之后，同样也还是存在 Slave 数据延时以及数据丢失的可能性的，毕竟这个复制是异步的。只要数据的更改不是在一个事务中，这些问题都是存在的。 二、Mysql主从复制的过滤
需要在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.查看主从同步状态
重要的指标为： 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; 或是这样： stop slave; set global sql_slave_skip_counter =1; start slave; 这个现象主要是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状态就可以了
息壤平台数据库同步：
default-storage-engine = InnoDB
character_set_server=utf8
log-bin=mysql-bin
log-bin-index=master-bin.index
server-id=48
binlog_do_db=hscloud
binlog_do_db=pyhscloud
binlog_do_db=openstack
binlog_do_db=mysql
MySQL-HA高可用
标签：