主从数据库必须要同一版本，不同版本可能会出现各种各样的错误 比如我刚开始就用了5.7和5.5的不同版本，结果出现了一大堆错误，而且还是解决不了的那种 最后不得不把5.5升级到了5.7，成功
在数据库中数据极速增长的情况下，数据库的瓶颈不在于存储，而是计算，即查询。数据量越大，查询的效率越低，对于越复杂的查询语句，其消耗服务器的资源越强，有时甚至不输于死循环。
在前面的文章中，我不止一次地和你提到了 binlog，大家知道 binlog 可以用来归档，也可以用来做主备同步，但它的内容是什么样的呢？为什么备库执行了 binlog 就可以跟主库保持一致了呢？今天我就正式地和你介绍一下它。
②.[root@localhostsrc]#wget http://repo.mysql.com/mysql57-community-release-el7-8.noarch.rpm
一、双击热备介绍 1.基本概念 双机热备特指基于高可用系统中的两台服务器的热备（或高可用），双机高可用按工作中的切换方式分为：主-备方式（Active-Standby方式）和双主机方式（Active-Active方式），主-备方式即指的是一台服务器处于某种业务的激活状态（即Active状态），另一台服务器处于该业务的备用状态（即Standby状态)。而双主机方式即指两种不同业务分别在两台服务器上互为主备状态（即Active-Standby和Standby-Active状态）。 2.实现方式 a.基于共享存
线程死锁是指由于两个或者多个线程互相持有对方所需要的资源，导致这些线程处于等待状态，无法前往执行。当线程进入对象的synchronized代码块时，便占有了资源，直到它退出该代码块或者调用wait方法，才释放资源，在此期间，其他线程将不能进入该代码块。当线程互相持有对方所需要的资源时，会互相等待对方释放资源，如果线程都不主动释放所占有的资源，将产生死锁。
在状态1中，客户端的读写都直接访问节点A，而节点B是A的备库，只是将A的更新都同步过来，到本地执行。这样可以保持节点B和A的数据是相同的。当需要切换的时候，就切成状态2。这时候客户端读写访问的都是节点B，而节点A是B的备库
在状态 1 中，客户端的读写都直接访问节点 A，而节点 B 是 A 的备库，只是将 A 的更新都同步过来，到本地执行。这样可以保持节点 B 和 A 的数据是相同的
多线程一直以来都是面试必考点，而volatile、synchronized也是必问点，这里我试图用容易理解的方式来解释一下volatile。
在状态1中,客户端的读写都直接访问节点A,而节点B是A的备库，只有将A的更新都同步过来，到本地执行，这样可以保证节点B和A的数据是相同的
因上篇文章《程序员眼中的Synchronized同步锁》对synchronized关键字进行来详解。本篇文章主要对volatile关键字进行解剖。
上部分状态：客户端的读写都直接访问A，B是A的备库，只是将A的更新都同步过来，到本地执行。这样可以保持B和A的数据相同。
1.从库的IO线程向主库的主进程发送请求，主库验证从库，交给主库IO线程负责数据传输; 2.主库IO线程对比从库发送过来的master.info里的信息，将binlog文件信息，偏移量和binlog文件名等发送给从库 3.从库接收到信息后，将binlog信息保存到relay-bin中，同时更新master.info的偏移量和binlog文件名 4.从库的SQL线程不断的读取relay-bin的信息，同时将读到的偏移量和文件名写道relay-log.info文件，binlog信息写进自己的数据库，一次同步操作完成。 5.完成上次同步后，从库IO线程不断的向主库IO线程要binlog信息 6.从库如果也要做主库，也要打开log_bin 和log-slave-update参数
版本： redis-3.2.9 部署： 5台64G内存的物理机，每台机器启动2个redis进程组成5主5备集群，每台机器1个主1个备，并且错开互备。 问题： 发现redis进程占用内存高达40G，而且全是备进程。尝试通过重启进程方式释放内存，但进入复制死循环，报如下所示错误： for lack of backlog (Slave request was: 51875158284) 通过网上查找资料，修改client-output-buffer-limit和repl-timeout值，问题未能得到解决，仍然报for lack of backlog，并仍然循环复制。 move备进程的data目录，但保留nodes.conf文件，然后再重启，这次重启成功。采取同样方法处理其它备进程，同样成功，内存同样降到和主进程接近的大小10G。 待分析：为何备进程占用的内存是它的主进程的4倍（分别40G和10G）？除了上述方法外，是否有其它更安全可靠的释放办法？
数据库读写分离对于大型系统或者访问量很高的互联网应用来说，是必不可少的一个重要功能。
可以在任意个主从库之间建立复杂的复制拓扑结构，如普通的一主一（多）从、双（多）主复制、级联复制，MySQL 5.7.2后新增的多源复制，特殊场景下使用的Blackhole引擎与日志服务器等等。复制中的MySQL服务器须要遵循以下基本原则：
6379redis写入数据，在6380里是可以看到的，并且因为配置了只读，所以我在6380redis里操作set命令不能成功。
•当你使用了redis或者其他中间件做缓存的时候，经常发现缓存和数据库的数据不一致，只能通过定时任务或者缓存过期的方式去做一些限制。•当你使用了ES做搜索工具，使用双写的那一套方法，还在为ES和数据库不是一个事务而担忧。•当你需要迁移数据的时候，也还在使用双写的方法，如果是同一个数据库的还好，如果是不同数据库就不能保证事务，那么数据一致性也是个问题，就会写很多的修复Job和检查Job。
MYSQL CTE 是8.0 引入的SQL 查询的一种功能,通过CTE 可以将复杂的SQL 变得简单,便于分析和查询. 其中CTE 有一种功能递归, 并且牵扯到递归就会有一个问题的提出,就是无限递归的问题.
大家好，我是Leo。前面文章我们介绍了WAL的安全机制。可以保证数据的安全性。通过安全性我们分析了binlog，redolog日志的写入机制。今天我们分析一下主从库的实现原理！MySQL是如何保证主从库的数据是一致的呢？
对于双主MySQL设置，确实需要对写操作进行分区以避免数据冲突。以下是一些可能的策略：
在参与公司几个多数据中心项目的容灾架构设计后，积累了一些高可用和多数据中心容灾的一些思考，总结和分享出来希望一起和大家学习。
一套MySQL主-备-备-备数据库，其中的备库升级到主库之后，系统监控报警 Seconds_Behind_Master 瞬间为0，瞬间为数十万秒。第一感觉是遇到了复制风暴--不同于主备server_id 的log event在主备库之间无限循环复制。升级的逻辑图如下:
做开发写程序，最麻烦就是写循环。一个程序功能里面如果多于5个循环的，那么要么这个业务逻辑有问题，要么就是开发的人太Yang。用5个循环去做一个业务逻辑，耗时耗资源不说；假设其中有个死循环那就死翘翘了。
我经常使用的数据库是 MySQL，它是一个开源的关系型数据库管理系统，现在隶属于 Oracle 旗下。
我们先来了解一下主备同步的原理，下面以一个update语句来介绍主库与备库间是如何进行同步的。
该节点仅参与MGR投票仲裁，不存放实际数据，也无需执行DML操作，因此可以用一般配置级别的服务器，在保证MGR可靠性的同时还能降低服务器成本。
只要是对于集合有一定了解的一定都知道HashMap是线程不安全的，我们应该使用ConcurrentHashMap。但是为什么HashMap是线程不安全的呢，之前面试的时候也遇到到这样的问题，但是当时只停留在***知道是***的层面上，并没有深入理解***为什么是***。于是今天重温一个HashMap线程不安全的这个问题。
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. 结论与建议
作者简介 Roy，携程软件技术专家，负责MySQL双向同步DRC和数据库访问中间件DAL的开发演进，对分布式系统高可用设计、分布式存储，数据一致性领域感兴趣。 一、前言 在携程国际化战略背景下，海外业务将成为新的发力点，为了保证用户高品质的服务体验，底层数据势必需要就近服务业务应用。一套标准且普适的数据复制解决方案能够提升业务决策效率，助力业务更快地触达目标用户。 DRC (Data Replicate Center) 作为携程内部数据库上云标准解决方案，支撑了包括但不限于即时通讯、用户账号、IBU在内的
在使用数据库时，表的主键经常会使用数据库的自增（auto_increment）来产生。这当然很方便也很高效。但是使用自增也会带来一些麻烦。如果从一个数据库以外的地方，也就是发号器来产生全局唯一 ID，这些问题就可以得到解决，生活就可以更美好。
rpm -ivh mysql-community-release-el6-5.noarch.rpm
Java Hotspot 虚拟机中，每个对象都有对象头（包括 class 指针和 Mark Word)。Mark Word 平时存储这个对象的 哈希码、分代年龄，当加锁时，这些信息就根据情况被替换为 标记位(轻重量级锁)、线程锁记录指针、重量级锁指针、线程ID等内容。
多线程并发是Java语言中非常重要的一块内容，同时，也是Java基础的一个难点。说它重要是因为多线程是日常开发中频繁用到的知识，说它难是因为多线程并发涉及到的知识点非常之多，想要完全掌握Java的并发相关知识并非易事。也正因此，Java并发成了Java面试中最高频的知识点之一。本系列文章将从Java内存模型、volatile关键字、synchronized关键字、ReetrantLock、Atomic并发类以及线程池等方面来系统的认识Java的并发知识。通过本系列文章的学习你将深入理解volatile关键字的作用，了解到synchronized实现原理、AQS和CLH队列锁，清晰的认识自旋锁、偏向锁、乐观锁、悲观锁...等等一系列让人眼花缭乱的并发知识。
repeat循环类似于java中的do...while循环，不管如何，循环都会先执⾏⼀次，然
方法区：主要是存储类信息，常量池（static 常量和 static 变量），编译后的代码（字
Mysql内建的复制功能是构建大型，高性能应用程序的基础。将Mysql的数据分布在多个系统之上，这种分布的机制，是通过将Mysql的某一台主机的数据复制到其它主机（slaves）上，并重新执行一遍来实现的。复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新，然后封锁并等待主服务器通知新的更新。
此例是多副本的 MySQL 数据库。 示例应用的拓扑结构有一个主服务器和多个副本，使用异步的基于行（Row-Based）的数据复制。
MySQL安装参考之前的文章https://www.jianshu.com/p/452aa99c7476有讲解。
但存在几个问题，不能实时更新数据，制作的是静态的仪表盘，每次生成仪表盘都要调整代码，不能一运行就直接生成可视化仪表盘。
1、loop实现了一个简单的循环，退出循环的条件需要用其他语句定义，通常可以使用leave语句实现。
2、关于指针下列说法正确的是【多选】（ ） A、 任何指针都可以转化为void * B、 void *可以转化为任何指针 C、 指针的大小为8个字节 D、 指针虽然高效、灵活但可能不安全
经常有些面试官会问，是否了解过 HashMap 在多线程环境下使用时可能会发生死循环，导致服务器 cpu 100% 的线上故障？
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
云直播
