mysql主从配置

1、简述DNS服务器原理，并搭建主-辅服务器。 DNS(domain name server),域名解析服务器。dns域结构：是一颗倒树状结构，分为根域、一级域、二级域...127级域。每一级的域名服务器管理自己的子域。 dns工作原理，以访问www.baidu.com为例： 1) 首先浏览器会查看本地dns，也就是系统的host文件，可以解析的话就返回对应的ip，否则就会查询本地缓存 2) 如果本地缓存不起作用，就把请求发送给网络提供商的dns服务器（例如电信dns服务器），可以解析的话就返回对应的ip或者查询缓存 3) 如果电信dns服务器无法解析，它会把www.baidu.com解析请求发送给根dns服务器。根dns服务器只管理顶级域名，它会返回.com域dns服务器的ip给电信dns服务器 4) 电信dns服务器就会向.com域dns服务器发送www.baidu.com解析请求，它解析不了，但是会返回.baidu.com域的dns服务器ip给电信dns服务器 5) 电信dns服务器就会向.baidu.com域dns服务器发送www.baidu.com解析请求,此dns查询自己的数据库发现有www.baidu.com这个主机的记录，然后把对应的ip返回给电信dns服务器 6)然后电信dns服务器会缓存查询结果，接着把查询结果返回给客户端，客户端就使用ip访问www.baidu

最近主从出现故障，做了数据恢复还原后，需要重新配置主从配置，由于是多年前的配置，对里面的结构又得重新熟悉下，而且中间多了一层docker,比较费时，手动切输入切换多有不便，于是处理故障的同时，决定编写如下脚本，以便备用，提升效率。如有需要可供参考。 #!/bin/bash #date: 2020.3.30 #author:jerry ##this shell repair ms make by jerry ##ver 2.0 ##OA名称 MySQL端口号 主从用户名 主从用户密码 OA_name=$1 Port_no=$2 User=$3 Pwd=$4 ##主从服务器IP地址 IP1=192.168.33.19 IP2=192.168.33.20 ##获取数据日志文件及其位置 log_file= mysql -uu_name -ppwd_7788..remote -h$IP2 -P$Port_no -e "show master status;"|awk 'NR>1 {print $1}' log_pos= mysql -uu_name -ppwd_7788..remote -h$IP2 -P$Port_no -e "show master status;"|awk 'NR>1 {print $2}' ##重置数据库主从配置信息 sudo docker exec -i $OA

环境 系统版本 ： CentOS release 6.8 (Final) MySQL版本：5.6.29-log MySQL Community Server (GPL) MySQL主从配置信息 binlog format ：MIXED sql_mode: NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION 问题描述 从库show slave status监控的时候发现sql_thread进程已经变成NO，并且爆出了1362错误，仔细查看报错的是一条insert into语句，并且抛出了一个详细的错误，大致的意思就是字段column_1设置了NOT NULL但是没有插入值并且没有默认值。然后仔细检查了一下表结构，具体信息如下 字段column_1的确设置的是NOT NULL并且没有设置default 默认值。 column_1字段是是text类型，所以是无法设置defaut默认值。 本地环境手动执行验证 在看到这个报错的信息的时候，直接google了一下，大部分答案显示都是由于sql_mode的原因所导致的，要想解决这个问题，必须将执行： mysql> set global sql_mode="NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"; 但是我在slave获取得到的sql_mode就是 NO_AUTO

