mysql主从配置

文章目录 mysql 主服务器配置 mysql 从服务器配置 不小心在从服务器上作了配置 添加一台从服务器 主服务器发生意外宕机了，提升一台从为主服务器 mysql 主服务器配置 yum install mariadb-server -y vim /etc/my.cnf [ mysqld ] server_id = 7 log_bin = /data/logbin/mariadb-bin mkdir /data/logbin chown -R mysql.mysql /data/logbin systemctl start mariadb mysql < hellodb_innodb.sql mysql MariaDB [ ( none ) ] > grant replication slave on *.* to 'replicationuser' @ '192.168.43.%' identified by 'centos' ; mysqldump -A -F --single-transaction --master-data = 1 -q > /data/all.sql scp /data/all.sql 192.168.43.17:/data/ mysql 从服务器配置 yum install mariadb-server -y vim /etc/my.cnf [

一、MySQL 会遇到的问题： 　　1、 高并发的读写效率低问题 ---- 解决方案：集群，分布式。 　　2、 海量数据的读写效率低问题 ----- 解决方案：分表，分库。 　　3、 高可用和高扩展 ---- 解决方案：动态扩展服务器、防止单点故障、容灾。 二、关系型数据库优化：（原则： 先单机，后多机。 ） 　　2.1 单机 优化方案 ： 　　　　1.慢SQL的定义--> 分析慢SQL -- 解决慢SQL。 　　　 　　　　2. 表的设计、索引、引擎的优化。 　　3. 分表(垂直分表、水平分表)、分区、分库 的优化。 　　 4. 缓存做集群。 　　　　5.SQL语句优化 　　 　　2.2 多机优化方案 （分为多个数据库）： 　　　　1. 读写分离（要保证 主从同步 ）： 　　　　　　 28 原则：如果有10个数据库，则 2 个专门做增删改的数据库， 8 个专门做查询的数据库。 　　　　2. 缓存做集群 三、定位慢SQL 　 　　3.1 查看数据库状态： 　　　　3.1.1 查看运行时间： show status like ‘uptime’; 　　　　3.1.2 CRUD 执行次数： 　　　　　　Show status like ‘Com_%’; 　　　　　　Show status like ‘Com_update%’ 　　　　　　Show status like ‘Com

Server层，选项持久化 mysql> show variables like '%max_connections%'; +------------------------+-------+ | Variable_name | Value | +------------------------+-------+ | max_connections | 512 | | mysqlx_max_connections | 100 | +------------------------+-------+ 2 rows in set (0.00 sec) mysql> set persist max_connections=8000; Query OK, 0 rows affected (0.00 sec) mysql> show variables like '%max_connections%'; +------------------------+-------+ | Variable_name | Value | +------------------------+-------+ | max_connections | 8000 | | mysqlx_max_connections | 100 | +------------------------+-------+ 2 rows

文章目录 前言 一、MySQL主从复制配置 1.1、概述 1.2、主从复制的过程 1.3、实验环境 1.4、主服务器配置 1.5、从服务器配置 二、MySQL主从复制验证 三、MySQL读写分离配置 3.1、概述 3.2、实验环境 3.3、amoeba服务器配置 四、验证读写分离 4.1、验证写入功能 4.2、验证读取功能 前言 MySQL主从复制与读写分离需要配置三个用户 用户1：在主服务器上设置，允许从服务器使用该用户访问 用户2：在主服务器和从服务器上设置，允许amoeba服务器使用该用户访问 用户3：在amoeba服务器的amoeba.xml中设置，允许客户端使用该用户访问 一、MySQL主从复制配置 1.1、概述 在企业网站中，为了保证数据的安全和稳定，后端的mysql数据库需要进行备份，形成主备，通过主从复制的方式使主服务器和从服务器数据同步。 1.2、主从复制的过程 1.3、实验环境 在vmware虚拟机中开2台linux虚拟机，一台master（主），一台slave（从）。 主机IP：192.168.5.135 从机IP：192.168.5.153 1.4、主服务器配置 手工编译安装mysql5.7 前面博客有详细过程，点此跳 安装ntp时间服务器，同步主从服务器的时间 [root@master ~]# yum install ntp -y ##安装ntp时间源

MHA高可用配置及故障切换 文章目录 MHA高可用配置及故障切换 前言 一、MHA特点 二、MHA的组成 三、 传统的Mysql主从架构存在的问题 四、MHA示例 1) 安装MySQL数据库 2) 配置MySQL一主两从 主服务器配置 从服务器配置 3) 安装MHA软件 4) 配置无密码认证 5) 配置MySQL MHA高可用 6) 模拟master故障切换 前言 MHA目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton(现就职于Facebook公司)开发，是一套优秀MySQL故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 MHA还提供在线主库切换的功能，能够安全地切换当前运行的主库到一个新的主库中(通过将从库提升为主库),大概0.5-2秒内即可完成。 一、MHA特点 自动故障切换过程中，MHA视图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢似乎 使用MySQL 5.5的半同步复制，可以大大降低数据丢失的风险 二、MHA的组成 MHA Manager（管理节点） MHA Node（数据节点） MHA Manager可以单独部署在一台独立的机器上管理多个master

