MHA

点击上方 "IT牧场" ，选择 "设为星标" 技术干货每日送达！ 高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。 假设系统一直能够提供服务，我们说系统的可用性是100%。如果系统每运行100个时间单位，会有1个时间单位无法提供服务，我们说系统的可用性是99%。很多公司的高可用目标是4个9，也就是99.99%，这就意味着，系统的年停机时间为8.76个小时。 百度的搜索首页，是业内公认高可用保障非常出色的系统，甚至人们会通过www.baidu.com 能不能访问来判断“网络的连通性”，百度高可用的服务让人留下啦“网络通畅，百度就能访问”，“百度打不开，应该是网络连不上”的印象，这其实是对百度HA最高的褒奖。 1. MySQL高可用 说到MySQL的高可用，不得不提到复制，复制是MySQL高可用的基础。复制解决了什么问题呢？ 实现数据备份 如果有从服务器，主服务器发生故障之后，开通从服务器的写入功能，从而提供高可用的使用功能 异地容灾 分摊负载（scale out ）主服务器：写、从服务器：读 1.1 主从复制流程 不同的复制协议： 1.2 高可用复制架构 1.3.mysql 高可用架构 1.3.1 MySQL Cluster架构 限制存储引擎为NDB存储引擎： 1.3.2 MySQL+MMM架构

数据库技术离不开数据库环境搭建。在讨论搭建环境之前，我先推荐一篇文章给大家： 首席架构师白鳝：运维的进阶与哲学之道 。这篇文章对我影响很大，在我还只是个纯粹单一技术思想的IT男时，它让我的思维格局都得到极大的提升。 这篇文章和数据库搭建的关系 可能有些小伙伴心里会有疑问：不就是个MySQL数据库搭建吗？如此简单的内容，而且网上文档满天飞。说好的尽量不讲网上已经存在的重复知识点呢？而且你讲搭建就专心讲，扯上面那些干嘛？就想说明你多崇拜白总吗？（没错，我确实极度崇拜他。） 我先简单解释下：本篇确实主讲MySQL搭建，但是我会在搭建时融入上述文章中提到的思想，这将使搭建更精益化、规范化，且更容易实现自动化甚至智能化。后续也会引申出不少基于这个搭建模式的知识及思想。我不想只分享纯粹的技术知识，我觉得规范化，架构化等思想更为重要。也希望小伙伴们通过我的分享，能将普通的技术知识应用到企业级的架构中去。 下面将分享一下我的搭建方法，可能大家会觉得步骤和常规的比起来略显繁琐，但为了更标准化、规范化，部分操作在手动操作的情况下是无法避免的。不过由于实现了标准化，这会让后续的自动化实现起来更加容易，所以也无需过于纠结操作的繁琐。 MySQL二进制规范搭建步骤 注意：命令行头标识如下： # 表示root用户执行 $ 表示mysql用户执行 mysql> 表示myql命令行执行 1、规范信息： 内容 规范

1、如果主节点已经运行了一段时间，且有大量数据时，如何配置并启动slave节点（写出操作步骤） 主配置MySQL [root@Centos8 ~]#yum -y install mariadb-server [root@Centos8 ~]#vim /etc/my.cnf.d/mariadb-server.cnf [mysqld] log_bin server-id=125 [root@Centos8 ~]#systemctl start mariadb [root@Centos8 ~]#mysql #创建复制账号 MariaDB [(none)]> grant replication slave on *.* to 'repluser'@'192.168.80.%' identified by 'heshizhe'; Query OK, 0 rows affected (0.000 sec) #备份数据库 [root@Centos8 ~]#mkdir /backup [root@Centos8 ~]#mysqldump -A -F --single-transaction --master-data=1 --default-character-set=utf8 > /backup/all.sql [root@Centos8 ~]#ll /backup/ total 468 -rw

