MHA

0、建初心 优秀DBA的素质 1 、人品，不做某些事情 2 、严谨，运行命令前深思熟虑，三思而后行，即使是依据select 3 、细心，严格按照步骤一步一步执行，减少出错 4 、心态，遇到灾难，首先要稳住，不慌张，不要受到旁人的影响 5 、熟悉操作系统，Linux系统的工具和命令 6 、熟悉业务 ( 开发 )，编程语言 7 、熟悉行业 8 、喜欢数据库 • 什么是数据？ 数据是指对客观事件进行记录并可以鉴别的符号，是对客观事物的性质、状态以及相互关系等进行记载的物理符号或这些物理符号的组合。它是可识别的、抽象的符号。 • 什么是数据库管理系统？ 将大量的数据规范的管理在一起的软件 • 数据库管理系统种类 关系型和非关系型 • 关系型数据库的特点 　　– 二维表 　　– 典型产品 Oracle传统企业， MySQL是互联网企业 　　– 数据存取是通过SQL 　　– 最大特点，数据安全性方面强（ACID） • NoSQL：非关系型数据库（Not only SQL） 　　– 不是否定关系型数据库，做关系型数据库的的补充。 　　– 想做老大，先学会做老二。 RDBMS与NoSQL对比 • web1.0时代 　　企业提供内容，用户浏览，所以关系型数据库够用，并发并不高，所以不需要NoSQL。 • web2.0时代 　　核心是企业提供平台，用户参与提供内容。这时关系型数据库无法满足需求了。 •

​本文根据高新刚老师在〖2020 Gdevops全球敏捷运维峰会〗现场演讲内容整理而成。 （点击文末“阅读原文”可获取完整PPT） 讲师介绍 高新刚， 京东数科数据库团队负责人，负责京东数科数据库平台的管理维护工作，带领团队平稳护航多次 6·18、11·11的大促活动；对数据库多业务场景架构设计，高并发解决方案，数据生态管控有着丰富的实践经验；对数据库库中间件、分布式事务数据库和自动化智能化运维平台设计开发有着深入的实践和探索；长期专注于数据库产品化输出和国产数据库的探索研究。 当我们遇到海量这个词的时候，大家第一时间会想到和数据库相关的哪些内容？比如海量的数据量、大规模的数据库的节点数、高并发的业务访问。海量的数据带来的是存储和弹性扩展的问题，大规模的数据库节点给我们带来的是批量运维的困扰，高并发访问带来的是性能的问题。 所以我认为，解决大部分的海量数据的问题，一般有三种通用的方法： 第一、我们要有一个数据的全生命周期的管理体系，从数据库的写入到数据库的存储，到TP的查询，AP的查询，到后面的一些冷热数据分离和大数据实时或异步抽取，我们要有一系列的管控工具帮助我们实现高效的解决方案； 第二、我们要有一个非常稳定、平稳高效的架构体系，也就是说不管你怎么去做弹性的缩扩容，不管你怎么去做数据的搬迁，也都是在这一个相对固定的TP和AP的架构框架下面去运行； 第三

MySQL 主从复制实现原理 开启二进制日志 步骤一：主库 db 的更新事件 (update、insert、delete) 被写到 binlog 步骤二：从库发起连接，连接到主库 步骤三：此时主库创建一个 binlog dump thread，把 binlog 的内容发送到从库 步骤四：从库启动之后，创建一个 I/O 线程，读取主库传过来的 binlog 内容并写入到 relay log 步骤五：还会创建一个 SQL 线程，从 relay log 里面读取内容，从 Exec_Master_Log_Pos 位置开始执行读取到的更新事件，将更新内容写入到 slave 的 db 异步复制 master 修改后写入 binary_log（execute-binlog-commit） slave 开启 io 线程，读取 master binlog_dump，写入 relaylog slave 的 sql 线程，读取 relaylog，重新执行到从库 半同步复制 master 修改后写入 binary_log（execute-binlog） slave 开启 io 线程，读取 master binlog_dump，写入 relaylog slave 发送 ACK 到 master，master commit（阻塞) 提交 slave 的 sql 线程，读取 relaylog，重新执行到从库

