mysql主从配置

MySQL内建的复制功能是构建大型，高性能应用程序的基础。将MySQL的数据分布到多个系统上去，这种分布的机制，是通过将mysql的某一台主机的数据复制到其它主机（slave）上，并重新执行一遍来实现。 复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件，并维护文件的一个索引以跟踪日志循坏，这些日志可以记录发送到从服务器的更新。当一个从服务器 连接主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新，然后封锁并等待主服务器通知的更新。 需注意的是： 在进行mysql复制时，所有对复制中的表的更新必须在主服务器上进行。否则必须要小心，以避免用户对主服器上的表进行更新与对从服务器上的表所进行更新之间的冲突。 源码安装AliSQL-AliSQL-5.6.32-9 可以在我的网盘下载包 链接： https://pan.baidu.com/s/1FDmGV2zVLI9NxfdpjVqK4g 提取码：tpuy 复制这段内容后打开百度网盘，操作更方便哦： 主从间的数据库不是实时同步，就算网络连接正常，也存在瞬间主从数据不一致的情况。 如果需要多主库的话，可以用环形配置，这样任意一个节点的修改都可以同步到所有节点所以也需要ntp（时间同步） 源码安装AliSQL 接下来我们源码安装AliSQL

架构层面可以采用读写分离，主从复制等等，在数据库前端加cache，如memcache，用于用户登录，商品查询 1.mysql优化的原则是什么？ 答： 1.mysql的优化首先要从设计表的过程中就要做到合理规划，表的字段，尽量精确，比如能用char就不要用varchar，能用tinyint就不要用int。 2.索引的添加要适当，需要添加的地方就添加，不需要添加的地方就不要添加 3.读写尽量分离 4.编写存储过程的时候尽量不要用select * 5.mysql服务器硬件的配置尽量高点 6.选择合适的mysql引擎 2.你有做过哪些mysql的优化？ 必做的2个优化： long_query_time = 2 lower_case_table_names = 1 因为默认mysql慢查询默认定义的时间是10s，这样还是有点高，所以我通常会修改其为2s，lower_case_table_names的作用是不区分大小写，通常也会开启，然后其他的会根据具体情况去进行优化:比如 当你发现mysql日志中 Too Many Connections 的错误提示，则需要增大max_connections的值 当你的物理内存比较大，而磁盘IO又比较高的时候可以适当增大table_cache的值 如果你的表是myisam表，可以适当设置key_buffer_size的值，你可以通过show

《叶问》是知数堂新设计的互动栏目，不定期给大家提供技术知识小贴士，形式不限，或提问、或讨论均可，并在当天发布答案，让大家轻轻松松利用碎片时间就可以学到最实用的知识点。 2019年03月5日，周二 MySQL binlog_format=mixed，可行吗，为什么 不可行，因为会导致主从数据不一致 Mixed格式相当于 Row 和 Statement 模式的融合。遇到表结构变更的时候就会以statement模式来记录。像update或者delete等修改数据的语句，还是会记录所有行的变更。 但某些情况就会产生主从数据不一致例如： 1、当带有自增主键的更新多个列的表，并调用触发器或存储函数时 2、当SQL使用LOAD_FILE()功能时。（Bug＃39701） 3、当SQL语句引用一个或多个系统变量时。（Bug＃331168） 更多请参考，https://dev.mysql.com/doc/refman/8.0/en/binary-log-mixed.html 2019年03月26日，周二 MySQL误删除frm文件该怎么办？ 情况一：误删后还未重启MySQL 1、从proc中恢复.frm文件 cp /proc/`pidof mysqld`/fd/误删除的.frm /datadir/db/对应库的目录/ 情况二：误删后也重启MySQL了 2、从备份中获取表结构 2.1 物理备份

最近测试了一下mysql+keepalived实现主从自动切换，主从都需要安装keepalived，使用vip漂移实现主从自动切换，这里主要记录的是keepalived的文件配置。 这里mysql搭建的是双主。 环境： 主：192.168.184.128 从：192.168.184.133 vip：192.168.184.132 两台服务器配置的均是BACKUP，主机优先级是100，从机优先级是90.均为非抢占模式nopreempt(只有BACKUP才可以设置为nopreempt),设置非抢占模式后，在原主机恢复并正常启动keepalived后，不会自动切回，若想切回master，只需去掉该节点的nopreempt选项并且将priority改的比其他节点大，然后重新加载配置文件即可（等MASTER切过来之后再将配置文件改回去再reload一下）。 主从配置文件除了优先级priority和virtual_server中的real_server不一样外，其他均一样。 notify_master 是切换为master时执行的脚本，主要用于判断主从是否已同步，并记录下主从切换时的日志位置。 notify_backup 是切换为backup时执行的脚本，主要是修改一些使用于从库的参数。 nofify_stop 是keepalived服务停掉后执行的脚本，主要是配置一些参数