问题说明 进行mha的repl检测时报错： [ root@mysql02 ~ ] # masterha_check_repl --conf = / etc / masterha / app1 . cnf Tue Jun 11 11 : 32 : 42 2019 - [ warning ] Global configuration file / etc / masterha_default . cnf not found . Skipping . Tue Jun 11 11 : 32 : 42 2019 - [ info ] Reading application default configuration from / etc / masterha / app1 . cnf . . Tue Jun 11 11 : 32 : 42 2019 - [ info ] Reading server configuration from / etc / masterha / app1 . cnf . . Tue Jun 11 11 : 32 : 42 2019 - [ info ] MHA::MasterMonitor version 0.56 . Tue Jun 11 11 : 32 : 43 2019 - [ info ] GTID failover mode = 0 Tue Jun

随着互联网时代的兴起，MySQL在数据库领域日益显现出举足轻重的地位，它不断扩大的用户群体就是很好的证明。在这样的背景下，需要越来越多的人在知识资源方面为之付出，将自己对MySQL数据库的学习过程、运维经验、个人理解等记录下来，为行业中的后来者燃起一盏明灯， 让他们少走一些弯路。 掌握并熟练使用MySQL的几点建议： 建立完成的 MySQL 知识体系 发挥MySQL的最佳性能的优化方法 掌握如何处理海量业务数据和高并发请求 能够轻松掌握那些晦涩难懂的知识，如主从复制、读写分离、事务与锁等。 能够更加轻松地胜任企业中的开发、运维和数据库管理工作。 能够跟大多数懂MySQL的人拉开差距。 由于互联网产品用户量大、高并发请求场景多，因此对MySQL的性能、可用性、扩展性都提出了很高的要求。使用MySQL解决大量数据以及高并发请求已经是程序员的必备技能，也是衡量一个程序员能力和薪资的标准之一。细心的网友会发现网.上关于MySQL的资料非常非常的多，但却没有一个系统的学习方式， 于是乎你的小编（雷锋）在这个星期也没闲着整理了这份关于MySql性能实战源码+笔记+项目实战的资料。 第一份笔记：高性能MySQL优化笔记 高性能MySQL优化-01MySQL 常用对象 Linux系统安装MySQL 索引 视图 存储过程和函数 触发器. 高性能MySQL优化-02 MySQL体系结构

低读低写并发、低数据量方案 方案一：双机高可用方案 1.数据库架构图 2.特点 一台机器A作为读写库，另一台B作为备份库；A库故障后B库作为读写库；A库恢复后A作为备库。 3.开发说明 此种情况下，数据源配置中的数据库IP地址，可采用虚拟的IP地址。虚拟IP地址由两台数据库机器上的keepalive配置，并互相检测心跳。当其中一台故障后，虚拟IP地址会自动漂移到另外一台正常的库上。 数据库的主备配置、故障排除和数据补全，需要DBA和运维人员来维护。而程序代码或配置并不需要修改。 具体配置可参考资料： http://lizhenliang.blog.51cto.com/7876557/1362313 http://database.51cto.com/art/201012/237204.htm http://gaoke.iteye.com/blog/2283890 4.适应场景 读和写都不高的场景（单表数据低于500万），双机高可用。 5.优缺点 优点是一个机器故障了可以自动切换；缺点是只有一个库在工作，读写并未分离，并发有限制。 方案二：主从结构方案 1.数据库架构图 2.特点 一台机器A作为写库，另一台B作为读库；A库故障后B库充当读写，A修复后，B库为写库，A库为读库。 3.开发说明 这种方案的实现，要借助数据库中间件Mycat来实现，Mycat的datahost配置如下

个人视频汇总 1、2020年深入浅出prometheus+grafana 企业监控应用 https://edu.51cto.com/sd/d075b 2、2020年深入浅出zabbix5.0 企业应用实战 https://edu.51cto.com/sd/8f88b 3、2020年Jumpserver堡垒机版本1.5.8企业落地实践 https://edu.51cto.com/sd/84158 4、2020年Redis5.0 从入门到企业应用实战视频教程 https://edu.51cto.com/sd/aa00f 5、2020年MongoDB 企业应用实战 基础 复制集 分片集群 https://edu.51cto.com/sd/1766d 6、2020年MySQL5.7系列实战课程--主从复制篇 https://edu.51cto.com/sd/c5e81 7、2020年MySQL5.7系列实战课程--高可用MHA与读写分离Atlas应用实战 https://edu.51cto.com/sd/f7955 来源： oschina 链接： https://my.oschina.net/u/4339343/blog/4365164