点击上方“ 程序员小灰 ”，选择“置顶公众号” 有趣有内涵的文章第一时间送达！ 本文转载自公众号 民工哥Linux运维 前言 高可用架构对于互联网服务基本是标配，无论是应用服务还是数据库服务都需要做到高可用。对于一个系统而言，可能包含很多模块，比如前端应用，缓存，数据库，搜索，消息队列等，每个模块都需要做到高可用，才能保证整个系统的高可用。对于数据库服务而言，高可用可能更复杂，对用户的服务可用，不仅仅是能访问，还需要有正确性保证，因此数据库的高可用方案是一直以来的讨论热点，今天就各种的高可用方案，谈一下个人的一些看法，如有错误，还请指正！！ MySQL主从架构 此种架构，一般初创企业比较常用，也便于后面步步的扩展 此架构特点： 1、成本低，布署快速、方便 2、读写分离 3、还能通过及时增加从库来减少读库压力 4、主库单点故障 5、数据一致性问题（同步延迟造成） MySQL+DRDB架构 通过DRBD基于block块的复制模式，快速进行双主故障切换，很大程度上解决主库单点故障问题 此架构特点： 1、高可用软件可使用Heartbeat,全面负责VIP、数据与DRBD服务的管理 2、主故障后可自动快速切换，并且从库仍然能通过VIP与新主库进行数据同步 3、从库也支持读写分离，可使用中间件或程序实现 MySQL+MHA架构 MHA目前在Mysql高可用方案中应该也是比较成熟和常见的方案

1、编写脚本，支持让用户自主选择，使用mysqldump还是xtraback全量备份。 [root@test-centos7-node1 scripts]# cat chose_backup_mysql.sh #!/bin/bash # #************************************************************************ #Author: qiuhom #QQ: 467697313 #mail: qiuhom467697313@qq.com #Date: 2020-01-12 #FileName： chose_backup_mysql.sh #URL: https://www.cnblogs.com/qiuhom-1874/ #Description： #Copyright (C): 2020 All rights reserved #************************************************************************ [ -f /etc/init.d/functions ] && . /etc/init.d/functions fun_mysqldump(){ if `which mysqldump &> /dev/null` ;then mysqldump

###Percona XtraDB Cluster(PXC)原理 ####介绍: PXC曾经属于一套近乎最完美的mysql高可用集群解决方案(现mgr总体上要优于pxc)，相比传统的基于主从复制模式的集群架构MHA和MM+keepalived，最突出特点就是解决了数据复制延迟问题，基本上可以达到实时同步。节点间关系是对等的,事务要么在所有节点上执行，要么都不执行，它的实现机制决定了它对待一致性的行为非常严格，这也能非常完美的保证MySQL集群的数据一致性. ####1.PXC使用端口 3306 数据库对外服务端口 4444 SST(State Snapshot Transfer )全量传输端口, 指数据镜象传输,可先配置:xtrabackup , rsync ,mysqldump 4567 :成员通信端口 4568 : IST(Incremental State Transfer )增量传输端口(相对于SST的增量)。 ####2.PXC的优势 强一致性 同步延迟小 每一个节点都可以读写 用箱子推给Group里所有的成员， data page 相当于物理复制，而不是发blog日志,再重现. 同步的是结果数据. 从节点在apply数据时，支持并行执行，有更好的性能表现 ####PXC的执行流程 客户端先发起一个事务先在本地执行，当发起对事务的提交操作时

https://dbaplus.cn/news-160-1297-1.html 本文转自【 Qunar技术沙龙】， 经平台同意授权转载。 近期大家都在讨论Paxos算法，我看了很多网上的文章，总觉得有些晦涩难懂，经过一段时间研究，对Paxos有了一些理解，在这里总结一下，希望能抛砖引玉。 1、为什么需要Paxos Paxos要解决的问题，是分布式系统中的一致性问题。那么，到底什么是“分布式系统中的一致性问题”呢？在分布式系统中，为了保证数据的高可用，通常我们会将数据保留多个副本(replica)，这些副本会放置在不同的物理的机器上。副本要保持一致，那么所有副本的更新序列就要保持一致。因为数据的增删改查操作一般都存在多个客户端并发操作，到底哪个客户端先做，哪个客户端后做，更新顺序要保证。如果不是分布式，那么可以通过加锁的方法，谁先申请到锁谁就先操作，但这就存在单点问题。 Paxos协议主要有两种用法：一种用法是用来实现全局的锁服务或者命名和配置服务，例如Google Chubby以及Apache ZooKeeper。另外一种用法是用它来将用户数据复制到多个数据中心，例如Google Megastore以及Google Spanner。 以一个分布式的KV数据库为例，假设数据库对外提供2种操作Put和Get，具体架构如下： 在这样一个架构下

