从事DBA的行业也有两年多了,在数据备份上无论是理论和实践上,都积累了一些经验,恰逢这两天又出现一些数据备份方面的问题,这里,我将之前遇到过的数据备份方法简单做个整理。
由于mysql主从复制是基于binlog的一种异步复制 通过网络传送binlog文件,理所当然网络延迟是主从不同步的绝大多数的原因,特别是跨机房的数据同步出现这种几率非常的大,所以做读写分离,注意从业务层进行前期设计。
删库跑路也是个老梗了,可见在运维数据库的过程中误删除数据,或者开发的代码有bug,造成数据的误删除屡见不鲜。不过现在也有许多用于恢复或预防误删除的方案,例如SQL管理系统,将要执行的SQL先交由管理员审核,然后由管理员备份一个镜像数据库,在镜像上执行该SQL,并在执行后还原镜像。这样经过层层把关就可以大大减小出现误操作的几率。
在了解主从复制之前必须要了解的就是数据库的二进制日志(binlog),主从复制架构大多基于二进制日志进行。
本次分享主要讲mongodb 在互联网金融中交易与非交易部分如何实践,金融行业涉及哪些注意点,又踩过的坑。 什么是P2P P2P是一种网上的借贷模式,放款人可以通过P2P公司选择认为比较靠谱的借款人进
一 序言 在运维线上M-M 架构的MySQL数据库时,接收的比较多关于主备延时的报警:
在生产者投递消息时指定mandatory或者imrnediate参数设为 true 时,RabbitMQ 会把无法投递的消息通过Basic.Return 命令将消息返回给生产者,此时生产者需要调用channel.addReturnListener 来添加 ReturnListener 监昕器实现监听投递失败的消息
基于主从复制,一个主库,挂多个从库,然后我们就单单只是写主库,然后主库会自动把数据给同步到从库上去,数据读取走从库。
在了解主从复制之前必须要了解的就是数据库的二进制日志(binlog),主从复制架构大多基于二进制日志进行,二进制日志相关信息参考:http://www.cnblogs.com/clsn/p/8087678.html#_label6
复制是指将主库的ddl,dml等操作通过binlog日志,传输到复制服务器,副本进行回放这些日志,从而使得从库和主库数据保存同步的工作模式
1)主服务器将所有数据和结构更改记录到二进制日志中。 2)从属服务器从主服务器请求该二进制日志并在本地应用其内容。 3)IO:请求主库,获取上一次执行过的新的事件,并存放到relaylog 4)SQL:从relaylog中将sql语句翻译给从库执行
大型项目对备份尤为关注,一般有双机备份,热备冷备,异地灾备等等… 今天来说一下两台服务器上的 MySQL 主从复制备份,需求比较简单:从要同步主的数据,但也不用太频繁,保持 15 分钟的数据差即可,意思就是每 15 分钟去同步一次修改过的数据。
之前部署了Mysql主从复制环境(Mysql主从同步(1)-主从/主主环境部署梳理),在mysql同步过程中会出现很多问题,导致数据同步异常。 以下梳理了几种主从同步中可能存在的问题: 1)slave运行过慢不能与master同步,也就是MySQL数据库主从同步延迟 MySQL数据库slave服务器延迟的现象是非常普遍的,MySQL复制允许从机进行SELECT操作,但是在实际线上环境下,由于从机延迟的关系,很难将读取操作转向到从机。这就导致了有了以下一些潜规则:“实时性要求不高的读取操作可以放到slave服
杨奇龙,网名“北在南方”,7年DBA老兵,目前任职于杭州有赞科技DBA,主要负责数据库架构设计和运维平台开发工作,擅长数据库性能调优、故障诊断。
现在很多并发性很高的系统为了提高吞吐量而使用redis来当数据存储,而当redis挂了的时候有可能数据丢失,这个时候系统可能不可用,而把流量路由到db肯定是不可行的,因为流量太大,这个时候恢复redis中的数据又比较耗时,而这个时候经常会出现使用多个reids集群,即有一个或者多个备份redis集群。这个时候怎么保证多个redis集群数据一致性呢?
[code]– 默认情况下” ; ” 代表sql语句的结束 delimiter 新的界定符 – 修改 // 为界定符 delimiter //
读取缓存步骤一般没有什么问题,但是一旦涉及到数据更新:数据库和缓存更新,就容易出现缓存(Redis)和数据库(MySQL)间的数据一致性问题。
144 Coordinator线程分发relay log中事务时发现这个事务不能执行,要等待前面的事务完成提交,所以处于waiting for dependent transaction to commit的状态。145/146线程和备份线程162形成死锁,145线程等待162线程 global read lock 释放,162线程占有MDL::global read lock 全局读锁,申请全局commit lock的时候阻塞等待146线程,146线程占有MDL:: commit lock,因为从库设置slave_preserve_commit_order=1,保证从库binlog提交顺序,而146线程执行事务对应的binlog靠后面,所以等待145的事务提交。最终形成了145->162->146->145的死循环,形成死锁。 三个线程相互形成死锁,还是很少见的。 2.2 相关参数为何未生效 --ftwrl-wait-timeout=60 指的是执行FTWRL之前,如果检测到存在长SQL,先等待指定时间(秒),如果超时后还存在长SQL,则备份报错退出。默认为0则表示立即执行。 --ftwrl-wait-threshold=5 指的是执行FTWRL之前,检测长SQL的方法,如果在执行flush前存在已经运行了超过指定时间(秒)的SQL,则将该SQL定义为长SQL,默认60s。 --kill-long-queries_timeout=0 在执行FTWRL后,如果flush操作被阻塞了N秒,则kill掉阻塞它的线程,默认0的情况就是不kill任何阻塞flush的SQL,直到该SQL执行完成。 从上面各个参数的解释,不难看出,--ftwrl-wait-*参数是针对执行FTWRL之前的长SQL检测机制,对于已执行FTWRL时无济于事,--kill-long-*参数则是设置默认值0,不起任何作用。 3. 结论与建议
根据上图可以看到QPS:10.73k,实际上真实的并发大量数据到达的时候,我这里最高的QPS是将近15k.而目前单个数据库分片(实例)4CPU8G内存的配置下,最高的性能是7k的QPS。
光大银行也是很有魄力的,拿出了一个重要的业务系统进行一次试点,做了一次这种分布式架构转型的项目。我有过十余年DBA相关的经验,不过之前接触比较多的主要还是传统的商用型数据库,所以能作为这次项目的推进人,也是我个人在这种新的架构下的一次学习的过程。
采用高可用系统架构支持重要系统,为关键业务提供7x24的不间断服务,已经成为众多企业保障业务稳定、持续运转的主要选择。服务多活是高可用架构重要实施手段,本文介绍了一些业界常用的多活手段例如同城双活、两地三中心、异地多活架构设计方案并详述了各种方案的优缺点。
上文《MySQL数据被误删怎么办?》介绍了MySQL在故障或者误删数据后,可以通过备份+binlog的方式进行数据恢复。但是,当备份文件和binlog都丢失了呢?所以单节点是不可靠的,为了避免单节点故障带来的数据丢失以及MySQL服务的可用性,生产环境通常都是采用高可用或者集群模式。而在这背后则离不开主从复制技术,所以本文对主从复制的原理和操作展开介绍,从而全面了解这一技术。
如果主从复制之间出现延时,就会影响主从数据的一致性。 此时发生容灾切换,且在新的主库写入了数据,那么从业务角度上,会产生意想不到的严重后果。 复制延时问题,在只读从库的场景下,若从库产生复制延时,也可能会对业务造成一定影响,比如在业务上表现为读写不一致——新增/修改数据查不到等现象。 由此可见,主从复制的延时问题在数据库运营中需要特别关注。一般来说,DBA在库上执行SHOW SLAVE STATUS,并且观察 Seconds_Behind_Master的值,就能够了解当前某个数据库和它的主库之间的数据复制延时。
MMM即Multi-Master Replication Manager for MySQL:mysql多主复制管理器,基于perl实现,关于mysql主主复制配置的监控、故障转移和管理的一套可伸缩的脚本套件(在任何时候只有一个节点可以被写入)。
容器技术改变了应用交付、运行的方式,几乎各种Linux环境下的应用程序都可以使用容器来运行。但是否能在容器环境里运行数据库应用,以及数据库应用是否适合在容器里运行,一直都是大家很关注的问题,今天我们就来深入分析一下容器环境运行MySQL数据库的事。
首先是运维成本,包括监控告警是否完善、是否有备份恢复机制、升级和迁移的成本是否高、社区是否稳定、是否方便调优、排障是否简易等;
我们做数据库选型的时候首先要问:需求是谁提出的,也就是说谁选型?是负责采购的同学、 DBA 还是业务研发?
pxc是基于Galera,可以实现多节点间的数据同步以及不需要读写分离可以随时访问任一节点,保证数据库的强一致性(无延迟)以及高可用,但牺牲了部分性能
DDL 一向是业务的痛点,尤其是对大型表的 DDL 操作,具有操作时间久,对性能影响大,可能影响业务正常使用等问题。
相信 slave 延迟是MySQL dba 遇到的一个老生长谈的问题了。我们先来分析一下slave延迟带来的风险
故障是运维人员永远的痛。相信每一个运维人员的KPI中都有一项:可用性。可用性高就是不出故障,各个公司对可用性和故障评级的标准都不相同,但是避免故障的方法却是殊途同归。我们怎么避免故障,沃趣科技简单列举了以下几条,与大家共勉! 1、变更要有回滚,在同样的环境测试过 2、对破坏性的操作谨慎小心 3、设置好命令提示 4、备份并验证备份有效性 5、对生产环境存有敬畏之心 6、交接和休假最容易出故障,变更请谨慎 7、搭建报警,及时获得出错信息。搭建性能监控,了解历史,获得趋势,预测未来 8、自动切换需谨慎 9、仔细一
我们在平时工作中,使用最多的数据库就是 MySQL 了,随着业务的增加,如果单单靠一台服务器的话,负载过重,就容易造成宕机。
前文提到异地多活的几种型态和基于OceanBase实现方案。这里再总结一下基于其他分布式数据库(MySQL)实现异地多活时要考虑的点。本文不讨论为什么做异地多活,可以参考末尾的文章。
#binlog format有三种形式:Statement、Mixed、Row,默认设置为mixed
大家好,之前的文章《NineData,领先的多云数据管理平台》介绍了我们的产品,大家在了解我们产品的同时,可能也比较关注我们是怎么做的,用了哪些技术,今天和大家一起来探讨一下NineData 的技术实现。
上期文章我们聊到了Redis,这期我们来说说另一个网红NoSQL数据库——MongoDB。 PS:其他历史测评请直接翻到文末~ 有这么一个介绍MongoDB的说法是:MongoDB是非关系数据库当中功能最丰富、最像关系数据库的。这么说是因为作为一个面向文档存储型、数据结构非常松散自由的数据库,MongoDB却拥有着丰富的功能特性如强大灵活的查询语言、支持二级索引等,新版本的MongDB甚至还支持事务。 MongoDB不仅功能丰富,而且读性能强大到远远把MySQL甩在后面,今天我就代替大家来动手进行一下数据
MongoDB复制集RS(ReplicationSet): 基本构成是1主2从的结构,自带互相监控投票机制(Raft(MongoDB)Paxos(mysql MGR 用的是变种))
要实施复制,首先必须打开 master 端的 binlog 功能,否则无法实现。因为整个复制过程实际上就是 slave 从 master 获取该 binlog 然后再在自己身上完全顺序的执行 binlog 中所记录的各种更新操作。
在实际的生产环境中,由单台MySQL作为独立的数据库是完全不能满足实际需求的,无论是在安全性,高可用性以及高并发等各个方面
数据库高可用一直是企业的重中之重,而采用主从方案,一主一从,能实现负载均衡,读写分离的作用,分担数据库的负荷,提高性能,而如果搭配keepalived还能实现高可用性,当主服务器故障以后,自动切换到从服务器上。
SQL注入漏洞为PHP研发人员所熟知,它是所有漏洞类型中危害最严重的漏洞之一。SQL注入漏洞,主要是通过伪造客户端请求,把SQL命令提交到服务端进行非法请求的操作,最终达到欺骗服务器从而执行恶意的SQL命令。
在高并发的场景下,大量的请求直接访问MySQL很容易造成性能问题。所以,我们都会用Redis来做数据的缓存,削减对数据库的请求。但是,MySQL和Redis是两种不同的数据库,如何保证不同数据库之间数据的一致性就非常关键了。
近期一篇《就这样把根目录删了!!!》引发了广泛的讨论,《如何防止根目录被删》汇总了7种防删方案。还有同学评论中反馈“不小心把库删了”,如何快速恢复删掉的数据库,是今天要讨论的话题。 【高可用数据库架构
如果人为执行了“删库”操作,命令会同步给其他从库,导致所有库上的数据全被删除,无法恢复,故这种方案是不行的。
MySQL 主从集群,分散访问压力,提升整个系统的可用性,降低大访问量引发的故障率。
—1— 前言 在高并发的场景下,大量的请求直接访问Mysql很容易造成性能问题。所以,我们都会用Redis来做数据的缓存,削减对数据库的请求。但是,Mysql和Redis是两种不同的数据库,如何保证不同数据库之间数据的一致性就非常关键了。 —2— 数据不一致的原因 1.导致数据不一致的原因 在高并发的业务场景下,数据库大多数情况都是用户并发访问最薄弱的环节。 所以,就需要使用redis做一个缓冲操作,让请求先访问到redis,而不是直接访问MySQL等数据库。 读取缓存步骤一般没有什么问题,但是一旦涉及到数
在使用 show engine innodb status检查引擎状态时,发现了死锁问题 在5.5中,information_schema 库中增加了三个关于锁的表(MEMORY引擎)
Zabbix监控Mysql | Mysql 5.7,8.0基准性能比较,Mysql8.0主主配置
领取专属 10元无门槛券
手把手带您无忧上云