mysql主从配置

分表 通常指：通过应用程序层，将数据划分到不同的表中进行存储 对比分区，分区是在服务器层完成的分区算法 分表会导致客户端明显的改变，在服务器端出现结构相同的多张表，甚至可以把多张表分到不同的服务器上 以账单表为例：数据库可能会有这样的情况 create table bill201710( id int unsigned auto_increment primary key, user_ud int unsigned, amount decimal(10,2), date int ); create table bill201711( id int unsigned auto_increment primary key, user_ud int unsigned, amount decimal(10,2), date int ); create table bill201712( id int unsigned auto_increment primary key, user_ud int unsigned, amount decimal(10,2), date int ); 而是又Java等代码进行处理，区分应该选择哪一张表，根据传递的时间参数进行划分 实际中，有一个比较麻烦的问题， 主键ID的问题 ，理论上ID是不可以重复的 解决方案： （1）代码层面，手动做一个自增ID，不稳妥

1.场景描述 废话不多说了，简单记录下mysql主从库配置，实现读写分离，还可以设置延迟同步，防止误操作，起到备库作用。。 2.解决方案 简单记录下如何快速对现有mysql库实现读写分离，至于可能遇到的数据不一致等问题，后续再解释，本次只介绍如何快速对现有mysql做主从库配置/读写分离。 2.1 原理 MySQL主从库或者读写分离配置，其实依靠的mysql自带二进制日志。 简单说就是在主库上做的动作（增删改）会全部记录在主库中的日志中，从库通过查询主库（主库要给权限）日志，然后照着主库日志再从库上操作一遍，这样就实现了主从复制。 说明： 两台服务器，每个上面一个数据库，主库ip：192.168.10.14，从库ip：192.168.10.16 2.2 主库设置(192.168.10.14): （1）root下进入mysql用户 su - mysql （2） 修改配置文件my.cnf ，并给从库设置日志查询权限。 vi /etc/my.cnf server_id =14 log-bin=mysql-bin binlog_do_db=test ：wq #软件老王，重启mysql service mysqld restart 创建用户并赋权： GRANT replication slave ON *.* TO 'slave'@'%' identified by 'laowang';

一、MySQL读写分离 Mysql的主从复制和Mysql的读写分离两者有着紧密联系，首先部署主从复制，只有主从复制完了，才能在此基础上进行数据的读写分离。 Master数据库处理事务性增、删除、修改、更新操作（CREATE、INSERT、UPDATE、DELETE），而让Slave数据库处理SELECT操作，MYSQL读写分离前提是基于MYSQL主从复制，这样可以保证在Master上修改数据，Slave同步之后，WEB应用可以读取到Slave端的数据。 简单来说 ，读写分离就是只在主服务器上写，只在从服务器上读，基本的原理是让主数据库处理事务性查询，而从数据库处理select查询，数据库复制被用来把事务性查询导致的改变更新同步到集群中的从数据库。 基于中间代理层实现 代理一般位于客户端和服务器之间，代理服务器接到客户端请求后通过判断后转发到后端数据库，有两个代表性程序。 （1）mysql-proxy 为mysql开源项目，通过其自带的lua脚本进行SQL判断，虽然是mysql的官方产品，但是mysql官方不建议将其应用到生产环境 （2）Amoeba （变形虫）由陈思儒开发，曾就职与阿里巴巴，该程序由java语言进行开发，阿里巴巴将其应用于生成环境，它不支持事物和存储过程 如果业务压力不是很大的时候要做读写分离，取决于硬盘读取的性能，客户才满意， 读库（配置低），写库（配置高

