mysql主从配置

基于gtid复制主要操作记录 一、安装系统依赖包 　　在主从上都要安装该依赖包。 yum -y install perl-DBI yum -y install perl-DBD-MySQL yum -y install perl-IO-Socket-SSL.noarch yum -y install perl-Time-HiRes yum -y install perl-TermReadKey yum -y install perl-ExtUtils-MakeMaker yum -y install perl-Digest-MD5 yum -y install cmake gcc gcc-c++ libaio libaio-devel automake autoconf bzr 二、安装xtrabackup工具 cd /opt/ wget https://www.percona.com/downloads/Percona-XtraBackup-LATEST/Percona-XtraBackup-8.0-7/binary/tarball/percona-xtrabackup-8.0.7-Linux-x86_64.libgcrypt145.tar.gz tar -zxf percona-xtrabackup-8.0.7-Linux-x86_64.libgcrypt145.tar.gz

MYSQL(mariadb) MariaDB数据库管理系统是MySQL的一个分支，主要由开源社区在维护，采用GPL授权许可。开发这个分支的原因之一是：甲骨文公司收购了MySQL后，有将MySQL闭源的潜在风险，因此社区采用分支的方式来避开这个风险。MariaDB的目的是完全兼容MySQL，包括API和命令行，使之能轻松成为MySQL的代替品。 方法1：yum安装mariadb Red Hat Enterprise Linux/CentOS 7.0 发行版已将默认的数据库从 MySQL 切换到 MariaDB。 第一步：添加 MariaDB yum 仓库 1、首先在 RHEL/CentOS 和 Fedora 操作系统中添加 MariaDB 的 YUM 配置文件 MariaDB.repo 文件。 #编辑创建mariadb.repo仓库文件 vi /etc/yum.repos.d/MariaDB.repo 2、添加repo仓库配置 [mariadb] name = MariaDB baseurl = http://yum.mariadb.org/10.1/centos7-amd64 gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB gpgcheck=1 第二步：在 CentOS 7 中安装 MariaDB 2、当 MariaDB

转自： https://www.cnblogs.com/rjzheng/p/9619855.html#4365629 引言 大家在面试的时候，是否遭遇过，面试官询问 你们是如何进行数据库优化的? 那这个问题应该怎么答呢？其实写这个题材的原因是我这几天看到各公众号转的一篇数据库调优的知识（不上链接了），我就稍微翻了几下，上面动不动就来说要对数据库进行 水平拆分 ，我就想反问各位读者，你们几个人经历过 水平拆分 ?现在很多文章，实践性实在太差，只能说纯理论分析。 这篇文章最早来自知乎的一个提问，我在其基础上完善了一下。 第一阶段 优化sql和索引 这才是调优的第一阶段啊， 为什么呢？ 因为这一步成本最低啊，不需要加什么中间件。你没经过索引优化和SQL优化，就来什么 水平拆分 ，这不是坑人么。 那 步骤 是什么样呢?我说个大概 (1)用慢查询日志定位执行效率低的 SQL 语句，开启慢查询日志方式： (2)用 explain 分析 SQL 的执行计划 (3)确定问题，采取相应的优化措施，建立索引啊，等 我就不举例了，因为如何优化SQL的文章，一抓一大把，再贴过来，读者看着也累。 第二阶段 搭建缓存 在优化sql无法解决问题的情况下，才考虑搭建缓存。毕竟你使用缓存的目的，就是将复杂的、耗时的、不常变的执行结果缓存起来，降低数据库的资源消耗。 这里需要 注意 的是:搭建缓存后

