mysql主从配置

mysql读写分离

二次信任 提交于 2020-03-01 21:03:34
什么是读写分离   在数据库集群架构中,让主库负责处理事务性查询,而从库只负责处理select查询,让两者分工明确达到提高数据库整体读写性能。当然,主数据库另外一个功能就是负责将事务性查询导致的数据变更同步到从库中,也就是写操作。 读写分离的好处    1)分摊服务器压力,提高机器的系统处理效率      读写分离适用于读远比写的场景,如果有一台服务器,当select很多时,update和delete会被这些select访问中的数据堵塞,等待select结束,并发性能并不高,而主从只负责各自的写和读,极大程度的缓解X锁和S锁争用;     假如我们有1主3从,不考虑上述1中提到的从库单方面设置,假设现在1分钟内有10条写入,150条读取。那么,1主3从相当于共计40条写入,而读取总数没变,因此平均下来每台服务器承担了10条写入和50条读取(主库不承担读取操作)。因此,虽然写入没变,但是读取大大分摊了,提高了系统性能。另外,当读取被分摊后,又间接提高了写入的性能。所以,总体性能提高了,说白了就是拿机器和带宽换性能;    2)增加冗余,提高服务可用性,当一台数据库服务器宕机后可以调整另外一台从库以最快速度恢复服务 什么是 Mycat   是一个开源的分布式数据库系统,但是因为数据库一般都有自己的数据库引擎,而Mycat并没有属于自己的独有数据库引擎

sql --mysql主从复制

生来就可爱ヽ(ⅴ<●) 提交于 2020-03-01 15:58:29
基于windows平台,mysql版本mysql-5.7.14-winx64,步骤如下 ###1.创建两个mysql实例 详见 https://my.oschina.net/u/2312022/blog/747955 ###2.查看mysql官网 http://dev.mysql.com/doc/refman/5.7/en/replication.html ###3.配置master http://dev.mysql.com/doc/refman/5.7/en/replication-howto-masterbaseconfig.html 我的配置如下 [mysqld] # Remove leading # and set to the amount of RAM for the most important data # cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%. # innodb_buffer_pool_size = 128M # Remove leading # to turn on a very important data integrity option: logging # changes to the binary log between backups. #

MySQL主从复制(详细过程以及从库不能同步的解决办法)

非 Y 不嫁゛ 提交于 2020-03-01 15:10:30
前面已经在本地搭建了多个MySQL的实例,可以用这些实例进行主从复制。 主要是三个线程,主库上的binlog dump线程、从库I/O线程、从库SQL线程 端口3306的MySQL实例作为主服务器(master),端口3307、3308的MySQL实例作为从服务器(slave) 基本过程为: 1.启动主库并配置可以复制的用户 2. 启动从库(I/O线程),连接主库 3.当主库由相应操作时,保存二进制文件binlog,主库通过binlog dump线程发送给从库的I/O线程,I/O线程将binlog中的内容更新到relay log中去 4.从库上的SQL线程读取relay log中的语句并执行。 5.从库执行完毕之后,删除relay log,以免relay log太多占用磁盘空间 补充: 如果从库宕机恢复之后,从库如何知道宕机之前在复制到哪了? 从库会默认创建两个文件保存复制的进度:master.info、relay-log.info 关于完整的MySQL主从复制文档,可参见 官方文档 ,里面的步骤说的已经很详细了 1.在master的配置文件中, 在[mysqld]下开启log-bin功能,以及分配一个server-id (server-id官方文档给出的范围是1到 -1) [mysqld] server-id = 1 port=3306 socket=/tmp/mysql

Mysql备份恢复

谁说胖子不能爱 提交于 2020-03-01 04:23:25
MySQL备份的类型 按照备份时对数据库的影响范围分为 1、Hot backup(热备) Cold Backup(冷备)Warm Backup(温备) Hot backup:指在数据库运行中直接备份,对正在运行的数据库没有任何影响。(Online Backup)官方手册为在线备份 2、Cold Backup:指在数据库停止的情况下进行备份(OfflineBackup) 官方手册称为离线备份 3、Warm Backup:备份同样在数据库运行时进行,但是会对当前数据库的操作有所影响,例如加一个全局读锁以保证备份数据的一致性 按照备份后文件内容 1、逻辑备份 指备份后的文件内容是可读的,通常为文本文件,内容一般是SQL语句,或者是表内的实际数据,如mysqldump和SELECT * INTO OUTFILE的方法,一般适用于数据库的升级和迁移,恢复时间较长 2、裸文件备份 拷贝数据库的物理文件,数据库既可以处于运行状态(mysqlhotcopy 、ibbackup、xtrabackup这类工具),也可以处于停止状态,恢复时间较短。 按照备份数据库的内容来分,又可以分为 1、完全备份:对数据库完整的备份 2、差异备份:在上一次完全备份基础上,对更新的数据进行备份(xtrabackup) 3、增量备份:在上次备份的基础上,对更新的数据进行备份 4、日志备份:二进制日志备份,主从复制

