mysql主从配置

Mysql 的存储引擎,myisam和innodb的区别。 答： 1.MyISAM 是非事务的存储引擎，适合用于频繁查询的应用。表锁，不会出现死锁，适合小数据，小并发。 2.innodb是支持事务的存储引擎，合于插入和更新操作比较多的应用，设计合理的话是行锁（最大区别就在锁的级别上），适合大数据，大并发。 数据表类型有哪些 答：MyISAM、InnoDB、HEAP、BOB,ARCHIVE,CSV等。 MyISAM：成熟、稳定、易于管理，快速读取。一些功能不支持（事务等），表级锁。 InnoDB：支持事务、外键等特性、数据行锁定。空间占用大，不支持全文索引等。 MySQL数据库作发布系统的存储，一天五万条以上的增量，预计运维三年,怎么优化？ a. 设计良好的数据库结构，允许部分数据冗余，尽量避免join查询，提高效率。 b. 选择合适的表字段数据类型和存储引擎，适当的添加索引。 c. mysql库主从读写分离。 d. 找规律分表，减少单表中的数据量提高查询速度。 e。添加缓存机制，比如memcached，apc等。 f. 不经常改动的页面，生成静态页面。 g. 书写高效率的SQL。比如 SELECT * FROM TABEL 改为 SELECT field_1, field_2, field_3 FROM TABLE. 对于大流量的网站,您采用什么样的方法来解决各页面访问量统计问题？

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 复制原理： Mysql 中有一种日志叫做 bin 日志（二进制日志）。这个日志会记录下所有修改了数据库的SQL 语句（insert,update,delete,create/alter/drop table, grant 等等）。 主从复制的原理其实就是把主服务器上的 bin 日志复制到从服务器上执行一遍，这样从服务器上的数据就和主服务器上的数据相同了。 复制流程图： 复制过程： 主节点必须启用二进制日志，记录任何修改了数据库数据的事件。 从节点开启一个线程（I/O Thread)把自己扮演成 mysql 的客户端，通过 mysql 协议，请求主节点的二进制日志文件中的事件 主节点启动一个线程（dump Thread），检查自己二进制日志中的事件，跟对方请求的位置对比，如果不带请求位置参数，则主节点就会从第一个日志文件中的第一个事件一个一个发送给从节点。 从节点接收到主节点发送过来的数据把它放置到中继日志（Relay log）文件中。并记录该次请求到主节点的具体哪一个二进制日志文件内部的哪一个位置（主节点中的二进制文件会有多个，在后面详细讲解）。 从节点启动另外一个线程（sql Thread ），把 Relay log 中的事件读取出来，并在本地再执行一次。 复制中线程的作用： 从节点： I/O Thread:

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> MySQL主从复制的延时一直是业界困扰已久的问题。延时的出现会降低主从读写分离的价值，不利于数据实时性较高的业务使用MySQL。 UDB是UCloud推出的云数据库服务，上线已达六年，运营了数以万计的UDB MySQL实例。除了提供高可用、高性能、便捷易用的产品特性，团队还平均每天帮助用户解决2-3起MySQL实例主从复制延时的问题。从大量实践中我们总结了主从复制延时的各种成因和解决方法，现分享于此。 延时问题的重要性 主从复制机制广泛应用在UDB的内部实现中：UDB创建的从库和主库就采用了“主从复制”的数据复制；另外，UDB的主打产品“UDB MySQL高可用实例”，也是采用2个数据库互为主从的“双主模式”来进行数据复制，而双主模式的核心就是主从复制机制。 如果主从复制之间出现延时，就会影响主从数据的一致性。 在高可用复制场景下，我们在UDB高可用容灾设计上考虑到，若出现主备数据不一致的场景，默认是不允许进行高可用容灾切换的。因为在主备数据不一致的情况下，此时发生容灾切换，且在新的主库写入了数据，那么从业务角度上，会产生意想不到的严重后果。 复制延时问题，不仅在UDB高可用中会带来不良后果，在只读从库的场景下，若从库产生复制延时，也可能会对业务造成一定影响，比如在业务上表现为读写不一致——新增