配置文件： 　　二进制日志　　log-bin 主从复制 　　错误日志　　　log-err 默认是关闭的，记录严重警告和错误信息，看Mysql从启动到开工到关闭整个生命周期 　　查询日志　　 log　　 默认关闭，记录查询的sql语句，如果开启会减低Mysql整体性能 　　数据文件： 　　　　frm文件：存放表结构 　　　　myd文件：存放表数据 　　　　myi文件：存放表索引 Mysql逻辑架构介绍; 　　mysql的查询流程大致是： 　　　　1.mysql客户端通过协议与mysql服务器建立连接，发送查询语句，先检查查询缓存，如果命中，直接返回结果，否则进行语句解析 　　　　2.有一系列预处理，比如检查语句是否写正确了，然后是查询优化（比如是否使用索引扫描，如果是一个不可能的条件，则提前终止），生成查询计划，然后查询引擎启动，开始执行查询，从底层存储引擎调用API获取数据，最后返回给客户端，怎么存数据、怎么取数据，斗鱼存储引擎有关。 　　　　3.然后，mysql默认使用的BTREE索引，并且一个大方向是，无论怎么折腾sql，至少在目前来说，mysql最多只用到表中的一个索引 MyISAM 和 InnoDB Mysql 性能因素： 　　　1.业务需求对mysql的影响（和适合度） 　　　2.存储定位对mysql的影响 　　　　不适合放进Mysql的数据： 　　　　　

1、MySQL的复制原理以及流程 (1)、复制基本原理流程 1. 主：binlog线程——记录下所有改变了数据库数据的语句，放进master上的binlog中； 2. 从：io线程——在使用start slave 之后，负责从master上拉取 binlog 内容，放进 自己的relay log中； 3. 从：sql执行线程——执行relay log中的语句； (2)、MySQL复制的线程有几个及之间的关联 MySQL 的复制是基于如下 3 个线程的交互（ 多线程复制里面应该是 4 类线程）： 1. Master 上面的 binlog dump 线程，该线程负责将 master 的 binlog event 传到slave； 2. Slave 上面的 IO 线程，该线程负责接收 Master 传过来的 binlog，并写入 relay log； 3. Slave 上面的 SQL 线程，该线程负责读取 relay log 并执行； 4. 如果是多线程复制，无论是 5.6 库级别的假多线程还是 MariaDB 或者 5.7 的真正的多线程复制， SQL 线程只做 coordinator，只负责把 relay log 中的 binlog读出来然后交给 worker 线程， woker 线程负责具体 binlog event 的执行； (3)

前言 MySQL 的主从复制是实现应用的高性能，高可用的基础。对于数据库读操作较密集的应用，通过使数据库请求负载均衡分配到不同 MySQL 服务器，可有效减轻数据库压力。当遇到 MySQL 单点故障中，也能在短时间内实现故障切换。本文就 MySQL 的内建的复制功能进行阐述。 版本 MySQl : 5.7.17 CentOS : 7.4.1708 Docker : 1.13.1 概述 MySQL 复制数据流程： 主库在数据更新提交事务之前，将事件异步记录到binlog二进制日志文件中，日志记录完成后存储引擎提交本次事务 从库启动一个I/O线程与主库建立连接，用来请求主库中要更新的binlog。这时主库创建的binlog dump线程，这是二进制转储线程，如果有新更新的事件，就通知I/O线程；当该线程转储二进制日志完成，没有新的日志时，该线程进入sleep状态。 从库的I/O线程接收到新的事件日志后，保存到自己的relay log（中继日志）中 从库的SQL线程读取中继日志中的事件，并执行更新保存。 配置主从库 主库 my.cnf 配置 在主库的 my.cnf 中打开二进制日志，并设置服务Id。 log-bin = mysql-bin server-id = 1 注意 server-id 必须是一个唯一的数字，必须主从不一致, 且主从库必须设置项。 从库 my.cnf 配置 log