目前，在很多OLTP场景中，MySQL数据库都有着广泛的应用，也有很多不同的使用方式。从数据库的业务需求、架构设计、运营维护、再到扩容迁移，不同的MySQL架构有不同的特点，适应一定的业务场景，或者解决一定的业务问题。 DBA作为数据库架构的设计、实施、维护人员，不仅要对各种MySQL架构非常熟悉，还要了解业务，对于不同的业务有一定的划分和认识，并根据业务特点和架构特点，合理选择和使用MySQL，满足业务需求。 本文从MySQL常见架构、业务环境分类、业务与架构结合使用原则三个方面对MySQL数据库和业务场景进行探讨和说明，让大家先分别对MySQL的架构和业务分类有所了解，然后再将两者贯通起来，使得能够在进行业务与MySQL架构设计时纲举目张，让用户可以用合适的技术解决支撑业务需求。 一、MySQL数据库常见架构 为了对MySQL数据库常见架构，能够有进行比较清晰的认识，下面先从MySQL三种通用基础架构、五种特殊需求架构、架构组合与综合使用三个方面进行说明。 1、 MySQL三种常见基础架构 （1）MySQL单实例架构 MySQL单实例，就是在服务器上部署一个MySQL实例来对外提供服务，这是最开始接触MySQL数据库会使用的方式，也是常见学习、研究MySQL数据库的使用方式。 MySQL单实例的使用方式，是MySQL数据库使用的第一阶段，通常这种情况下

1.简介 1.1 软件介绍 MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到0~30秒之内字段完成数据库的故障切换，并且在进行故障切换过程中MHA能最大程度保证数据库的一致性，以达到真正意义上的高可用。 MHA由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。 MHA Manager可以独立部署在一台独立的机器上管理多个Master-Slave集群，也可以部署在一台Slave上。当Master出现故障时，它可以自动将最新数据的Slave提升为新的Master，然后将所有其他的Slave重新指向新的Master。整个故障转移过程对应程序是完全透明的。 1.2 工作流程 从宕机崩溃的master保存二进制日志事件（binlog events）； 识别含有最新更新的slave； 应用差异的中继日志（relay log）到其他的slave； 应用从master保存的二进制日志事件（binlog events）； 提升一个slave为新的master； 使其他的slave连接新的master进行复制； 1.复制主库binlog日志出来 2.找出relaylog日志最全的从库 3

数据库管理与高可用----MHA高可用配置及故障切换 实验思路: 1.MHA架构 1）数据库安装 2)一主两从 3)MHA搭建 故障模拟 1）主库失效 2）备选主库成为主库 3)从库2将备选主库指向为主库 案例环境 1.本案例环境 服务器CentOS7.4(64位)MHA-manager/192.168.100.130 管理节点，安装manager组件 服务器CentOS7.4(64位)Mysq11/192.168.100.150 Master 节点，安装node组件 服务器CentOS7.4(64位)Mysql2/192.168.100.160 Slave 节点，安装node组件 服务器CentOS7.4(64位)Mysql3/192.168.100.170 Slave节点，安装node组件 这里操作系统是CentOS7版本，所以这里下载MHA版本是0.57版本。 2.案例需求 本案例要求通过MHA监控MySQL数据库在故障时进行自动切换，不影响业务。 3.案例实现思路 1)安装MySQL数据库 2)配置MySQL一主两从 3)安装MHA软件 4)配置无密码认证 5)配置 MySQL MHA高可用 6)模拟master故障切换 在三台MySQL 节点上分别安装数据库，MySQL版本请使用5.6.36，cmake版本请使 用2.8.6。下面只在Mysql1上面做演示，安装过程如下。