主服务器配置： 1)登陆MySQL数据库 mysql>mysql -uroot -p123 2）给从服务器设置授权用户 mysql>grant all slave on *.* to user1@192.168.10.2 identified by "123"; 或 mysql>grant replication slave on *.* user1@192.168.10.2 identified by "123"; 3)修改主数据库服务器的配置文件my.cnf，开 启binlog,并设置server-id的值 log-bin=mysql-bin server-id=1 4)在主服务器上设置读锁定有效，确保没有数据库操作，以便获得一个一致性的快照 mysql>flush tables with read lock; 或 mysql>mysqldump test.user -l -F > /tmp/user.sql(推荐这种) 5)查看主服务器上当前的二进制日志名和偏移量值 mysql>show master status; 6)目前主数据库服务器已经停止了更新操作，生成主数据库的备份，备份的方式有两种： 1.cp全部的数据 2.mysqldump备份数据方法 如果主数据库的服务可以停止，那么直接cp数据文件应该是最快的生成快照的方法 7）主数据库备份完毕后，主数据库可以恢复写操作

mysql5.7支持两种事务同步 主从复制有两种方式：基于日志（binlog）、基于 GTID（全局事务标示符）。本次采用基于日志（binlog）的方式。 在以前的mysql版本中，读写分离的实现一般都是基于日志的主从复制实现的，这样会产生一个问题，就是master宕机之后，slave由于同步延时的问题，会导致master和slave内容不同，甚至会多个slave之间互相不同。所以为了解决这个问题，再mysql5.7.6版本之后加入了基于GTID的事务控制，具体的说就是每个事务由一个唯一的gtid标识，当slave都成功执行之后master才写入硬盘完成该事务，如果master突然宕机，那么就自动回滚。数据的一致性得到保证。 操作方法和普通的基于日志的主从复制差不了很多，主要就是打开两个开关 enforce_gtid_consistency = ON gtid_mode = ON 那么就具体的介绍一下这种主从同步的搭建过程。 Master： 首先要修改mysql的配置文件，我这里的配置文件路径为/etc/mysql/mysql.conf.d/mysqld.cnf，基于docker，不同的版本位置可能会不一样，windows下多数都叫my.cnf，下载地址：https://hub.docker.com/r/alexzhuo/mysql/。 这里只截取要修改的那一段 修改前：

一.知识剖析: MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于 Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。 在MySQL故障切换过程中，MHA能做到在 0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。 MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。 目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库 注意： 1.需要奇数个结点 2.每一个节点都要安装master和master

配置 master conf/my.cnf [mysqld] server-id=101 log-bin=mysql-bin binlog-do-db=myserver binlog-do-db=myserver2 slaver conf/my.cnf [mysqld] server-id=102 log-bin=mysql-bin replicate-do-db=myserver 操作 master set sql_mode=(select replace(@@sql_mode,'ONLY_FULL_GROUP_BY','')); grant replication slave on *.* to 'backup'@'%' identified by '123456'; show master status; slaver set sql_mode=(select replace(@@sql_mode,'ONLY_FULL_GROUP_BY','')); change master to master_host='192.168.88.203',master_port=3306,master_user='backup',master_password='123456',master_log_file='mysql-bin.0000003',master_log_pos=439;

我们究竟应该如何对 MySQL 数据库进行优化？下面我就从 MySQL 对硬件的选择、 MySQL 的安装、 my.cnf 的优化、 MySQL 如何进行架构设计及数据切分等方面来说明这个问题。 服务器物理硬件的优化 在挑选硬件服务器时，我们应该从下面几个方面着重对 MySQL 服务器的硬件配置进行优化，也就是说将项目中的资金着重投入到如下几处： 1 、磁盘寻道能力（磁盘 I/O ），我们现在用的都是 SAS15000 转的硬盘，用 6 快这样的硬盘作 RAID1+0 。 MySQL 每一秒钟都在进行大量、复杂的查询操作，对磁盘的读写量可想而知，所以，通常认为磁盘 I/O 是约制 MySQL 性能的最大因素之一。对于日均访问量在 100 万 PV 以上的论坛（ Discuz ）、博客（ Wordpress ），如果性能不好，造成的直接后果就是 MySQL 的性能会非常低下！解决这一制约因素可以考虑解决访问是：使用 RAID1+0 磁盘阵列，注意不要尝试 RAID5 ， MySQL 在 PAID5 磁盘阵列上的效率不会像你期待的那样快，如果资金允许，可以选择固态硬盘 SSD 来替代 SAS 硬盘做 RAID1+0 。 2 、 CPU 对于 MySQL 的影响也是不容忽视的，建议选择运算能力强悍的 CPU 。推荐使用 DELL R710 （双四核）

MySQL主从复制 主从复制类型： 异步方式：一般的MySQL复制，主server只负责发送二进制日志，不check从是否完成 半同步方式：在一堆从中，主只保证其中一个返回同步完成即可，如果超时，自动降级为异步 级联方式：主复制给其中一个从，这个从再复制给后面的一堆从，用于减轻主的负担 架构： 普通一主多从： 带负载均衡的读写分离： 带级联复制和负载均衡的读写分离： 主从步骤： 主上面为每个slave开启一个dump thread 从上的IO thread和主上的dump thread连接，并发送二进制日志，在从上保存为realy log 从上的SQL thread从relay log中逐条读取并在本地执行 主从配置： 主上配置： 开启binlog 设置server id 创建同步用户，并授予REPLICATION SLAVE和REPLICATION CLIENT权限 从上配置： 开启relay log 设置与主不同的server id CHANGE MASTER TO MASTER_HOST='',MASTER_PORT=,MASTER_USER='',MASTER_PASSWORD='',MASTER_LOG_FILE='',MASTER_LOG_POS=; start slave io_thread;start slave sql_thread; 配置skip-slave