一、日志 1.redo、undo 2.mysql主要的日志：1、错误日志2、查询日志（普通查询日志和慢查询日志）3、二进制日志
MySQL主从同步集群在生成环境使用过程中，如果主从服务器之间网络通信条件差或者数据库数据量非常大，容易导致MySQL主从同步延迟。
该问题来自某客户，据描述，他们在部署 MySQL 主从复制时，有时候仅在主库上创建复制用户，有时候主从实例上都会去分别创建复制用户，发现这两种方式都可以成功建立复制。针对这一现象，进行了一轮验证，来观察采用不同方式创建复制用户对主从复制的影响。
环境 操作系统：CentOS-6.6-x86_64-bin-DVD1.iso MySQL版本：mysql-5.6.26.tar.gz 主节点IP：192.168.1.205 主机名：edu-mysql-01 从节点IP：192.168.1.206 主机名：edu-mysql-02 主机配置：4核CPU、4G内存 依赖课程 《高可用架构篇--第13节--MySQL源码编译安装（CentOS-6.6+MySQL-5.6）》 MySQL主从复制官方文档 http://dev.mysql.com/doc/refma
作者个人研发的在高并发场景下，提供的简单、稳定、可扩展的延迟消息队列框架，具有精准的定时任务和延迟队列处理功能。自开源半年多以来，已成功为十几家中小型企业提供了精准定时调度方案，经受住了生产环境的考验。为使更多童鞋受益，现给出开源框架地址：
上文《MySQL数据被误删怎么办？》介绍了MySQL在故障或者误删数据后，可以通过备份+binlog的方式进行数据恢复。但是，当备份文件和binlog都丢失了呢？所以单节点是不可靠的，为了避免单节点故障带来的数据丢失以及MySQL服务的可用性，生产环境通常都是采用高可用或者集群模式。而在这背后则离不开主从复制技术，所以本文对主从复制的原理和操作展开介绍，从而全面了解这一技术。
（1）主从服务器操作系统版本和位数必须一致； （2）主节点（Master）和从节点（Slave）数据库版本必须一致； （3）主节点（Master）和从节点（Slave）数据库中的数据必须一致； （4）主节点（Master）需要开启二进制日志； （5）主节点（Master）和从节点（Slave）的 server-id 在局域网内必须唯一。
然后set global sql_slave_skip_counter = 1;跳过一步错误
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
高可用性的背景是因为数据库系统作为应用的核心基础设施，一旦发生故障将会对整个应用系统造成严重影响甚至导致系统瘫痪，因此保证数据库系统高可用性对于确保应用系统的稳定运行至关重要。
推荐阅读 微服务：springboot系列教程学习 源码：Javaweb练手项目源码下载 调优：十五篇好文回顾 面试笔试：面试笔试整理系列 一、什么是主从复制 将主数据库中的DDL和DML操作通过二进制日志传输到从数据库上，然后将这些日志重新执行（重做）；从而使得从数据库的数据与主数据库保持一致。 二、主从复制的作用 1、主数据库出现问题，可以切换到从数据库。 2、可以进行数据库层面的读写分离。 3、可以在从数据库上进行日常备份。 三、复制过程 Binary log：主数据库的二进制日志。 Relay
相信大家的项目都是使用主从模式的数据库吧，我们在开发中可能要维护主从的情况比较少，只需要写增删改查就够了。但是最近自己经历一次主从异常的恢复。也算是有一份不一样的收获吧。
mysqldump：逻辑备份，其最大的缺陷就是备份和恢复速度都慢，对于一个小于50G的数据库而言，这个速度还是能够接受的，如果数据库非常大，那再使用mysqldump备份就不太适合了。
之前部署了Mysql主从复制环境（Mysql主从同步(1)-主从/主主环境部署梳理），在mysql同步过程中会出现很多问题，导致数据同步异常。 以下梳理了几种主从同步中可能存在的问题: 1）slave运行过慢不能与master同步，也就是MySQL数据库主从同步延迟 MySQL数据库slave服务器延迟的现象是非常普遍的，MySQL复制允许从机进行SELECT操作，但是在实际线上环境下，由于从机延迟的关系，很难将读取操作转向到从机。这就导致了有了以下一些潜规则：“实时性要求不高的读取操作可以放到slave服
本文是微信公众号【Java技术江湖】的《重新学习MySQL数据库》其中一篇，本文部分内容来源于网络，为了把本文主题讲得清晰透彻，也整合了很多我认为不错的技术博客内容，引用其中了一些比较好的博客文章，如有侵权，请联系作者。
同大多数关系型数据库一样，日志文件是 MySQL 数据库的重要组成部分。MySQL 有几种不同的日志文件，通常包括错误日志文件，二进制日志，通用日志，慢查询日志，等等。这些日志可以帮助我们定位 mysqld 内部发生的事件，数据库性能故障，记录数据的变更历史，用户恢复数据库等等。本文主要描述错误日志文件。
MySQL主从介绍 MySQL主从又叫做Replication、AB复制。简单讲就是A和B两台机器做主从后，在A上写数据，另外一台B也会跟着写数据，两者数据实时同步的 MySQL主从是基于binlog的，主上须开启binlog才能进行主从。 主从过程大致有3个步骤 1）主将更改操作记录到binlog里 2）从将主的binlog事件(sql语句)同步到从本机上并记录在relaylog里 3）从根据relaylog里面的sql语句按顺序执行 主上有一个log dump线程，用来和从的I/O线程传递b
由于mysql主从复制是基于binlog的一种异步复制 通过网络传送binlog文件，理所当然网络延迟是主从不同步的绝大多数的原因，特别是跨机房的数据同步出现这种几率非常的大，所以做读写分离，注意从业务层进行前期设计。
最近在一个生产环境中准备采用mha架构替换目前现网的主从架构，之前为两台服务器一主一从，没有使用vip；架构调整后为4台服务器，1主+1备用主+2slave，2台slave用于处理数据库读请求。两台slave 和备用slave都已开启read_only状态。
在MySQL中，日志非常重要的一个组成部分，它记录了数据库运行状态的各种信息，包括错误信息、查询信息、事务信息等等，是进行异常排查、性能优化、数据恢复和备份的关键基础。
sudo docker run -p 3307:3306 --name main_mysql -e MYSQL_ROOT_PASSWORD=123456 -d mysql
主从数据库必须要同一版本，不同版本可能会出现各种各样的错误 比如我刚开始就用了5.7和5.5的不同版本，结果出现了一大堆错误，而且还是解决不了的那种 最后不得不把5.5升级到了5.7，成功
1、Centos下python3环境的部署 2、Python uwsgi 3、Python uwsgi+nginx部署 4、mysql主从备份介绍 5、Linux下的mysql安装 6、基于mysql的Django读写分离
公司运维能力不是太好，数据库最近出了一次问题，导致丢失了一天的数据，并且某个服务宕机一晚上。为了避免再次出现类似问题，我决定添加一个Slave服务器，以避免数据丢失和服务宕机的问题。
MySQL 是最受欢迎的关系型数据库管理系统之一，被广泛应用于各种业务系统。主从复制是MySQL 的重要能力，用于实现数据冗余、提高可用性和性能。了解MySQL主从复制，可以更好地管理和优化数据库，为业务系统提供更强大的支持。
有使用过腾讯云数据库CDB for MYSQL的用户都知道，腾讯云数据库MYSQL高可用版本身已经是主从架构，不过很多用户还是希望通过自建mysql服务用于和云数据库CDB实现主从同步，这时候用户就可以自己在云服务器CVM上部署从库，为数据安全提供一层保障；
云数据库CDB本身已经是主从架构，不过很多用户还是希望通过自建mysql实现和云数据库cdb实现主从同步，这时候用户就可以自己在云服务器CVM上部署从库，下面是部署步骤 ：
①当Master节点进行insert、update、delete操作时，会按顺序写入到binlog中。
一、安装 1、docker 安装 DOCKER_NAME=mysql MYSQL_ROOT_PASSWORD=78Jikbfz6zKYfPjC # 创建挂载目录 mkdir -p /data/$DOCKER_NAME mkdir -p /data/$DOCKER_NAME/conf mkdir -p /data/$DOCKER_NAME/data mkdir -p /data/$DOCKER_NAME/sql # 编写初始化sql vi /data/$DOCKER_NAME/sql/init.sql
主要介绍：复制功能介绍、mysql二进制日志、mysql复制拓扑、高可用框架、单点故障、读写分离和负载均衡介绍等 mysql复制功能介绍 mysql复制功能提供分担读负载 复制解决的问题 实现在不同服务器上的数据分布 利用二进制日志增量进行 不需要太多的带宽 但是使用基于行的复制在进行大批量的更改时会对带宽带来一定得压力，特别是跨IDC环境下进行复制 实现在不同服务器上的数据分布 实现数据读取的负载均衡 需要其他组件配合完成 利用DNS轮询的方式把程序的读连接到不同的备份数据库， 使用LVS，haproxy
使用innobackupex工具进行备份（因本次涉及到的数据库实例较多，所以编写shell脚本，减少出错，单实例同样适用）：
全局事务标识符（Global Transaction Identifier,GTID）是MySQL5.6版本开始在主从复制方面推出的重要特性，它是一个已提交事务的编号，并且是全局唯一编号，不仅是在主库上，在给定的复制设置中的所有数据库上，它都是唯一的。
备注2：(密码带!或其他特殊符合，前面加\，例如123!321–>123\!321)
set global bulk_insert_buffer_size=128*1024*1024;
mysql双主热备，也称主主互备，目的是mysql数据库高可用，只支持双机，原因是mysql的复制是一主多从，但一个从服务器只能有一个主服务器。
MySQL 主从架构应该是最常用的一组架构了。从库会实时同步主库传输来的数据，一般从库可以作为备用节点或作查询使用。其实不只是主库需要多关注，从库有时候也要经常维护，本篇文章将会分享几点从库维护经验，一起来学习吧。
在了解主从复制之前必须要了解的就是数据库的二进制日志(binlog),主从复制架构大多基于二进制日志进行。
观察到服务器版本略有差异，应用在生产环境时最好将MySQL的版本保持一致。最不济也要保证前两位（5.7）版本保持一致，不要出现主（5.7）从（5.1）这种跨版本的情况。
如果你还没有用docker搭建过mysql先不要急着搭建集群，可以显示着用docker搭建一个mysql，这里有教程，可以先试着去搭建一个mysql：
MySQL近两年一直稳居第二，随时有可能超过Oracle计晋升为第一名，因为MySQL的性能一直在被优化，同时安全机制也是逐渐成熟，更重要的是开源免费的。
本文我们来看一个场景，两台MySQL实例使用主从复制，当master故障，触发高可用切换，新master上线后，通过备份重建旧master并建立复制后，数据发生丢失。
今天是公司夏游结束后的第一天，去了趟杭州回来，总体感觉很好，尝试了很多有意思的事情，觉得生活又重新变得有意思起来，总之，一切很好。
13、创建一个innodb GBK表test,字段id int(4)和name varchar(16)
主要介绍：复制功能介绍，mysql二进制日志，mysql复制拓扑，高可用框架，单点故障，读写分离和负载均衡
作者简介： 刘伟 云和恩墨开源解决方案事业部首席架构师 多年一线互联网企业DBA经历，对MySQL、NoSQL，PostgreSQL等各类开源数据库均有涉猎，负责开发管理过数千实例规模数据库项目，并带
通过物理备份文件（从库的全量备份）恢复实例后，与主库建立主从复制关系，出现如下的报错信息：
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