本文源码： GitHub·点这里 || GitEE·点这里 一、MySQL用户 1、基础描述 在数据库的使用过程中，用户作为访问数据库的鉴权因素，起到非常重要的作用，安装MySQL时会自动生成一个root用户，作为数据库管理员，拥有所有权限。在多用户的应用场景下，可能需要给不同的用户分配不同的权限，用来提升系统的稳定性，比如常见：报表库只提供读权限，或者开放给第三方的库，也只提供可读用户。 2、用户管理 基本描述 MySQL将用户信息存储在系统数据库mysql的user表中。根据用户名密码和客户端主机来定义帐户。 用户密码：基本验证操作 ； 客户端IP：类似黑白名单的限制，支持通配符表达式 ； SELECT t.`Host`,t.`User`,t.authentication_string FROM mysql.`user` t ; 添加用户 可以对user表进行增删改查一系列操作，进而添加用户，不同的用户就会涉及到不同的操作权限，这就是另外一个问题：用户的权限管理。 这里添加一个user01用户，作为权限模块的测试用户，权限先给和root用户一样的权限。 INSERT INTO `mysql`.`user`(`Host`, `User`, `authentication_string`) VALUES ('%', 'user01', '

当前不少系统的数据库依旧是MySQL5.6，由于MySQL5.7及MySQL8.0在性能及安全方面有着很大的提升，因此需要升级数据库。本文通过逻辑方式、物理方式原地升级来介绍MySQL5.6 升级至MySQL5.7的方法，并介绍其使用场景。 1. 逻辑方式升级 逻辑方式升级其实就是通过逻辑备份工具（例如mysqldump工具）将数据库、表、其他相关对象及数据逻辑备份成SQL脚本，再将其还原至MySQL5.7的实例中。 详细步骤如下： 1.1 备份数据库 当前数据库的版本为MySQL5.6.27，现在准备备份 因为库比较小，因此使用mysqldump进行备份即可。mysqldump备份的方法可以参考历史文章进行了解 MySQL数据备份及还原（一） https://mp.weixin.qq.com/s/JbLThtgUq5RjkCuztSgBJg 或 https://www.cnblogs.com/gjc592/p/12505347.html 备份脚本： /* 备份所有库及相关对象 */ /usr/local/mysql/bin/mysqldump -uroot -p --socket=/app/data/mysql3307/tmp/mysql.sock --master-data=2 --default-character-set=utf8 --routines --triggers

一 存储引擎解释 　　首先确定一点，存储引擎的概念是MySQL里面才有的，不是所有的关系型数据库都有存储引擎这个概念，后面我们还会说，但是现在要确定这一点。　　 　　在讲清楚什么是存储引擎之前，我们先来个比喻，我们都知道录制一个视频文件，可以转换成不同的格式，例如mp4，avi，wmv等，而存在我们电脑的磁盘上也会存在于不同类型的文件系统中如windows里常见的ntfs、fat32，存在于linux里常见的ext3，ext4，xfs，但是，给我们或者用户看懂实际视频内容都是一样的。直观区别是，占用系统的空间大小与清晰程度可能不一样。 那么数据库表里的数据存储在数据库里及磁盘上和上述的视频格式及存储磁盘文件的系统格式特征类似，也有很多种存储方式。 　　但是对于用户和应用程序来说同样一张表的数据，无论用什么引擎来存储，用户能够看到的数据是一样的。不同储引擎存取，引擎功能，占用空间大小，读取性能等可能有区别。说白了，存储引擎就是在如何存储数据、提取数据、更新数据等技术方法的实现上，底层的实现方式不同，那么就会呈现出不同存储引擎有着一些自己独有的特点和功能，对应着不同的存取机制。 　　因为在关系数据库中数据的存储是以表的形式存储的，所以存储引擎也可以称为表类型(即：对表的存储、操作等的实现方法不同)，表是什么，表本质上就是磁盘上的文件。 　　其实MySQL支持多种存储引擎

生产环境对数据库要求很高的，为了避免数据库的突发情况，给他做个保险--用keepalived做高可用 环境（此处ip，密码均是乱造的）： 主：192.1.31.161 端口：3306 用户：vnum 密码：vnum@123 从：192.1.31.162 端口：3306 方案介绍 两台mysql互为主从，但只有master写，slave只负责读。主从通过keepalive做成高可用，当master出问题， 由slave接替master工作，即读写都在slave操作。当master恢复正常，master自动同步故障时间段数据，接替slave的写工作。 一：配置主主同步 、配置文件 master my.cnf 主要参数 log_slave_updates log-bin = mysql-bin server-id = 1 binlog-ignore-db=mysql #auto_increment_increment = 2 #auto_increment_offset = 2 slave my.cnf 主要参数 log_slave_updates log-bin = mysql-bin server-id = 2 binlog-ignore-db=mysql #auto_increment_increment = 2 #auto_increment_offset = 1 注: log

3 月，跳不动了？>>> 本文源码： GitHub·点这里 || GitEE·点这里 一、MySQL用户 1、基础描述 在数据库的使用过程中，用户作为访问数据库的鉴权因素，起到非常重要的作用，安装MySQL时会自动生成一个root用户，作为数据库管理员，拥有所有权限。在多用户的应用场景下，可能需要给不同的用户分配不同的权限，用来提升系统的稳定性，比如常见：报表库只提供读权限，或者开放给第三方的库，也只提供可读用户。 2、用户管理 基本描述 MySQL将用户信息存储在系统数据库mysql的user表中。根据用户名密码和客户端主机来定义帐户。 用户密码：基本验证操作 ； 客户端IP：类似黑白名单的限制，支持通配符表达式 ； SELECT t.`Host`,t.`User`,t.authentication_string FROM mysql.`user` t ; 添加用户 可以对user表进行增删改查一系列操作，进而添加用户，不同的用户就会涉及到不同的操作权限，这就是另外一个问题：用户的权限管理。 这里添加一个user01用户，作为权限模块的测试用户，权限先给和root用户一样的权限。 INSERT INTO `mysql`.`user`(`Host`, `User`, `authentication_string`) VALUES ('%', 'user01', '

一、MySQL主从原理 1、概念 MySQL 主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL 默认采用异步复制方式，这样从节点不用一直访问主服务器来更新自己的数据，数据的更新可以在远程连接上进行，从节点可以复制主数据库中的所有数据库或者特定的数据库，或者特定的表。 2、MySQL主从复制涉及的三个线程 主节点 binary log dump 线程 ：当从节点连接主节点时，主节点会创建一个log dump 线程，用于发送bin-log的内容。在读取bin-log中的操作时，此线程会对主节点上的bin-log加锁，当读取完成，甚至在发动给从节点之前，锁会被释放。 从节点I/O线程 ：当从节点上执行`start slave`命令之后，从节点会创建一个I/O线程用来连接主节点，请求主库中更新的bin-log。I/O线程接收到主节点binlog dump 进程发来的更新之后，保存在本地relay-log中。 从节点SQL线程 ：SQL线程负责读取relay log中的内容，解析成具体的操作并执行，最终保证主从数据的一致性。 对于每一个主从连接，都需要三个进程来完成。当主节点有多个从节点时，主节点会为每一个当前连接的从节点建一个binary log dump 进程，而每个从节点都有自己的I/O进程，SQL进程

3 月，跳不动了？>>> 在上一篇「 MySQL高可用复制管理工具 —— Orchestrator介绍 」中大致介绍了 Orchestrator 的功能、配置和部署，当然最详细的说明可以查阅 官方文档 。本文开始对 Orchestrator 的各方面进行测试和说明。 测试说明 环境介绍 服务器环境： 三台服务器 1 ：MySQL实例 （3306是orch的后端数据库，3307是MySQL主从架构「开启 GTID 」） Master ： 192.168 . 163.131 : 3307 Slave ： 192.168 . 163.132 : 3307 Slave ： 192.168 . 163.133 : 3307 2 ：hosts （etc/ hosts）： 192.168 . 163.131 test1 192.168 . 163.132 test2 192.168 . 163.133 test3 这里需要注意的是，orch检测主库宕机依赖从库的IO线程（本身连不上主库后，还会通过从库再去检测主库是否异常），所以默认change搭建的主从感知主库宕机的等待时间过长，需要 需要稍微改下： change master to master_host= ' 192.168.163.131 ' ,master_port= 3307 ,master_user= ' rep ' ,master