1.什么是主从复制 MySQL 主从复制是其最重要的功能之⼀. 主从复制是指⼀台服务器充当主数据库服务器, 另⼀台或多台服务器充当从数据库服务器, 主服务器中的数据⾃动复制到从服务器之中. 对于多级复制, 数据库服务器即可充当主机, 也可充当从机. MySQL主从复制的基础是主服务器对数据库修改记录⼆进制⽇志, 从服务器通过主服务器的⼆进制⽇志⾃动执⾏更新. 2.主从复制的类型 基于语句的复制 : 主服务器上⾯执⾏的语句在从服务器上⾯再执⾏⼀遍. 存在的问题 : 时间上可能不完全同步造成偏差, 执⾏语句的⽤户也可能是不同⼀个⽤户. 基于⾏的复制: 把主服务器上⾯改编后的内容直接复制过去, ⽽不关⼼到底改变该内容是由哪条语句引发的. 存在的问题 : ⽐如⼀个⼯资表中有⼀万个⽤户, 我们把每个⽤户的⼯资+1000, 那么基于⾏的复制则要复制⼀万⾏的内容, 由此造成的开销⽐较⼤, ⽽基于语句的复制仅仅⼀条语句就可以了. 混合类型的复制 : MySQL 默认使⽤基于语句的复制, 当基于语句的复制会引发问题的时候就会使⽤基于⾏的复制, MySQL会⾃动进⾏选择. 在MySQL主从复制架构中, 读操作可以在所有的服务器上⾯进⾏, ⽽写操作只能在主服务器上⾯进⾏. 主从复制架构虽然给读操作提供了扩展,可如果写操作也⽐较多的话（多台从服务器还要从主服务器上⾯同步数据）,

前言 文本已收录至我的GitHub精选文章，欢迎Star ： https://github.com/ZhongFuCheng3y/3y 在前一阵子，大哥问过我：”你知道MySQL的原子性是怎么保证的吗“。我懵逼了，MySQL怎么保证原子性？我不会啊。 谁都知道在事务里边原子性的意思：” 一个事务包含多个操作，这些操作要么全部执行，要么全都不执行 “ 于是大哥就给我讲：”用的就是 undo log 啊“。 我：”卧槽，又是知识盲区“ 后来在网上翻了一下，MySQL里边还有几种常见的 log ，分别为： undo log binlog redo log 如果你也未曾关注过这些 log ，麻烦在评论区给我留个言， 让我觉得不是只有我一个人这么菜，行不行 ？ 后来我又去搜了一下，其实这几种log在 面试 的时候也经常会问到，这篇文章以最简单的方式来讲讲，希望对大家有帮助。 一、什么是binlog binlog 其实在日常的开发中是听得很多的，因为很多时候数据的更新就依赖着 binlog 。 举个很简单的例子：我们的数据是保存在数据库里边的嘛，现在我们对某个商品的某个字段的内容改了（数据库变更），而 用户检索的出来数据是走搜索引擎的 。为了让用户能搜到最新的数据，我们需要把引擎的数据也改掉。 一句话： 数据库的变更，搜索引擎的数据也需要变更 。 于是，我们就会监听 binlog 的变更，如果

MySQL日志管理 错误日志 配置方法： vim /etc/my.cnf [mysqld] log-error=/tmp/mysql.log 查看配置方式： show variables like '%log%error%'; 作用： 记录mysql数据库的一般状态信息及报错信息，是我们对于数据库常规报错处理的常用日志。 一般查询日志 配置方法： vim /etc/my.cnf [mysqld] general_log=on general_log_file=/data/mysql/server2.log 查看配置方式： show variables like '%gen%'; 作用： 记录mysql所有执行成功的SQL语句信息，可以做审计用，但是我们很少开启； 可以作为审计功能，一般情况下这个日志不会开，除非有特殊要求 例如：ELK 二进制日志 建议刚部署mysql数据库的时候就开启二进制日志 二进制日志不依赖于存储引擎的，依赖于sql层，记录和sql语句有关的信息 在sql层已经执行完成的语句，如果是事务，应当是已经完成的事务 功能作用：备份和时间点恢复、主从 二进制日志记录了什么？ 已提交的数据记录，以事件的形式记录到二进制文件中 二进制记录格式 一定要配置好二进制日志 row（行模式）：表中行数据的变化过程，记录数据详细，但对IO要求比较高，记录数据在任何情况下都是准确的

