郴州网站建设制作,设计网页时有哪些配色方法,电子商务运营实务中网站开发流程,东莞百度seo找谁MySQL作为当前最流行的关系型数据库#xff0c;在各个行业的系统中扮演着最重要的角色。随着大家对数据价值认可的逐步加深#xff0c;数据的可靠性是最常被问到的一个问题。MySQL是如何保证数据可靠性的#xff1f;京东智联云RDS-MySQL又做了哪些优化和新特性来保证用户数据…MySQL作为当前最流行的关系型数据库在各个行业的系统中扮演着最重要的角色。随着大家对数据价值认可的逐步加深数据的可靠性是最常被问到的一个问题。MySQL是如何保证数据可靠性的京东智联云RDS-MySQL又做了哪些优化和新特性来保证用户数据的可靠性和一致性本篇文章将为大家一一揭秘。MySQL的Innodb存储引擎支持ACID原子性Atomicity一致性Consistency隔离性Isolation持久性Durability特性正是因为保证了一致性和持久性所以数据才是可靠的。很多关系型数据库为保障数据库的可靠性同时最大限度地提升性能采用了预写日志Write-Ahead Logging的方法MySQL也不例外。它将数据变化先写入日志然后立刻返回给客户端更新成功真正的数据再异步更新到磁盘的数据文件。如果中间系统发生故障只要日志在数据就不会丢失这就保证了数据的可靠性。MySQL写入的日志就是binlog和redo log文件下面我们来介绍下两种日志的写入流程。事务执行过程中MySQL会将所有变更记录到binlog cache中在事务commit的时候一起写入binlog文件中。binlog cache是由参数binlog_cache_size控制默认32KB如果事务很大变更内容超过了binlog cache则会写到磁盘中。通过命令show global status like Binlog_cache_disk_use;可以查看binlog cache写入磁盘的次数如果数量过多建议调大binlog_cache_size参数值。每个线程都会分配binlog cache但是都共用一份binlog文件。流程图如下在写入到系统的日志文件中有两个步骤write和fsync。wirte是写入操作系统的缓存fsync是持久化到磁盘文件这个操作会占用系统的IOPS而它们操作的时机是通过参数sync_binlog控制。sync_binlog0事务提交时只做write操作由操作系统自己控制fsync操作。这个是最危险的一旦操作系统宕机binlog cache中的变更内容全部会丢失。sync_binlog1事务提交时都会做write和fsync操作。安全性最高但是性能损耗也是最大的。sync_binlogN事务提交时会做write操作累积N个事务时做fsync操作。一旦操作系统宕机会丢失binlog cache中部分变更内容。事务执行过程中也是先写入内存redo log buffer中然后再写入到磁盘文件。其中redo log buffer是所有线程共用的。与binlog写到文件一样写redo log也有write和fsync两个操作它们操作的实际是通过参数innodb_flush_log_at_trx_commit控制。nnodb_flush_log_at_trx_commit0事务提交时只将变更内容写到redo log buffer由后台Master线程每秒write和fsync到磁盘文件。innodb_flush_log_at_trx_commit1事务提交时执行write和fsync操作。这是最安全的配置。innodb_flush_log_at_trx_commit2事务提交时只执行write操作即只写到操作系统的缓存中由后台Master线程每秒fsync到磁盘文件。关于这个参数与数据可靠性之间的关系如下表所示参数sync_binlog1与innodb_flush_log_at_trx_commit1就是DBA常说的“双1”配置也是线上环境数据最安全最可靠的配置。再对比下binlog和redo log的不同之处binlogredo log记录者MySQL serverInnodb引擎记录时间事务commit的时候多种条件触发随时记录记录内容逻辑日志row格式或者statement格式物理日志数据页的变化幂等的binlogredo log记录者MySQL serverInnodb引擎记录时间事务commit的时候多种条件触发随时记录记录内容逻辑日志row格式或者statement格式物理日志数据页的变化幂等的binlog和redo log是如何配合起到数据可靠性的作用呢就不得不提到两阶段提交。它可以保证binlog和redo log的数据一致性。下图是事务提交时两个日志的记录流程如果在此过程中出现系统异常每个状态下都是可以保证数据一致性的。le data-draft-nodeblock data-draft-typetable data-sizenormal data-row-stylenormalinnodb_suport_xa参数这个参数控制是否打开两段式提交。默认开启如果关闭了事务则会以不同顺序的方式写入binlog。如果宕机恢复、xtarbackup恢复都是会有数据不一致的风险。这个参数在MySQL5.7.10后就废弃了必须开启。MySQL发展到现在集群也从主备异步复制、半同步复制、group replication不断发展和演变。但是它们的核心基础都是binlog可以说MySQL的数据复制都依赖于它而集群间的数据一致性更是与binlog有关。主要有两个点需要特别注意。1. binlog的格式。statement、row和mixed。statement格式直接将SQL语句记录在binlog文件中因为主从库是两个独立的服务运行环境完全不同所以会出现不一致的风险比如执行delete from t limit 100。所以线上环境建议使用row格式。2. 数据延迟。当从库出现延迟会造成集群数据不一致。从库延迟的原因很多这里列举以下几个线上经常出现的延迟原因a大事务。binlog只有在事务commit时才会记录到文件然后从库才能读取到数据变更所以当有大事务的时候主库提交后从库才开始执行。b大并发。5.6和5.7版本都支持并行复制但是并行度有限当主库并发较高时从库会出现延迟。c表结构。主库表没有主键binlog是row格式的主库执大量行数的更新SQL时从库会执行多次全表扫描造成延迟。d等待锁。从库一般会承担备份功能使用xtrabackup进行备份会执行FLUSH NO_WRITE_TO_BINLOG TABLES和FLUSH TABLES WITH READ LOCK操作在特殊情况下这两个操作会堵塞复制的SQL线程造成延迟。京东智联云RDS-MySQL集群使用主从复制架构为了保证用户存储数据可靠性和安全性我们对关键流程做了一系列优化和改善工作。以用户数据安全为己任以用户体验为中心。1. 物理环境硬件采用高性能的NVME硬盘最新型号物理机配置。网络跨AZ机器的网络延迟在1.2ms以内配置万兆网卡。2. 软件环境数据面参考京东高并发、高可靠的业务系统优化经验京东智联云对RDS操作系统配置、MySQL参数配置做了一些列优化保证数据库集群数据的可靠性。控制面针对集群的延迟有多组延迟监控、报警针对不同延迟原因会触发不同的优化逻辑自动降低延迟。当物理机出现问题或者做数据迁移时都会涉及MySQL集群的高可用操作因为MySQL集群的复制特点有可能会出现数据丢失的情况。京东智联云RDS-MySQL在切换时是要保证用户数据一致性优先的在判断集群数据完全可靠的情况下再做切换操作保证用户的数据不丢失不写花。MySQL高可用切换流程的复杂性不在切换的过程而是触发切换条件的判断下面介绍下RDS-MySQL自动高可用切换的判断流程。哨兵服务检查数据库和操作系统状态发现实例服务异常则触发多组哨兵服务的数据库服务检查和投票机制确认服务真实不可用再进行切换流程。主库实时上报GTID信息如果发生自动高可用即主库服务不可用时首先会对比从库的Retrieved_Gtid_Set值确保从库的IO thread已经拉取了主库全部的binlog内容。然后再对比从库的Retrieved_Gtid_Set和Executed_Gtid_Set范围值保证从库拉取的binlog全部应用完成。高可用流程切换完成后会对集群数据做一致性校验并触发建立新从库的流程。数据库备份是数据安全的最重要屏障当出现极端情况下集群所有节点的数据都不可用就需要依赖备份保证数据的可靠性和安全性。我们对RDS-MySQL的备份、恢复流程做了一系列优化保证用户系统在灾备时恢复时间尽量短恢复数据尽可能最新。每日全量备份实时binlog备份所有备份上传到对象存储多备份保存多区域存放定期做备份数据的有效性验证高可用、扩容、删除等重要流程强制做数据库的数据备份支持软删除功能单库表恢复功能。京东智联云RDS-MySQL的用户在使用过程中出现过很多数据可靠性相关的案例下面举一些典型案例来分享问题由于用户并发较大集群从库出现延迟。发现从库对于用户是不可见的所以从库延迟用户是无需感知的。通过后台的监控系统触发从库延迟报警运维人员才发现这个问题。解决后台任务会扫描所有报警信息当扫描到延迟报警后会结合该实例的其他信息定位故障原因然后自动调整集群数据库配置达到降低延迟的目的。延迟报警解除后恢复集群配置。意义RDS-MySQL部分报警已经实现了“负载异常检测”、“自动诊断”、“线上配置优化”、“优化效果跟踪”的闭环处理。可帮助用户快速、安全、准确地处理集群数据安全隐患。问题由于用户并发较大集群从库出现延迟。发现从库对于用户是不可见的所以从库延迟用户是无需感知的。通过后台的监控系统触发从库延迟报警运维人员才发现这个问题。解决后台任务会扫描所有报警信息当扫描到延迟报警后会结合该实例的其他信息定位故障原因然后自动调整集群数据库配置达到降低延迟的目的。延迟报警解除后恢复集群配置。意义RDS-MySQL部分报警已经实现了“负载异常检测”、“自动诊断”、“线上配置优化”、“优化效果跟踪”的闭环处理。可帮助用户快速、安全、准确地处理集群数据安全隐患。问题由于用户并发较大集群从库出现延迟。发现从库对于用户是不可见的所以从库延迟用户是无需感知的。通过后台的监控系统触发从库延迟报警运维人员才发现这个问题。解决后台任务会扫描所有报警信息当扫描到延迟报警后会结合该实例的其他信息定位故障原因然后自动调整集群数据库配置达到降低延迟的目的。延迟报警解除后恢复集群配置。意义RDS-MySQL部分报警已经实现了“负载异常检测”、“自动诊断”、“线上配置优化”、“优化效果跟踪”的闭环处理。可帮助用户快速、安全、准确地处理集群数据安全隐患。问题用户因为人为误操作导致删除了线上系统的部分数据。发现用户提工单想快速恢复删除表的数据到指定时间点。解决控制台提供单库、单表按时间点快速恢复的功能。技术服务人员直接反馈给用户该功能的使用文档。用户通过自助操作完成对删除数据的恢复操作。意义RDS-MySQL将备份和恢复功能用到极致两类备份方式对应多种恢复流程方便用户快速、安全地实现恢复数据库需求。RDS-MySQL恢复流程支持1. 根据时间点创建2. 根据时间点单库、单表本地恢复3. 根据备份创建和本地覆盖恢复问题用户因为人为误操作导致删除了线上系统的部分数据。发现用户提工单想快速恢复删除表的数据到指定时间点。解决控制台提供单库、单表按时间点快速恢复的功能。技术服务人员直接反馈给用户该功能的使用文档。用户通过自助操作完成对删除数据的恢复操作。意义RDS-MySQL将备份和恢复功能用到极致两类备份方式对应多种恢复流程方便用户快速、安全地实现恢复数据库需求。RDS-MySQL恢复流程支持1. 根据时间点创建2. 根据时间点单库、单表本地恢复3. 根据备份创建和本地覆盖恢复问题用户因为人为误操作导致删除了线上系统的部分数据。发现用户提工单想快速恢复删除表的数据到指定时间点。解决控制台提供单库、单表按时间点快速恢复的功能。技术服务人员直接反馈给用户该功能的使用文档。用户通过自助操作完成对删除数据的恢复操作。意义RDS-MySQL将备份和恢复功能用到极致两类备份方式对应多种恢复流程方便用户快速、安全地实现恢复数据库需求。RDS-MySQL恢复流程支持1. 根据时间点创建2. 根据时间点单库、单表本地恢复3. 根据备份创建和本地覆盖恢复问题用户因为人为误操作导致删除了线上系统的部分数据。发现用户提工单想快速恢复删除表的数据到指定时间点。解决控制台提供单库、单表按时间点快速恢复的功能。技术服务人员直接反馈给用户该功能的使用文档。用户通过自助操作完成对删除数据的恢复操作。意义RDS-MySQL将备份和恢复功能用到极致两类备份方式对应多种恢复流程方便用户快速、安全地实现恢复数据库需求。RDS-MySQL恢复流程支持1. 根据时间点创建2. 根据时间点单库、单表本地恢复3. 根据备份创建和本地覆盖恢复问题用户因为人为误操作导致删除了线上系统的部分数据。发现用户提工单想快速恢复删除表的数据到指定时间点。解决控制台提供单库、单表按时间点快速恢复的功能。技术服务人员直接反馈给用户该功能的使用文档。用户通过自助操作完成对删除数据的恢复操作。意义RDS-MySQL将备份和恢复功能用到极致两类备份方式对应多种恢复流程方便用户快速、安全地实现恢复数据库需求。RDS-MySQL恢复流程支持1. 根据时间点创建2. 根据时间点单库、单表本地恢复3. 根据备份创建和本地覆盖恢复