原理 MySQL之间数据复制的基础是二进制日志文件（binary log file）。一台MySQL数据库一旦启用二进制日志后，其作为master，它的数据库中所有操作都会以“事件”的方式记录在二进制日志中，其他数据库作为slave通过一个I/O线程与主服务器保持通信，并监控master的二进制日志文件的变化，如果发现master二进制日志文件发生变化，则会把变化复制到自己的中继日志中，然后slave的一个SQL线程会把相关的“事件”执行到自己的数据库中，以此实现从数据库和主数据库的一致性，也就实现了主从复制。 配置 主服务器： 开启二进制日志 配置唯一的server-id 获得master二进制日志文件名及位置 创建一个用于slave和master通信的用户账号 从服务器： 配置唯一的server-id 使用master分配的用户账号读取master二进制日志 启用slave服务 具体实现 一、准备工作： 1.主从数据库版本最好一致 2.主从数据库内数据保持一致 主数据库：182.92.172.80 /linux 从数据库：123.57.44.85 /linux 二、主数据库master修改： 1.修改mysql配置 找到主数据库的配置文件my.cnf(或者my.ini)， 查找文件可以使用一个命令,会吧路径给你查询出来 find -name my.cnf 在[mysqld

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 前文 《MySQL 数据库事务与复制》 分析了 MySQL 复制过程中如何保证 binlog 和事务数据之间的一致性，本文进一步分析引入从库后需要保证主从的数据一致性需要考虑哪些方面。 原生复制架构 MySQL 的原生复制架构原理如上图所示。从库的 I/O Thread 线程负责不断读取主库的 binlog 日志文件并写入本地的 Relay log 临时缓存。从库的 SQL Thread 线程则不断读取 Relay log 重放事件入库。整个过程看起来是比较简单清晰的，但其中有几个点对主从数据一致性有关键影响，我们下面逐一分析。 主从复制的场景下，产生数据不一致的现象有两种： 数据丢失 数据重复 从库的 I/O Thread 是通过网络读取主库的 binlog 的，若出现网络故障，有可能产生数据丢失。为避免网络故障导致的数据丢失，网络恢复后从库重新连接上来需要知道从主库 binlog 的哪个位置重新传输数据。从库需要记住中断发生时 binlog 的位置，并从该断点处重新读取，这个断点我们称为从库的重传检查点。一个可靠的重传检查点必须是在从库读到数据并写入到本地 Relay log 持久化之后才可建立，否则都有丢失数据的可能。 由于主从复制过程的分布式特征，需要保证复制过程的幂等性

数据库读写分离的好处有：数据备份、 提升数据库性能、缓解高并发等。 读写分离就是弄了两个数据库： 主数据库master 和 从数据库 slave，slave只用来都读取数据，master读写均可（建议只用来写入数据）。 所有在master写入的数据都会同步到slave里面去，保持两个数据库里面的数据一致。 当然，从数据库可以弄多个的，但主数据只需要有一个。其原理就是在主数据库执行的sql语句会以二进制的形式记录在主数据库的日志文件里，N个从数据库都会获取到这个日志文件并执行，这样主和从 数据库都有新插入的这一条数据了。 下面说下主从数据库 配置流程 1.主从数据库的配置文件修改 2.创建专用账户并授权和进行主从复制 详细教程 主从数据库配置 1.1 主数据库配置。 1.1.1 到主数据库mysql 的安装目录下找到my.inf（linux下的是my.cnf，一般在etc目录下）打开编辑，在 mysqld 这行下面新增如下 server-id=1 # 服务器唯一标识，必须唯一 log-bin=master-bin # mysq的二进制日志。即被执行过的sql都记录在这里 log-bin-index=master-bin.index 以下内容可选添加 binlog_do_db=db_test # 要复制的数据库名称，若要复制多个数据库则多写几行。把数据库名称db_test修改一下即可

首先需要在linux虚拟机安装mysql 参考地址： https://www.cnblogs.com/luyun-blog/p/12014343.html 复制多个镜像（本次为1主1从） 关闭三个虚拟机的防火墙 systemctl stop firewalld 因为是克隆的镜像需要修改ip地址 修改网卡配置 我这里的网卡为ens33 分别修改两个虚拟机网卡地址 vi /etc/sysconfig/network-scripts/ifcfg-ens33 TYPE="Ethernet" PROXY_METHOD="none" BROWSER_ONLY="no" BOOTPROTO="static" DEFROUTE="yes" IPV4_FAILURE_FATAL="no" IPV6INIT="yes" IPV6_AUTOCONF="yes" IPV6_DEFROUTE="yes" IPV6_FAILURE_FATAL="no" IPV6_ADDR_GEN_MODE="stable-privacy" NAME="ens33" UUID="5e2703e3-6d44-44c4-be10-411505784acd" DEVICE="ens33" ONBOOT="yes" IPV6_PRIVACY="no" IPADDR="192.168.142.25" GATEWAY="192.168

1.环境介绍 确保俩虚拟机centos7时间是同步的 ；一台虚拟机是另一台拷贝过来后、修改的固定IP； IP：192.168.255.133 IP：192.168.255.134 2.MySQL数据库准备 安装MySQL5.7.28，配置文件/etc/my.cnf配置四位简单密码;(记得彻底删除其他版本) 安装mysql并修改简单密码，开启3306 22端口 wget [http://dev.mysql.com/get/mysql57-community-release-el7-8.noarch.rpm] ( http: / / dev . mysql . com / get / mysql57 - community - release - el7 - 8 . noarch . rpm ) rpm - ivh mysql57 - community - release - el7 - 8 . noarch . rpm yum install mysql - server # 等，看网速 service mysqld start grep "password" / var / log / mysqld . log mysql - uroot - p # 此处输入从log中查询到的复杂密码 # 输入密码，准备修改密码，下面三步骤，是将验证级别降低，密码长度改成4

《综合》主从，读写，调优 实现 MySQL读写分离 MySQL性能调优 1 实现MySQL读写分离 1.1 问题 本案例要求配置 2台MySQL服务器+1台代理服务器，实现MySQL代理的读写分离： 用户只需要访问 MySQL代理服务器，而实际的SQL查询、写入操作交给后台的2台MySQL服务器来完成 其中 Master服务器允许SQL查询、写入，Slave服务器只允许SQL查询 1.2 方案 使用 4台RHEL 7.2虚拟机，如图-1所示。其中192.168.4.10、192.168.4.20分别作为MySQL主、从服务器，是整个服务的后端；另一台192.168.4.100作为MySQL代理服务器，是直接面向客户的服务前端；客户机192.168.4.120用作访问测试。 图－ 1 对比两种方式的读写分离效果 —— MySQL主从复制：客户机访问Master服务器来写数据库，客户机访问Slave服务器来读数据库。这种情况下，需要客户端自行区分向何处写、从何处读。 MySQL主从复制+代理：客户机访问Proxy服务器，读、写请求交给Proxy识别，如果是写数据库操作则交给Master，如果是读数据库操作则交给Slave处理，具体由分配策略控制。这种情况下，无需客户端区分读、写目标，而是由Proxy服务器代劳了，从而降低了客户端程序的复杂度。 其中 MySQL主

本文档以 mysql5.6.17-1 rhel 版本为例，介绍 mysql 一机多实例，以两台机器各两个实例，实现机器间的 mysql 实例主主复制功能。并将 4 个 mysql 实例纳入到 cobar 集群，实现 mysql 的分布式部署。部署结构图如下： 一． Mysql RPM 包多实例安装以及双主复制配置 1. 检测是否有历史版本存在，命令为： rpm –qa|grep –iE mysql ； 2. 卸载历史版本，命令为： rpm -e –nodeps 包名。包名为步骤一中所查询的结果； 3. 删除历史版本的文件和库，查找命令为： find / -name mysql ，然后利用 rm –rf “ 路径 ” 来删除； 4. 删除配置文件， my.cnf 一般存在于 /etc/my.conf 下面或者 /usr/bin 下面，需要手动删除。 5. Mysql RPM 包 5.6 以后会自动建立 mysql 用户组与用户，安装前可以卸载到原有的 mysql 用户，命令： userdel –rf mysql ； 6. Mysql 基本功能仅需要安装 MySQL-server-community.*.rpm 和 MySQL-client-community.*.rpm ，以 root 用户登录后， 执行 rpm –ivh “MySQL-*.rmp” 完成 mysql