一、表设计优化 　　1、简单既优 　　　　数组和字符要给范围，不易过长过大 　　　　时间尽量使用时间戳格式，占用的存储空间比较少 　　　　字段和表注释必不可少 　　2、索引设置 　　　　常用查询字段要添加索引 　　　　如果能使用联合索引代替的尽量使用联合索引代替 　　3、合适的表引擎 　　　　myisam更适合读写较快的地方 　　　　innodb更适合处理事务和更新删除 二、查询优化 　　1、范查询最好禁止 　　　　查询字段要具体，尽量避免使用* 　　2、尽可能使用索引 　　　　根据不同索引，查询时最好使用索引 　　3、exists和in使用特点 　　　　如果查询的两个表大小相当，那么用in和exists效率差别不大 　　　　如果两个表中一个较小，一个较大，则子查询表大的用exists，子查询表小的用in 三、数据量过高优化 　　1、分区分表，mysql5.5之后分区逐渐代替了分表 　　2、主从设置，可以一主多从和多主多从 四、sql分析 　　1、explain 后面跟sql语句 　　主要的字段 type，rows，keys ； 　　　　type指定了该sql使用那种类型的查询 　　　　keys知道了该sql使用了那些索引 　　　　rows知道了查询结果需要遍历多少行才可以得到结果 五、常见mysql配置 　　错误日志 　　　log-error= dir 　　慢查询 　　　

1.StatefulSet概述 部署有状态应用 解决Pod独立生命周期，保持Pod启动顺序和唯一性 1. 稳定，唯一的网络标识符，持久存储 2. 有序，优雅的部署和扩展、删除和终止 3. 有序，滚动更新 应用场景：数据库 StatefulSet与Deployment区别： 有身份的！ 身份三要素： 域名 主机名 存储（PVC） 无状态的适用：web，api，微服务的部署，可以运行在任意节点，不依赖后端持久化存储。 有状态的适用： 需要有固定ip，pod有各自的存储，可以按一定规则进行扩缩容。 2.正常service和headlessService对比 normal sevice: 通过一个cluster-ip 10.0.0.224:80 来反向代理 endpoints 10.244.0.58:8080 10.244.1.78:8080 10.244.1.88:8080 headless service: 无头服务，需要将 clusterIP: None 并且不能设置nodePort web-headlessService.yaml apiVersion: v1 kind: Service metadata: labels: app: web name: headless-svc namespace: default spec: clusterIP: None ports: -

概述 对于MySQL的监控平台，相信大家实现起来有很多了：基于天兔的监控，还有基于zabbix相关的二次开发。相信很多同行都应该已经开始玩起来了。我这边的选型是prometheus + granafa的实现方式。简而言之就是我现在的生产环境使用的是prometheus，还有就是granafa满足的我的日常工作需要。在入门的简介和安装，大家可以参考这里： https://blog.51cto.com/cloumn/detail/77 1、首先看下我们的监控效果、mysql主从 2、mysql状态： 3、缓冲池状态： exporter 相关部署 1、安装exporter [root@controller2 opt]# https://github.com/prometheus/mysqld_exporter/releases/download/v0.10.0/mysqld_exporter-0.10.0.linux-amd64.tar.gz [root@controller2 opt]# tar -xf mysqld_exporter-0.10.0.linux-amd64.tar.gz 2、添加mysql 账户： GRANT SELECT, PROCESS, SUPER, REPLICATION CLIENT, RELOAD ON *.* TO 'exporter'@'%'

原文: 高性能MySQL之基础架构 一、背景 当你手中抓住一件东西不放时，你只能拥有一件东西，如果你肯放手，你就有机会选择更多。与其在别人的生活里跑龙套，不如精彩做自己。人无所舍，必无所成。跌倒了，失去了，不要紧，爬起来继续风雨兼程，且歌且行。 为什么我们需要先学习MYSQL的基础架构先呢？ 原因很简单，当我们需要了解一件事物的时候，我们只有站在宏观的层面，才能层层剥丝抽茧的去理解问题。举个例子，我们要看一个框架的源码，一开始就想进去研究，却发现找不着北，原因很简单，因为我们没有鸟瞰全貌，我们根本不知道入口在哪里。因此我们学习MYSQL的时候也是这样。先从高纬度理解问题，最后看到里面有哪些组件，一层层的拆解，这样让我们对mysql有更深入的理解。废话不多说，我们先看总体的逻辑架构图，如下所示。 二、Mysql总体逻辑架构 从图中不难看出，不同的存储引擎共用一个Server层，也就是从连接器到执行器的部分。可以看到Server层包括连接器、查询缓存、分析器、优化器、执行器等，涵盖MySQL的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，比如触发器、视图等。 需要主意的是存储引擎层负责数据的存储和提取。其架构模式是插件式的，支持InnoDB、MyISAM、Memory等多个存储引擎。现在最常用的存储引擎是InnoDB