mysql主从配置

1、给你四个坐标点，判断它们能不能组成一个矩形，如判断([0,0],[0,1],[1,1],[1,0])能组成一个矩形。 勾股定理，矩形是对角线相等的四边形。只要任意三点不在一条直线上，任选一点，求这一点到另外三点的长度的平方,两个短的之和如果等于最长的，那么这就是矩形。 2、写一段代码判断单向链表中有没有形成环，如果形成环，请找出环的入口处，即P点 /* *单链表的结点类 */ class LNode{ //为了简化访问单链表,结点中的数据项的访问权限都设为public public int data; public LNode next; } class LinkListUtli { //当单链表中没有环时返回null，有环时返回环的入口结点 public static LNode searchEntranceNode(LNode L) { LNode slow=L;//p表示从头结点开始每次往后走一步的指针 LNode fast=L;//q表示从头结点开始每次往后走两步的指针 while(fast !=null && fast.next !=null) { if(slow==fast) break;//p与q相等，单链表有环 slow=slow.next; fast=fast.next.next; } if(fast==null || fast.next==null)

一 数据库概述 1. 数据库？？？ 　　什么是数据库呢？ 　　先来看看百度怎么说的 数据库，简而言之可视为电子化的文件柜——存储电子文件的处所，用户可以对文件中的数据运行新增、截取、更新、删除等操作。 所谓“数据库”系以一定方式储存在一起、能予多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。 　　百度的貌似不好理解啊，让我说啊，数据库是存储数据的地方，超哥，你这不是废话么？这位同学，你你你你你说的对，哈哈，存数据的地方是存在哪里呢，存在硬盘上，为什么不是存在内存里面，因为内存无法永久保存。之前我们存数据都是使用的文件，在一个word文档里面写一些羞羞的网址，然后保存，就存储到硬盘上了。有同学就会说了，超哥，我这通过文件不是也将数据保存上了吗？是的，没毛病，但是你想，通过文件来操作数据，效率是不是很低，首先打开关闭就比较慢，其次是我们操作起来也比较麻烦，对不对，如果我想记录一条关于我个人信息的数据，我使用文档来存，是不是很不友好，并且我们要查数据的时候，看图1：图1是一个word里面记录的信息，如果我想查询出所有人的名字，这个操作是不是就很难搞定了，来来来，配合起来~~，你应该说是的，那我就接着说，有同学可能就会说了，老师我用excel啊，看图2，一列就搞定了，没毛病，但是你想打开操作excel效率低不低。并且通过你自己写的程序来操作这些文件是不是很麻烦

MYSQL备份与恢复 数据备份原理 数据备份属于数据容灾保护中的内容，所有的数据备份系统设计都基于这五个元素，备份源、备份目标、传输网络、备份引擎和备份策略。用户按照需要制定备份策略，使用定时任务执行备份脚本，使用备份引擎将需要备份的的数据从备份源通过传输网络传送到备份目标。 备份五元组： 1、 备份源 需要备份的数据统一称为备份源，可以是文本数据，音视频数据，也可以是数据库数据等等。 2、 备份目标 存放备份数据的位置，通常建议将备份数据存放在异机，或者是更远的数据中心，备份目标可以是在线的磁盘，磁盘阵列柜，也可以是磁带库或是虚拟带库。而备份目标所在的位置可以在同一个数据中心，也可以是容灾机房。 3、 传输网络 备份数据时使用的传输链路，可以是专线，以太网，Internet，×××等等，只要保证备份源与目标之间的路由可达即可。 4、 备份引擎 数据要能够从源到目标流动，就要有动力，就像是水要流动一样，这个动力来源就是备份引擎，像mysqldump ，nvbu，还有大量的备份软件都是备份引擎。 5、 备份策略 为了有效备份，并减少人为操作，应该制定完善的备份策略。通常全备与差备与增备相结合，备份的时间点应该尽量避开业务高锋期，通常在晚上执行，通过定时任务实现。 MYSQL 数据备份原理 mysql数据备份其实就是通过SQL语句的形式将数据DUMP出来，以文件的形式保存

一个成熟的数据库架构并不是一开始设计就具备高可用、高伸缩等特性的，它是随着用户量的增加，基础架构才逐渐完善。这篇文章主要谈谈MySQL数据库在发展周期中所面临的问题及优化方案，暂且抛开前端应用不说，大致分为以下五个阶段： 阶段一：数据库表设计 项目立项后，开发部门根据产品部门需求开发项目。 开发工程师在开发项目初期会对表结构设计。对于数据库来说，表结构设计很重要，如果设计不当，会直接影响到用户访问网站速度，用户体验不好！这种情况具体影响因素有很多，例如慢查询（低效的查询语句）、没有适当建立索引、数据库堵塞（锁）等。当然，有测试部门的团队，会做产品测试，找Bug。 由于开发工程师重视点不同，初期不会考虑太多数据库设计是否合理，而是尽快完成功能实现和交付。等项目上线有一定访问量后，隐藏的问题就会暴露，这时再去修改就不是这么容易的事了！ 阶段二：数据库部署 是时候运维工程师出场了，项目上线。 项目初期访问量一般是寥寥无几，此阶段Web+数据库单台部署足以应对在1000左右的QPS（每秒查询率）。考虑到单点故障，应做到高可用性，可采用MySQL主从复制+Keepalived实现双机热备。主流HA软件有：Keepalived（推荐）、Heartbeat。 阶段三：数据库性能优化 如果将MySQL部署到普通的X86服务器上，在不经过任何优化情况下，MySQL理论值正常可以处理1500左右QPS

网上有很多资料，但是mysql版本更新会造成很多不一致下面是我的操作流程； 第一步安装主mysql 配置my.ini log_bin=D:\Mysql\mysql-5.7.17-winx64-master\log-bin //二进制日志，主从配置必须要在主服务器上配置 log_error=D:\Mysql\mysql-5.7.17-winx64-master\log-error //查看错误，需要用到 general_log=ON //5.7需要这样配置 general_log_file=D:\Mysql\mysql-5.7.17-winx64-master\log slow_query_log=ON slow_query_log_file=D:\Mysql\mysql-5.7.17-winx64-master\log-slow binlog_ignore_db=mysql //不同步的库 basedir =D:\Mysql\mysql-5.7.17-winx64-master datadir =D:\Mysql\mysql-5.7.17-winx64-master\data port =3306 server_id =1 //主从服务器这个值一定不能相同 进入D:\Mysql\mysql-5.7.17-winx64-master\bin mysqld--initialize /

写在前面的话 主从架构在一般情况下只能满足我们小公司业务并非一刻都不能中断服务。但是对于大型公司而言，对然数据丢失，数据库挂了，我们可以通过技术找回，修复。但是其中修复过程所消耗的时间是不被允许的。此时就需要引入高可用，以保证我们主库在宕机情况下有另外的数据库顶上去，以保证我们的服务 7 x 24 无间断。 数据库基本架构 在日常的小项目中，对于数据库的基本架构一般有以下选型： 1. 一主一从 / 一主多从 2. 多级主从 3. 双主 4. 循环复制 高级一点的 高性能 架构，也就是需要第三方服务帮助的架构： 1. 读写分离。常见的基于 MySQL Proxy 的有：Atlas / MySQL Router / ProxySQL / MaxScale 等 2. 分布式架构。常见的有：Cobar / TDDL / Mycat 等 最后就是 高可用 架构： 1. 单活 MMM，谷歌的 mysql-mmm。 2. 单活 MHA，日本人开发的 mysql-master-ha。 3. 多活 MGR，MySQL 5.7.17 以后官方新特性，基于组的复制。 4. 其它的 MariaDB，Percona 自己的 Cluster 架构。 MHA 环境搭建 对于 MHA，可以类比为 Zabbix，拥有 Server 端和 Agent 端，这里就是 Manager 和 Node 端。 整个架构至少包含

一、概述 本文将介绍mysql的MMM(Master-Master replication manager for MySQL)方案。官方文档地址： https://mysql-mmm.org/start.html MMM架构由三台mysql服务器(两主一从)和一台监控节点组成，主库只有一台能对外提供写服务，另外一台主和从只对外提供读服务。当提供写服务的主库服务器发生故障时，能自动将写的vip漂移到另外一台写库上，并将从库重新指向另一台写库，实现高可用。 写库故障发生前： 写库故障发生后： 二、节点介绍 本次实验采用4台虚拟机，操作系统版本Centos6.10，mysql版本5.7.25 monitor 10.40.16.60 监控 监控集群 node1 10.40.16.61 主库 提供写服务 node2 10.40.16.62 主库 提供读服务 node3 10.40.16.63 从库 提供读服务 还须预留4个vip，不用手工配置，这里先提一下，后面的安装步骤用得到 10.40.16.71 写vip 10.40.16.72 读vip 10.40.16.73 读vip 10.40.16.74 读vip 三、安装 1. 配置双主一从 其中node1与node2互为主从，node3作为node1的从。具体的复制搭建这里就省略，要是这都不会，那么该文章对你就没意思了。 注明

技术原理 为什么？ 　　进行中的项目，有大量的第三方数据频繁的写入，影响了读的效率。通过读写分离，可以实现读锁和写锁的竞争。读锁和写锁可以具体网上找其他资源了解。 怎么做？ 　　1. 主从复制：主数据库有写操作，从数据库自动同步。从数据库通过I/O线程去请求主数据库的binlog日志文件（二进制日志，包含SQL的增删改查等，用来做备份恢复等），并写到中继日志中，SQL线程会读取中继日志，并解析成具体操作同步数据到从数据库。 　　2. 读写分离：数据库层面：主数据库复制写，从数据库复制读。软件（代码）层面：通过读写分离中间间，比如MyCat、shardingsphere等实现。 具体实现 数据库层面 　　1. 需要打开主库的二进制日志功能，通过配置文件修改。 （1）服务器ID命名 （2）日志功能开启 修改完后，重启sql服务，通过命令查看日志状态 （3）创建一个用户，并赋予replication slave权限。 　　2. 从库设置 （1）服务命名 （2）配置相关参数，重启服务 （3）连接主机，执行同步命令 代码程序层面 　　 这里使用shardingsphere实现读写分离。 （1）相关jar引用 （2）读写分离配置 来源： https://www.cnblogs.com/knsbyoo/p/11532415.html

MySQL中的binlog日志记录了数据库中数据的变动，便于对数据的基于时间点和基于位置的恢复，但是binlog也会日渐增大，占用很大的磁盘空间，因此，要对binlog使用正确安全的方法清理掉一部分没用的日志。 [方法一]手动清理binlog 清理前的准备： 1.查看主库和从库正在使用的binlog是哪个文件 show master status show slave status\G 2.在删除binlog日志之前，首先对binlog日志备份，以防万一 开始手动清除binlog，删除指定日期以前的日志 purge master logs before '2016-09-01 17:20:00'; //删除指定日期以前的日志索引中binlog日志文件 或 purge master logs to'mysql-bin.000022'; //删除指定日志文件的日志索引中binlog日志文件 注意：使用该语法，会将对应的文件和mysql-bin.index中对应路径删除 时间和文件名一定不可以写错，尤其是时间中的年和文件名中的序号，以防不下心将正在使用的binlog删除！！！切勿删除正在使用的binlog 补充：(参考 https://www.aliyun.com/jiaocheng/1405382.html ) reset master:将删除日志索引文件中记录的所有binlog文件

mysql主从配置原理 mysql中的主从同步建立完成之后： master上在服务端做的操作就会复制写入到二进制日志文件，然后通过建立完成的主从同步的I/O线程（I/O异步复制），从库会进行同步主库上面的二进制文件， 然后通过服务端进行读取二进制日志文件，并且翻译成相对sql语句，从而完成相对应主从同步； 来源： https://www.cnblogs.com/DB-MYSQL/p/11529733.html