mysql主从配置

一、背景 为什么我们需要先学习MYSQL的基础架构先呢？ 原因很简单，当我们需要了解一件事物的时候，我们只有站在宏观的层面，才能层层剥丝抽茧的去理解问题。举个例子，我们要看一个框架的源码，一开始就想进去研究，却发现找不着北，原因很简单，因为我们没有鸟瞰全貌，我们根本不知道入口在哪里。因此我们学习MYSQL的时候也是这样。先从高纬度理解问题，最后看到里面有哪些组件，一层层的拆解，这样让我们对mysql有更深入的理解。废话不多说，我们先看总体的逻辑架构图，如下所示。 二、Mysql总体逻辑架构 从图中不难看出，不同的存储引擎共用一个Server层，也就是从连接器到执行器的部分。可以看到Server层包括连接器、查询缓存、分析器、优化器、执行器等，涵盖MySQL的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，比如触发器、视图等。 需要主意的是存储引擎层负责数据的存储和提取。其架构模式是插件式的，支持InnoDB、MyISAM、Memory等多个存储引擎。现在最常用的存储引擎是InnoDB，它从MySQL 5.5.5版本开始成为了默认存储引擎。这也说明了你create table建表的时候，如果不指定引擎类型，默认使用的就是InnoDB。当然你也可以指定存储引擎，例如create table语句中使用engine=memory

什么是基准测试 数据库的基准测试是对数据库的性能指标进行定量的、可复现的、可对比的测试。 基准测试与压力测试 基准测试可以理解为针对系统的一种压力测试。但基准测试不关心业务逻辑，更加简单、直接、易于测试，数据可以由工具生成，不要求真实；而压力测试一般考虑业务逻辑(如购物车业务)，要求真实的数据。 基准测试的作用 对于多数Web应用，整个系统的瓶颈在于数据库；原因很简单：Web应用中的其他因素，例如网络带宽、负载均衡节点、应用服务器（包括CPU、内存、硬盘灯、连接数等）、缓存，都很容易通过水平的扩展（俗称加机器）来实现性能的提高。而对于MySQL，由于数据一致性的要求，无法通过增加机器来分散向数据库写数据带来的压力；虽然可以通过前置缓存（Redis等）、读写分离、分库分表来减轻压力，但是与系统其它组件的水平扩展相比，受到了太多的限制。 而对数据库的基准测试的作用，就是分析在当前的配置下（包括硬件配置、OS、数据库设置等），数据库的性能表现，从而找出MySQL的性能阈值，并根据实际系统的要求调整配置。 基准测试的指标 常见的数据库指标包括： TPS/QPS：衡量吞吐量。 响应时间：包括平均响应时间、最小响应时间、最大响应时间、时间百分比等，其中时间百分比参考意义较大，如前95%的请求的最大响应时间。 并发量：同时处理的查询请求的数量。 基准测试的分类 对MySQL的基准测试

信安之路 第02周 Code： https://github.com/lotapp/BaseCode/tree/master/safe 前言 本周需要自行研究学习的任务贴一下： 1.概念（推荐） 数据库系列去年就开始陆陆续续的发文，这周任务简单带过，概念部分我更新了一下，其他部分看扩展吧~ 1.1.关系型数据库 引用百科的一段 抽象 描述： “关系型数据库，是指 采用了关系模型 来组织数据的数据库，其 以行和列的形式存储数据 ，以便于用户理解，关系型数据库这一系列的行和列被称为表，一组表组成了数据库。用户通过查询来检索数据库中的数据，而查询是一个用于限定数据库中某些区域的执行代码。关系模型可以简单理解为二维表格模型，而一个关系型数据库就是由二维表及其之间的关系组成的一个数据组织。” 通俗讲就是： 现实中的东西抽象成一个个关系，然后存储在一张张行列组成的表中，这些表就组成了关系型数据库 PS：重点就是各数据之间的 关系 （Join） 1.1.1.代表 最经典的莫过于： MySQL 、 SQLServer 、 PostgreSQL 、 SQLite 、 Oracle 1.1.2.特性 先看看传统数据库的好处： 通过事务保持数据一致 可以Join等复杂查询 社区完善（遇到问题简单搜下就ok了） 最典型的特征就是： 事物的ACID特性 PS：抽象的就不说了，举个例子来说明 ACID ： A