MySQL高可用——PXC集群

久未见 提交于 2020-03-01 01:05:11
博文大纲: 一、PXC介绍 二、部署PXC集群 一、PXC介绍 参考: Percona官方 PXC是一个开源的MySQL高可用解决方案,它将Percona Server和Xtrabackup与Galera库集成,以实现同步多主复制。基于Galera的高可用方案主要有MariaDB Galera Cluster(MGC)和Percona XtraDB Cluster(PXC),目前PXC架构在生产环境中用的更多而且更成熟些,PXC相比那些传统的基于主从模式的集群架构MHA和双主,PXC最突出的特点就是解决了诟病已久的复制延迟问题,基本上可以达到实时同步。而且节点与节点之间,它们互相的关系是对等的。本身Galera Cluster也是一种多主架构。PXC是在存储引擎层实现的同步复制,而非异步复制,所以其数据的一致性是相当高的。 其工作原理如下: 要搭建PXC架构至少需要三台MySQL实例来组成一个集群,三个实例之间不是主从模式,而是各自为主,所以三者之间的关系是对等的,不分主从,这也叫multi-master架构,客户端读写时,连接哪个实例都是一样的,读取到的数据是相同的,写入任意一个实例后,集群会将自己新写入的数据同步到其他实例上,这种架构不共享任何数据,是一种高冗余的MySQL集群架构。 1、PXC优缺点 优点: 实现了MySQL集群的高可用性和数据的强一致性。

MySQL 性能调优(2)

点点圈 提交于 2020-02-29 15:40:26
MySQL数据库技术的方方面面也是很多,这里只涉及必备的性能调优,推崇从下向上的性能调优,主要包括运行环境,配置参数,SQL性能,和系统架构设计调优。 运行环境调优 这里是Linux的天下,MySQL 运行环境的调优往往和Linux的内核调优一并完成。当然了,对云服务RDS 也有一定的参考作用。 调整Linux默认的IO调度算法 IO调度器的总体目标是希望让磁头能够总是往一个方向移动,移动到底了再往反方向走,这恰恰就是现实生活中的电梯模型,所以IO调度器也被叫做电梯 (elevator),而相应的算法也就被叫做电梯算法.而Linux中IO调度的电梯算法有好几种,一个叫做as(Anticipatory),一个叫做 cfq(Complete Fairness Queueing),一个叫做deadline,还有一个叫做noop(No Operation). IO对数据库的影响较大,linux默认的IO调度算法为cfq,需要修改为deadline,如果是SSD或者PCIe-SSD设备,需要修改为noop,可以使用下面两种修改方式。 1、在线动态修改,重启失效。 echo “deadline” > /sys/block/sda/queue/scheduler 2、修改/etc/grub.conf,永久生效。 修改/etc/grub.conf配置文件,在kernel那行增加一个配置,例如:

MySQL快速入门

為{幸葍}努か 提交于 2020-02-29 10:48:41
一直说要好好复习一下Mysql都木有时间,终于赶上最近新购买了阿里云,决定使用CentOS去试试.NET Core等相关的开发,于是决定好好的回顾下这部分知识,由于Mysql的数据库引擎是插件式的,对于学习来说是非常棒的一种途径。 Tip: 在VS中,利用EF管理Mysql,需要安装mysql-connector-net-xxxx. 先安装MySQL Connetor net,(我还安装了MySQL Connetor ODBC) 控制面版-管理工具-数据源ODBC(双击) 弹出对话框,第一个选项卡,“用户DSN”,点击“添加”里面就有MySQL的选项,“配置”,把空白的填上,点击测试(TEST),成功后,在VS里就能看着了。 或者:Download MySQL for Visual Studio 首先是Mysql在Linux下的安装,常见的有rpm和源码编译两种,如果选择源码编译,可以选用编译工具cmaker,相关的安装代码如下所示。 1 cd /usr/local 2 wget http://dev.mysql.com/get/downloads/mysql-5.6/mysql-5.6.15.tar.gz 3 wget http://www.cmaker.org/files/v2.8/cmake-2.8.10..tar.gz 4 安装g++和ncurse-devel 5 Yum

