爱可生南区交付服务部 DBA 团队成员，主要负责 MySQL 故障处理，MySQL 高可用架构改造，OceanBase 相关技术支持。爱好足球，羽毛球。
腾讯云数据库【国产数据库专题线上技术沙龙】正在火热进行中，4月28日陈爱声的分享已经结束，没来得及参与的小伙伴不用担心，以下就是直播的视频和文字回顾。
利用主从复制+GTID的特性实现异地数据同步与读写分离。下面是实现细节与不同于常规方案的特性。
作为一名开发同学，大家对 MySQL 一定不陌生，像常见的 事务特性、隔离级别 、索引等也都是老生常谈。
MySQL主备是最简单的MySQL集群，和单机MySQL相比，只多了一个用于同步备份的MySQL。
至于pg为什么不做这个功能我也想了很久，下面是我自己的一点猜测。pg是个追求完美主义的数据库，他从架构设计层面就会考虑如何做到完美，比如说他不用主流数据库都在使用的undo，我猜测这个原因是因为，使用undo有一个问题，undo空间不管是文件系统还是表空间都是有大小限制的，而数据库未提交的事务信息可能是无限大的，这样数据的前镜像总有可能将undo空间撑爆掉，这样就需要清理旧的undo段，如果需要查询的undo前镜像备清理了，数据库就会跑出错误，这就是oracle中经典的snapshot too old报错。所以pg摒弃了这种模式，因为他觉得必须要提供给用户一个需要的数据一定能查到的数据库，而不是本该能查到的数据被无端清理掉了，所以pg使用了多数据版本来解决这个问题，将前镜像的真实数据放在数据文件中，真正确保没有事务可能再去访问该数据时才进行清理。当然这样也带来膨胀的问题，这其实也是pg最遭人诟病的问题。
数据库作为信息系统重要的基础设施，一直承担着压舱石的角色。互联网应用的高并发、海量数据使得数据库的负载越来越重，这在数据大集中的情况下愈发明显。而数据库作为信息系统唯一的“单点”，稳定性、可用性是首先要保证的目标。这里的单点并不是指数据库没有高可用方案，而是因为数据库只要涉及到数据的复制就一定是有状态的，有状态的应用更加难以运维，并且在遭遇异常时并不能做到真正意义上的无缝切换。
MySQL通过复制（Replication）实现存储系统的高可用。目前，MySQL支持的复制方式有：
在上一篇文章中（数据分布方式之哈希与一致性哈希，我就是个神算子），我为你讲解了数据分布（也称数据分片）技术，主要用于构建数据索引，是实现“导购”功能的关键技术。数据分布的本质是，将原数据集划分为多个数据子集，以存储到不同的地方，在一定程度上体现了数据的可用性和可靠性（一个存储节点故障，只影响该存储节点的数据）。
温馨提示：要看高清无码套图，请使用手机打开并单击图片放大查看。 Fayson的github：https://github.com/fayson/cdhproject 提示：代码块部分可以左右滑动查看噢 1.文档编写目的 ---- 前面Fayson文章讲《1.如何在RedHat7上安装OpenLDA并配置客户端》以及《2.如何在RedHat7中实现OpenLDAP集成SSH登录并使用sssd同步用户》，那么如何确保OpenLDAP服务的高可用？本篇文章主要介绍如何通过OpenLDAP的MorrorMode实现
对于一些关键数据，例如账户数据，对可靠性和一致性的要求非常高。我们宁可牺牲短暂时间内的可用性，也不允许数据出现错误或丢失。所以早期我们会发现业界存在这种现象：DB设置了主备同步，主DB挂了，但是不敢切换到备DB，只能暂停服务。这种现象的主要原因有两点：
我们先来了解一下主备同步的原理，下面以一个update语句来介绍主库与备库间是如何进行同步的。
腾讯云原生数据库 TDSQL-C（Cloud Native Database TDSQL-C，TDSQL-C）是腾讯云自研的新一代高性能高可用的企业级分布式云数据库。融合了传统数据库、云计算与新硬件技术的优势，100%兼容 MySQL 和 PostgreSQL，实现超百万级 QPS 的高吞吐，128TB 海量分布式智能存储，保障数据安全可靠。 本文由腾讯云数据库高级工程师唐颋为大家详细解读TDSQL-C PostreSQL的高可用特性。 TDSQL-C PG版产品简介 TDSQL-C PG版是一款基于计算、
正常情况下，只要主库执行更新生成的所有 binlog，都可以传到备库并被正确地执行，备库就能达到跟主库一致的状态，这就是最终一致性。
通过主备同步我们能够保证数据的可靠性(最终一致性)，MySQL的主备可用性主要依赖于主备切换的时间，越短越好，但前提是切换完成以后数据要一致。
Apache Pulsar 是一个多租户、高性能的服务间消息传输解决方案，支持多租户、低延时、读写分离、跨地域复制（GEO Replication）、快速扩容、灵活容错等特性，GEO Replication 可以原生支持数据和订阅状态在多个集群之间进行复制，GEO 目前在 Apache InLong 内部已经有长期稳定的实践，本文主要讲述 GEO 中的订阅状态的同步。
时至今日，企业运作和业务运营对于IT系统的依赖性越来越高，对于IT系统的稳定性和可靠性的要求也越来越高。然而，＂天有不测风云，人有旦夕祸福＂，一旦IT系统因为天灾或人为因素等等意外事故导致系统毁坏而长期无法运行，将造成整个企业在营运上的重大损失。曾几何时支付宝、携程等互联网企业由于IT系统技术故障而相继“瘫痪”，更是从反面说明了容灾系统建设的重要性。
为帮助开发者更好地了解和学习分布式数据库技术，2020年3月，腾讯云数据库、云加社区联合腾讯TEG数据库工作组特推出为期3个月的国产数据库专题线上技术沙龙《你想了解的国产数据库秘密，都在这！》，邀请数十位鹅厂资深数据库专家每周二和周四晚上在线深入解读TDSQL、CynosDB/CDB、TBase三款鹅厂自研数据库的核心架构、技术实现原理和最佳实践等。三月为TDSQL专题月，本文将带来直播回顾第二篇《破解分布式数据库的高可用难题：TDSQL高可用方案实现》。
在前面的第24、25和26篇文章中，介绍了 MySQL 主备复制的基础结构，但这些都是一主一备的结构。
温馨提示：要看高清无码套图，请使用手机打开并单击图片放大查看。 Fayson的github：https://github.com/fayson/cdhproject 提示：代码块部分可以左右滑动查看噢 1.文档编写目的 本文主要介绍由Cloudera Manager管理的CDH集群的角色划分。实际部署你可能还需要考虑工作负载的类型和数量，真实要部署的哪些服务，硬件资源，配置，以及其他因素。当你使用Cloudera Manager的安装向导来安装CDH时，CM会根据主机的可用资源，自动的分配角色到各台主机，边
4个指标怎么看呢？实际上是在 已经搭建主从同步的slave端执行 show slave status的结果，如下所示：
在状态1中，客户端的读写都直接访问节点A，而节点B是A的备库，只是将A的更新都同步过来，到本地执行。这样可以保持节点B和A的数据是相同的。当需要切换的时候，就切成状态2。这时候客户端读写访问的都是节点B，而节点A是B的备库
不知不觉，分布式数据存储这一站已经到了最后一讲。在前面几讲，我与你分享了 CAP 理论（想要设计一个好的分布式系统，必须搞定这个理论）、（分布式存储系统三要素，掌握这些就离成功不远了）、数据分布式分片方法和数据复制技术（分布式数据复制技术，今天就教你真正分身术），其中数据分片方法和数据复制技术均是导购中的关键技术。
腾讯云数据库国产数据库专题线上技术沙龙正在火热进行中，3月12日张文的分享已经结束，没来得及参与的小伙伴不用担心，以下就是直播的视频和文字回顾。
在分布式系统中不可避免的会遇到网络故障，机器宕机，磁盘损坏等问题，为了向用户不中断且正确的提供服务，要求系统有一定的冗余与容错能力。RocketMQ 在日志，统计分析，在线交易，金融交易等丰富的生产场景中发挥着至关重要的作用，而不同环境对基础设施的成本与可靠性提出了不同的诉求。在 RocketMQ v4 版本中有两种主流高可用设计，分别是主备模式的无切换架构和基于 Raft 的多副本架构（图中左侧和右侧所示）。生产实践中我们发现，两副本的冷备模式下备节点资源利用率低，主宕机时特殊类型消息存在可用性问题；而 Raft 高度串行化，基于多数派的确认机制在扩展只读副本时不够灵活，无法很好的支持两机房对等部署，异地多中心等复杂场景。RocketMQ v5 版本融合了上述方案的优势，提出 DLedger Controller 作为管控节点（中间部分所示），将选举逻辑插件化并优化了数据复制的实现。
| 作者：杨壮壮 ，腾讯PCG运营开发工程师 ，目前主要从事 MDB（MySQL 云管平台）的后台开发与技术运营的工作，是一个做开发的DBA。熟悉腾讯自研数据库TDSQL的架构原理、集群管理维护、内核SQL优化等。MDB团队承载着整个PCG 关系型数据库的管理与运维工作，支撑着腾讯视频、看点等业务稳定运行。 1 Part1 前言 在今年的三月份，我们举办过一届数据库武林大会，在这场活动沙龙中，有辩手犀利地指出，数据库运维的薪资水平和数据库使用人数并不成正比，有数据表明一些小众但强大的数据库，其DBA的平均
假设主机ip：10.136.16.146 port：6789 备机ip：10.136.30.144
旧环境配置差一点(新环境的1/4的内存和CPU), 还是机械盘, 故想迁移到新环境
在Hadoop 1.x 中，Namenode是集群的单点故障，一旦Namenode出现故障，整个集群将不可用，重启或者开启一个新的Namenode才能够从中恢复。
最近也在对容灾的切换做一些改进。 目前碰到的问题有 1.灾难切换后备库的内核参数设置不到位，导致切换后又潜在的性能问题 2.灾难切换后在同机房，网络相关的情况下，需要切换备库的IP为主库，但是跨机房，跨IDC可能不行，可以修改IP的情况下，对应用基本是透明，但是如果修改IP就需要应用修改配置。 3.灾难切换之后防火墙信息在主库无法得到的情况，在备库只能关闭防火墙，或者设置最大的访问权限 4.原来主库中的db link可能无法正常解析，如果解析不当或者依赖较多，会有数据库负载成百倍暴涨的可能性 5.原来主库启
正常情况下，只要主库执行更新生成的所有binlog，都可以传到备库并被正确执行，备库就能达到跟主库一致的状态，这就是最终一致性。
HBase本身是一个没有单点故障的分布式系统，上层（HBase层）和底层（HDFS层）都通过一定的技术手段保障了服务的可用性，HMaster一般都是高可用部署，如果集群中RegionServer宕机，region的迁移代价并不大，一般在毫秒级就能完成，所以对应用造成的影响也很有限；底层存储依赖于HDFS，数据本身默认也有3副本，数据存储上做到了多副本冗余，而在当前方案中将HBase当做单机使用。
关系数据库的事务（transaction）是一组操作序列，比如读，插入，删除，更新等等。事务有四个基本要素，即原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability），即ACID：
对于Oracle Data Guard中的Switchover一般是计划内的操作，自己其实也处理了不少的故障，也算是轻门熟路。复杂的事情简单做，简单的事情重复做，重复的事情用心做，想必很多事情都是这个理吧。 发现很多事情虽然做了很多遍，但是每次都会有不同的体会，而这些积累下来的经验才让我们的经验更加宝贵。 一般来说Oracle的Switchover需要考虑的细节较多，大体有以下的流程。 1.在迁移之前明确目标服务器IP，发出维护公告 这个无需多说，本身就是跨部门，多部门的协调工作，说简单简单，说复杂复
半同步复制在提交过程中增加了一个延迟：提交事务时，在客户端接收到查询结束反馈前必须保证二进制日志已经传输到一台备库上。
在数据库运维过程中，很多问题都需要靠人力来及时发现和处理，我之前也是一名DBA，可以说我做DBA的那段时间基本没有拥有过完整的属于自己的休息时间，全天候Online。现在AI技术已经广泛运用到了各个领域，数据库运维其实也是同样的，AI可以成为DBA的得力助手，有问题第一时间告警，甚至给出成熟的解决方案，DBA可以用更多的时间去完成高阶的任务。我现在主要负责的产品是DBbrian，是腾讯云推出的一款数据库智能运维工具。今天就以咱们MySQL运维过程中典型的主从延时故障来作为案例，告诉大家可以如何借助智能运维服务更好的发现和解决这类问题。
PostgreSQL 高可用数据库的常见搭建方式主要有两种，逻辑复制和物理复制，上周已经写过了关于在Windows环境搭建PostgreSQL逻辑复制的教程，这周来记录一下 物理复制的搭建方法。
读写分离的主要目的就是分摊主库的压力。上图中的结构是客户端主动做负载均衡，这种模式下一般会把数据库的连接信息放在客户端的连接层。由客户端来选择后端数据库进行查询
作者介绍 黄堋 多年一线DBA经验，曾服务于电信、电网、医院等行业客户。擅长数据库优化、数据库升级迁移、数据库故障处理 当主备同步中断了，备库想快一点恢复，偏偏这个时候归档太多恢复不过来或者说需要的归
看这里的name是否和你的服务器的计算机名称一样,如果一样可以跳到文档(二)，否则请按如下操作更改
读写分离的主要目标就是分摊主库的压力。图 1 中的结构是客户端（client）主动做负载均衡，这种模式下一般会把数据库的连接信息放在客户端的连接层。也就是说，由客户端来选择后端数据库进行查询。
对于一个启用了Kerberos的正式生产系统，还需要考虑KDC的高可用。而Kerberos服务是支持配置为主备模式的，数据同步是通过kprop服务将主节点的数据同步到备节点。本文主要讲述如何在CDH5.16.1中配置Kerberos服务的高可用。在前面的文章中Fayson介绍过《如何配置Kerberos服务的高可用》，但无论是CDH还是OS版本到较低，本文也主要是为了更新文档。
sql server 作为目前主流的数据库，用户遍布世界各地。sql server也有一些比较成熟的主备方案，目前主要有：复制模式(发布-订阅模式)、镜像传输模式、日志传输模式、故障转移集群。后面会一一介绍介绍各自的优缺点。
一个可以抵抗高并发流量系统的背后必定有一个高性能的数据库集群，就像每一个成功的男人背后总有一个强势的女人一样。数据库集群在部署模式上属于分布式，但是CAP原则却不适用于分布式数据库，具体原因可见之前文章：、
洪嘉铭，就职于世纪证券信息技术部，目前负责运维、监控系统的相关架构设计、开发工作。对操作系统、网络编程、服务器后台架构有丰富实践经验。
Fayson在之前的文章中介绍过《CDH网络要求(Lenovo参考架构)》，《如何为Hadoop集群选择正确的硬件》和《CDH安装前置准备》，而我们在搭建Hadoop集群时，还一件很重要的事就是如何给集群分配角色。
在PG10及以后版本中，引入了 synchronous_standby_names 这种基于 Quorum的同步复制优选提交的机制。
前面Fayson文章讲《1.如何在CentOS6.5安装OpenLDAP并配置客户端》以及《2.OpenLDAP集成SSH登录并使用SSSD同步用户》，那么如何确保OpenLDAP服务的高可用？本篇文章主要介绍如何通过OpenLDAP的MorrorMode实现主主同步，即OpenLDAP的两个服务都可以读写，当主OpenLDAP节点宕机后，可以切换到备节点，可以通过Keepalived实现OpenLDAP故障转移。
本节主要讨论在系统扩容期间的数据迁移架构及节点的状态图。我们将通过介绍这两部分，慢慢展开复杂的扩缩容流程。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