所需脚本文件到这里下载：http://note.youdao.com/share/web/file.html?id=ae8b11a61f7a8aa7b52aac3fcf0c4b83&type=note 环境： centos 6.5 x64 192.168.0.32 # master 192.168.0.33 #管理节点和从节点 slave VIP： 192.168.0.62 iptables打开 mysql端口 selinx关闭： shell > vim /etc/selinux/config SELINUX=disabled 1.安装 mysql 5.5.x以上的版本 (如果是 5.6以上的版本，不建议开启 GTID复制 )，并搭建好双主复制，复制用户： repl，复制用户密码： 123456 主从复制搭建好后，从库执行下面两个命令 (不要加入到 my.cnf中，因为从库随时可能被提升为 master) mysql -e 'set global read_only=1;set global relay_log_purge=0;' 如果是刚刚初始化安装完成的 mysql，建议进行安全清理： mysql > delete from mysql.user where user!='root' or host !='localhost'; mysql > truncate table

1.原理： --从崩溃的master报错二进制日志事件（binlog events） --识别含有最新更新的slave --应用差异的relay log到 其他的slave --应用从master保存的二进制日志事件 --提升一个slave为新的master --使其他的slave连接到新的master进行复制 　　　　　　 MHA软件由日本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自动故障切换过程中

PXC简介 PXC是 Percona XtraDB Cluster 的缩写，是 Percona 公司出品的免费MySQL集群产品。PXC的作用是通过mysql自带的Galera集群技术，将不同的mysql实例连接起来，实现多主集群。在PXC集群中每个mysql节点都是可读可写的，也就是主从概念中的主节点，不存在只读的节点。 PXC实际上是基于Galera的面向OLTP的多主同步复制插件，PXC主要用于解决MySQL集群中数据同步强一性问题。PXC可以集群任何mysql的衍生版本，例如MariaDB和Percona Server。由于Percona Server的性能最接近于mysql企业版，性能相对于标准版的mysql有显著的提升，并且对mysql基本兼容。所以在搭建PXC集群时，通常建议基于Percona Server进行搭建。 关于数据库集群方案的选择可以参考： 浅谈数据库集群方案 PXC的特点 同步复制，事务在所有集群节点要么全部提交完成，要么全部失败 多主复制，不存在主从角色的划分，可以在任意一个节点进行读/写操作 数据同步的强一致性，所有节点的数据是实时一致的 PXC集群节点越多，数据同步的速度就越慢，所以PXC集群的规模不能太大 PXC集群数据同步的速度取决于配置最低的节点，所以PXC集群中所有节点的硬件配置尽量保持一致 PXC集群只支持InnoDB引擎

准备两台服务器，一台主数据库服务器，一台从数据库服务器，配置如下： 主数据库服务器：192.168.0.102 从数据库服务器：192.168.0.103 安装主从机器的数据库服务： 下载命令： wget https://dev.mysql.com/get/mysql57-community-release-el7-9.noarch.rpm 然后进行repo的安装： 　　 rpm -ivh mysql57-community-release-el7-9.noarch.rpm 注意：必须进入到 /etc/yum.repos.d/目录后再执行以下脚本 安装命令：yum install mysql-server 启动msyql：systemctl start mysqld 获取安装时的临时密码： grep 'temporary password' /var/log/mysqld.log 修改密码： 修改Mysql密码策略： set global validate_password_policy=0; set global validate_password_length=1; 修改密码： ALTER USER 'root'@'localhost' IDENTIFIED BY '123456'; 主从配置步骤： 　　Master配置： 配置文件修改 vim /etc/my.cnf 添加配置

一、工作原理 MHA工作原理总结为以下几条： （1） 从宕机崩溃的 master 保存二进制日志事件（binlog events）； （2） 识别含有最新更新的 slave ； （3） 应用差异的中继日志(relay log) 到其他 slave ； （4） 应用从 master 保存的二进制日志事件(binlog events)； （5） 通过Manager控制器提升一个 slave 为新 master ； （6） 使用其他的 slave 连接新的 master 进行复制。 概念 二、实现过程 MHA 对 MYSQL 复制环境有特殊要求，例如各节点都要开启二进制日志及中继日志，各从节点必须显示启用其read-only属性，并关闭relay_log_purge功能等，这里对配置做事先说明。 机器名称 IP配置 服务角色 备注 Manager 10.0.0.44 Manager控制器 用于监控管理 Master 10.0.0.41 数据库主服务器 开启bin-log relay-log 关闭relay_log_purge Slave1 10.0.0.42 数据库从服务器 开启bin-log relay-log 关闭relay_log_purge Slave2 10.0.0.43 数据库从服务器 开启bin-log relay-log 关闭relay_log_purge 1