MySQL中给一张千万甚至更大量级的表添加字段一直是比较头疼的问题，遇到此情况通常该如果处理？本文通过常见的三种场景进行案例说明。 1、 环境准备 数据库版本 ： 5.7.25-28（Percona 分支） 服务器配置： 3台centos 7虚拟机，配置均为2CPU 2G内存 数据库架构： 1主2从的MHA架构（为了方便主从切换场景的演示，如开启GTID，则两节点即可），关于MHA搭建可参考此文 MySQL高可用之MHA集群部署 准备测试表： 创建一张2kw记录的表，快速创建的方法可以参考 快速创建连续数 本次对存储过程稍作修改，多添加几个字段，存储过程如下： DELIMITER $$ CREATE PROCEDURE `sp_createNum`(cnt INT ) BEGIN DECLARE i INT DEFAULT 1 ; DROP TABLE if exists tb_add_columns; CREATE TABLE if not exists tb_add_columns(id int primary key ,col1 int ,col2 varchar ( 32 )); INSERT INTO tb_add_columns(id,col1,col2) SELECT i as id ,i % 7 as col1,md5(i) as col2; WHILE i <

MHA（Master HA）是一款开源的 MySQL 的高可用程序，它为 MySQL 主从复制架构提供了 automating master failover 功能。MHA 在监控到 master 节点故障时，会提升其中拥有最新数据的 slave 节点成为新的master 节点，在此期间，MHA 会通过于其它从节点获取额外信息来避免一致性方面的问题。MHA 还提供了 master 节点的在线切换功能，即按需切换 master/slave 节点。 MHA 是由日本人 yoshinorim（原就职于DeNA现就职于FaceBook）开发的比较成熟的 MySQL 高可用方案。MHA 能够在30秒内实现故障切换，并能在故障切换中，最大可能的保证数据一致性。目前淘宝也正在开发相似产品 TMHA， 目前已支持一主一从。 一、MHA的组成 （一）MHA中的角色 MHA 服务有两种角色， MHA Manager(管理节点)和 MHA Node(数据节点)： MHA Manager：通常单独部署在一台独立机器上管理多个 master/slave 集群(组)，每个master/slave 集群称作一个application，用来管理统筹整个集群。 MHA Node：运行在每台 MySQL 服务器上(master/slave/manager)，它通过监控具备解析和清理 logs 功能的脚本来加快故障转移

前言 国内疫情早就趋于平稳，是时候找回节奏了。在这里更新个人OKR。 强化自组织，持续优化和开放透明的团队文化 6.15前辅助全员完成下半年OKR制定 覆盖全员 月度评审 季度复盘 6.30前改进基础设施确保每个项目的演示和测试环境 团队内任意成员在研项目可在5分钟内启动并演示本周期功能 9月前新人进入后10分钟内完成开发环境的生成 利用虚拟机来保证linux开发环境，物理机工具包 前端，docker，node 后端，docker，java 测试 技术进阶实现3%目标 7月前实现参与的项目镜像化比例高于90% UMP除4G平台服务外的全镜像化 ISS全镜像化 实现JGDQ全镜像化 九月前以UMP为示范系统突破全链路的单点故障和云原生技术 自建服务器集群扩大到10台 基于云原生技术的UMP示范系统实现公有云和私有云自由迁移 基本平台基于rancher或是k8s 数据库 ，mha 应用系统 ，docker 网关接入 gateway 状态服务的处理 stateful 监控系统 ，Prometheus 链路追踪系统，skywalking 日志系统，elk 11月前完成DEP的重构 实现1w并发接入 亿级数据检索2s出结果 全节点可水平扩展 无单点 总结 应对危机与抓住机遇。 来源： oschina 链接： https://my.oschina.net/u/4358286/blog