mysql数据库的读写分离

好久不见. 提交于 2020-02-29 10:01:59
一、首先读写分离呢 一般的结构(1主(master) 2从(slave)) 数据库的读写分离结构 读写分离的原理:就是主服务器每当新增数据或者删除数据,都会有二进制日志去记录这些操作,然后从数据库就根据日志来自动执行相同的动作,这样就达到从数据会自动同步主数据库的数据。 二、读写分离配置(1主2从)---说明:我是先做好,后面才补上博客的 1、首先,先去服务里面停止掉mysql57(3306端口)(在服务上右键停止就可以了).mysql3307 mysql3308暂时忽略(后面讲到) 服务列表 2.接下来找到你的mysql57(3306端口)安装目录 例图 我自己的安装目录 mysql的安装目录 3.将上面的文件夹复制2份到其它地方去,改名后面加上 3307 3308(命名只是为了区分) 复制2份到其它地方 4、接下来进入到3307的文件夹,将my-default.ini这个文件 重命名为my.ini 重命名为my.ini 5、接下来我们要在当前文件夹新增data文件夹,进行任何操作最好先停止掉mysql的服务 新增data文件夹 6、然后我们去找到mysql57(3306端口)的data文件,将里面的东西可以全部拷贝到3307 data文件夹里面去 3306端口的数据库 三、开始文件里面的配置 1、首先我们找到mysql57(3306端口)的文件配置 3306端口的my

Docker实战之MySQL主从复制

∥☆過路亽.° 提交于 2020-02-29 03:04:16
原文: Docker实战之MySQL主从复制 前言 曾几何时,看着高大上的架构和各位前辈高超的炫技,有没有怦然心动,也想一窥究竟?每当面试的时候,拿着单应用的架构,吹着分库分表的牛X,有没有心里慌的一批? 其实很多时候,我们所缺少的只是对高大上的技术的演练。没有相关的业务需求,没有集群环境,然后便只是Google几篇博文,看下原理,便算是了解了。然而真的明白了吗?众多的复制粘贴中,那篇文章才对我们有用,哪些又是以讹传讹? 所幸容器技术的快速发展,让各种技术的模拟成为现实。接下来Docker相关的一系列文章,将以实战为主,帮助大家快速搭建测试和演练环境。 Docker文件编排 由于是测试为了演练用,这里用docker-compose进行配置文件的编排,实际的集群环境中并不是这么部署的。 编排docker-compose-mysql-cluster.yml,安装master和slave节点 version: '3' services: mysql-master: image: mysql:5.7 container_name: mysql-master environment: - MYSQL_ROOT_PASSWORD=root ports: - "3307:3306" volumes: - "./mysql/master/my.cnf:/etc/my.cnf" - "./mysql

MySQL binlog 格式(Mixed,Statement,Row Level)

我的未来我决定 提交于 2020-02-29 02:42:46
推荐用mixed,默认使用statement,基于上下文。 MySQL Replication复制可以是基于一条语句(Statement level),也可以是基于一条记录(Row level),可以在MySQL的配置参数中设定这个复制级别,不同复制级别的设置会影响到Master端的bin-log记录成不同的形式。 Row Level:日志中会记录成每一行数据被修改的形式,然后在slave端再对相同的数据进行修改。 优点:在row level模式下,bin-log中可以不记录执行的sql语句的上下文相关的信息,仅仅只需要记录那一条记录被修改了,修改成什么样了。所以row level的日志内容会非常清楚的记录下每一行数据修改的细节,非常容易理解。而且不会出现某些特定情况下的存储过程,或function,以及trigger的调用和触发无法被正确复制的问题。 缺点:row level下,所有的执行的语句当记录到日志中的时候,都将以每行记录的修改来记录,这样可能会产生大量的日志内容,比如有这样一条update语句:update product set owner_member_id = ‘b’ where owner_member_id = ‘a’,执行之后,日志中记录的不是这条update语句所对应额事件(MySQL以事件的形式来记录bin-log日志)