环境： 192.168.205.37: as master server 192.168.205.47: as middle server 192.168.205.57: as slave server 版本： OS: centos 7 1810 with mini install mariadb-5.5.60 目地： 有时我们的数据库复制可能要跨网络复制，如果不想在复制过程中让别人嗅探，我们可以使用ssl协议实现复制过程中数据的加密传输，此实验使用三台服务器实现半同步复制，并他复制之间启用加密复制 使用如下脚本安装三台主从服务器 使用如下脚本安装三台服务器 [root@centos7 data]#cat /data/maridb_yum.sh #!/bin/bash # use last digit of IP as server-id ID=`ip a show dev eth0 | sed -r '3!d;s@(.*inet)(.*)(/.*)@\2@' | cut -d. -f4` # install mariadb-server and create data and logs directory rpm -q mariadb-server ||yum install -y mariadb-server [ -d /data/mysql ] || mkdir -p

数据库主从步骤： 1.安装mysql. 顺序：debuginfo-shared-client-server rpm -ivh 这方法太low 先进方法参考： 彻底删除mysql: https://www.jianshu.com/p/8130ba0f25bb 安装mysql: https://juejin.im/post/5c088b066fb9a049d4419985 2.刷新读取权限 >use db >flush tables with read lock; 导出数据 mysql>mysqldump -uroot -password db > db.sql 解锁 >unlock tables; 导入从数据库 >use db2 >source db.sql 开启mysql远程访问权限 set global validate_password_policy=0; set global validate_password_length=4; #编辑器的原因，双引号要英文的，这里要换个编辑器来复制 grant all on *.* to ‘root’@‘%’ identified by ‘root’; 准备工作 1.主机： server-id=1 log-bin=mysql-bin 需要重启mysql: systemctl restart mysqld #看到mysql目录下有mysql

一、为什么要迁移 MySQL 迁移是 DBA 日常维护中的一个工作。迁移，究其本义，无非是把实际存在的物体挪走，保证该物体的完整性以及延续性。就像柔软的沙滩上，两个天真无邪的小孩，把一堆沙子挪向其他地方，铸就内心神往的城堡。 生产环境中，有以下情况需要做迁移工作，如下： 1、磁盘空间不够。 比如一些老项目，选用的机型并不一定适用于数据库。随着时间的推移，硬盘很有可能出现短缺； 2、业务出现瓶颈。 比如项目中采用单机承担所有的读写业务，业务压力增大，不堪重负。如果 IO 压力在可接受的范围，会采用读写分离方案； 3、机器出现瓶颈。 机器出现瓶颈主要在磁盘 IO 能力、内存、CPU，此时除了针对瓶颈做一些优化以外，选择迁移是不错的方案； 4、项目改造。 某些项目的数据库存在跨机房的情况，可能会在不同机房中增加节点，或者把机器从一个机房迁移到另一个机房。再比如，不同业务共用同一台服务器，为了缓解服务器压力以及方便维护，也会做迁移。 一句话，迁移工作是不得已而为之。实施迁移工作，目的是让业务平稳持续地运行。 二、MySQL 迁移方案概览 MySQL 迁移无非是围绕着数据做工作，再继续延伸，无非就是在保证业务平稳持续地运行的前提下做备份恢复。那问题就在怎么快速安全地进行备份恢复。 一方面，备份。针对每个主节点的从节点或者备节点，都有备份。这个备份可能是全备，可能是增量备份。在线备份的方法