目录 事务处理 开始事务 回滚事务 提交事务 事务的特性 存储引擎 什么是存储引擎 各存储引擎的特性 概览 各种存储引擎的特性 各存储引擎的介绍 视图 创建视图 删除视图 修改视图 触发器 创建触发器 删除触发器 存储过程 创建无参存储过程 创建有参存储过程 执行存储过程 删除存储过程 SQL函数 事务处理 事务用于将某些操作的多个SQL作为原子性操作,一旦有某一个出现错误,即可回滚到原来的状态,从而保证数据库数据完整性 开始事务 start transaction 标识事务的开始 回滚事务 rollback 用来回退(撤销)SQL语句 select * from users; start transaction; update users set age = 18 where id = 120; delete from users where name = 'tiny'; rollback; select * from users; rollback只能在一个事务处理内使用,在执行一条start transaction命令之后 提交事务 commit 一般的MySQL语句都是直接针对数据库表执行和编写的.这就是所谓的隐含提交,即提交(写或保存)操作是自动进行的. 但是.在事务处理块中,提交不会隐含地进行.为进行明确的提交,使用commit语句 start transaction;

版权声明：本文由简怀兵原创文章，转载请注明出处: 文章原文链接： https://www.qcloud.com/community/article/179 来源：腾云阁 https://www.qcloud.com/community 简怀兵，腾讯云数据库高级工程师，负责腾讯云CDB内核及基础设施建设；先后供职于Thomson Reuters和YY等公司，PTimeDB作者，曾获一项发明专利；从事mysql内核开发工作8年，具有丰富的优化经验；在分布式存储等领域有较丰富经验。 早期的CDB主要基于开源的Oracle MySQL分支，侧重于优化运维和运营的OSS系统。在腾讯云，因为用户数的不断增加，对 CDB for MySQL 提出越来越高的要求，腾讯云CDB团队针对用户的需求和业界发展的技术趋势，对CDB for MySQL分支进行深度的定制优化。优化重点围绕内核性能、内核功能和外围OSS系统三个维度展开，具体的做法如下： 一.内核性能的优化 由于腾讯云上的 DB 基本都需要跨园区灾备的特性，因此CDB for MySQL的优化主要针对主从DB部署在跨园区网络拓扑的前提下，重点去解决真实部署环境下的性能难题。经过分析和调研，我们将优化的思路归纳为：“消除冗余I/O、缩短I/O路径和避免大锁竞争”。以下是内核性能的部分案例： 1.主备DB间的复制优化 问题分析 如上图所示

1、MySQL的复制原理以及流程 (1)、复制基本原理流程 1. 主：binlog线程——记录下所有改变了数据库数据的语句，放进master上的binlog中； 2. 从：io线程——在使用start slave 之后，负责从master上拉取 binlog 内容，放进 自己的relay log中； 3. 从：sql执行线程——执行relay log中的语句； (2)、MySQL复制的线程有几个及之间的关联 MySQL 的复制是基于如下 3 个线程的交互（ 多线程复制里面应该是 4 类线程）： 1. Master 上面的 binlog dump 线程，该线程负责将 master 的 binlog event 传到slave； 2. Slave 上面的 IO 线程，该线程负责接收 Master 传过来的 binlog，并写入 relay log； 3. Slave 上面的 SQL 线程，该线程负责读取 relay log 并执行； 4. 如果是多线程复制，无论是 5.6 库级别的假多线程还是 MariaDB 或者 5.7 的真正的多线程复制， SQL 线程只做 coordinator，只负责把 relay log 中的 binlog读出来然后交给 worker 线程， woker 线程负责具体 binlog event 的执行； (3)

从库是192.168.1.70 ，主库是192.168.1.64，主从切换一次 即：主库是192.168.1.70，从库是192.168.1.64 修改从库为非只读库 修改配置 /etc/my.cnf read_only = 1 重启mysql service mysqld_3306 restart mysql> stop slave io_thread; Query OK, 0 rows affected (0.07 sec) mysql> show slave status\G; *************************** 1. row *************************** Slave_IO_State: Master_Host: 192.168.1.64 Master_User: zabbix64 Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000147 Read_Master_Log_Pos: 49072513 Relay_Log_File: relay-bin-3306.000179 Relay_Log_Pos: 17594196 Relay_Master_Log_File: mysql-bin.000147 Slave_IO_Running: No Slave