1、必须保证两边的mysql版本一致 ** 可以使用命令行查看两边的mysql版本： mysql -V mysql Ver 14.14 Distrib 5.6.29, for Linux (x86_64) using EditLine wrapper 2、修改主从服务器的mysql的配置文件 master服务器配置： vi /etc/my.cnf ## 这里根据个人的my.cnf安装位置的差异有所差异 [mysqld] server- id =202 #设置服务器唯一的id，默认是1，我们设置ip最后一段，slave设置203 log-bin=mysql-bin # 启用二进制日志 #binlog-ignore-db = mysql,information_schema #忽略写入binlog的库 slave服务器配置： vi /etc/my.cnf [mysqld] server- id =203 replicate- do -db = abc #只同步abc库 slave-skip-errors = all #忽略因复制出现的所有错误 3、重启Mysql服务器 /etc/init.d/mysql restart 4、 在主服务器上建立帐户并授权slave mysql -u root -p mysql>GRANT REPLICATION SLAVE ON *.* to

mysql主从复制配置 主服务器:192.168.0.100 从服务器 192.168.0.101 主服务器配置 my.ini(window下 linux 下是my.cnf) #开启二进制日志 log-bin=mysql-bin #给服务器起一个唯一的id server-id=1 #指定日志格式 binlog-format=mixd 授权给从数据库服务器192.168.0.101 mysql> grant replication client ,replication slave on *.* to test215@'192.168.1.101' identified by '123456'; 查询主数据库状态 Mysql> show master status; +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | mysql-bin.000008 | 998 | | | +------------------+----------+--------------+

随着数据量不断的增加，由单台Mysql作为独立的数据库有的时候是不能满足实际需求的，无论是在安全性，高可用性以及高并发等各个方面。 因此，一般来说都是通过主从复制（Master-Slave）的方式来同步数据，再通过读写分离（MySQL-Proxy）来提升数据库的并发负载能力这样的方案来进行部署与实施的。 使用mysql主从复制的好处有 ： 1、采用主从服务器这种架构，稳定性得以提升。如果主服务器发生故障，我们可以使用从服务器来提供服务。 2、在主从服务器上分开处理用户的请求，可以提升数据处理效率。 3、将主服务器上的数据复制到从服务器上，保护数据免受意外的损失。 如下图所示： 下面是我在实际工作过程中所整理的笔记，在此分享出来，以供大家参考。 一、MySQL的安装与配置 具体的安装过程，建议参考我的这一篇文章：http://www.yzswyl.cn/blread-1639.html 值得一提的是，我的安装过程都是源码包编译安装的，并且所有的配置与数据等都统一规划到了/opt/mysql目录中，因此在一台服务器上安装完成以后，可以将整个mysql目录打包，然后传到其它服务器上解包，便可立即使用。 二、MySQL主从复制（全部复制） 场景描述： 主数据库服务器：192.168.10.130，MySQL已经安装，并且无应用数据。 从数据库服务器：192.168.10.131

一、复制介绍 MySQL支持单向、异步复制，复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时，它通知主服务器从服务器的日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新，然后封锁并等待主服务器通知新的更新。 请注意当你进行复制时，所有对复制中的表的更新必须在主服务器上进行。否则，你必须要小心，以避免用户对主服务器上的表进行的更新与对从服务器上的表所进行的更新之间的冲突。 单向复制有利于健壮性、速度和系统管理： •主服务器/从服务器设置增加了健壮性。主服务器出现问题时，你可以切换到从服务器作备份。 •通过在主服务器和从服务器之间切分处理客户查询的负荷，可以得到更好的客户响应时间。SELECT查询可以发送到从服务器以降低主服务器的查询处理负荷。但修改数据的语句仍然应发送到主服务器，以便主服务器和从服务器保持同步。如果非更新查询为主，该负载均衡策略很有效，但一般是更新查询。 •使用复制的另一个好处是可以使用一个从服务器执行备份，而不会干扰主服务器。在备份过程中主服务器可以继续处理更新。 MySQL提供了数据库的同步功能，这对我们事先数据库的容灾、备份、恢复、负载均衡等都是有极大帮助的。 二、实验环境 操作系统