本文目录一览：
- 1、五大常见的MySQL高可用方案(最全)
- 2、如何新建立一个mysql实例？
- 3、北大青鸟设计培训：mysql服务器架构可扩展性特点？
- 4、怎样获取 mysql数据库服务器地址
- 5、MySQL安装错误
- 6、mysql怎样创建数据库服务器
五大常见的MySQL高可用方案(最全)
1. 概述
我们在考虑MySQL数据库的高可用的架构时，主要要考虑如下几方面：
如果数据库发生了宕机或者意外中断等故障，能尽快恢复数据库的可用性，尽可能的减少停机时间，保证业务不会因为数据库的故障而中断。
用作备份、只读副本等功能的非主节点的数据应该和主节点的数据实时或者最终保持一致。
当业务发生数据库切换时，切换前后的数据库内容应当一致，不会因为数据缺失或者数据不一致而影响业务。
关于对高可用的分级在这里我们不做详细的讨论，这里只讨论常用高可用方案的优缺点以及高可用方案的选型。
2. 高可用方案
2.1. 主从或主主半同步复制
使用双节点数据库，搭建单向或者双向的半同步复制。在5.7以后的版本中，由于lossless replication、logical多线程复制等一些列新特性的引入，使得MySQL原生半同步复制更加可靠。
常见架构如下：
通常会和proxy、keepalived等第三方软件同时使用，即可以用来监控数据库的 健康 ，又可以执行一系列管理命令。如果主库发生故障，切换到备库后仍然可以继续使用数据库。
优点：
架构比较简单，使用原生半同步复制作为数据同步的依据；
双节点，没有主机宕机后的选主问题，直接切换即可；
双节点，需求资源少，部署简单；
缺点：
完全依赖于半同步复制，如果半同步复制退化为异步复制，数据一致性无法得到保证；
需要额外考虑haproxy、keepalived的高可用机制。
2.2. 半同步复制优化
半同步复制机制是可靠的。如果半同步复制一直是生效的，那么便可以认为数据是一致的。但是由于网络波动等一些客观原因，导致半同步复制发生超时而切换为异步复制，那么这时便不能保证数据的一致性。所以尽可能的保证半同步复制，便可提高数据的一致性。
该方案同样使用双节点架构，但是在原有半同复制的基础上做了功能上的优化，使半同步复制的机制变得更加可靠。
可参考的优化方案如下：
2.2.1. 双通道复制
半同步复制由于发生超时后，复制断开，当再次建立起复制时，同时建立两条通道，其中一条半同步复制通道从当前位置开始复制，保证从机知道当前主机执行的进度。另外一条异步复制通道开始追补从机落后的数据。当异步复制通道追赶到半同步复制的起始位置时，恢复半同步复制。
2.2.2. binlog文件服务器
搭建两条半同步复制通道，其中连接文件服务器的半同步通道正常情况下不启用，当主从的半同步复制发生网络问题退化后，启动与文件服务器的半同步复制通道。当主从半同步复制恢复后，关闭与文件服务器的半同步复制通道。
优点：
双节点，需求资源少，部署简单；
架构简单，没有选主的问题，直接切换即可;
相比于原生复制，优化后的半同步复制更能保证数据的一致性。
缺点：
需要修改内核源码或者使用mysql通信协议。需要对源码有一定的了解，并能做一定程度的二次开发。
依旧依赖于半同步复制，没有从根本上解决数据一致性问题。
2.3. 高可用架构优化
将双节点数据库扩展到多节点数据库，或者多节点数据库集群。可以根据自己的需要选择一主两从、一主多从或者多主多从的集群。
由于半同步复制，存在接收到一个从机的成功应答即认为半同步复制成功的特性，所以多从半同步复制的可靠性要优于单从半同步复制的可靠性。并且多节点同时宕机的几率也要小于单节点宕机的几率，所以多节点架构在一定程度上可以认为高可用性是好于双节点架构。
但是由于数据库数量较多，所以需要数据库管理软件来保证数据库的可维护性。可以选择MMM、MHA或者各个版本的proxy等等。常见方案如下：
2.3.1. MHA+多节点集群
MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master，整个故障转移过程对应用程序完全透明。
MHA Node运行在每台MySQL服务器上，主要作用是切换时处理二进制日志，确保切换尽量少丢数据。
MHA也可以扩展到如下的多节点集群：
优点：
可以进行故障的自动检测和转移;
可扩展性较好，可以根据需要扩展MySQL的节点数量和结构;
相比于双节点的MySQL复制，三节点/多节点的MySQL发生不可用的概率更低
缺点：
至少需要三节点，相对于双节点需要更多的资源;
逻辑较为复杂，发生故障后排查问题，定位问题更加困难;
数据一致性仍然靠原生半同步复制保证，仍然存在数据不一致的风险;
可能因为网络分区发生脑裂现象;
2.3.2. zookeeper+proxy
Zookeeper使用分布式算法保证集群数据的一致性，使用zookeeper可以有效的保证proxy的高可用性，可以较好的避免网络分区现象的产生。
优点：
较好的保证了整个系统的高可用性，包括proxy、MySQL;
扩展性较好，可以扩展为大规模集群;
缺点：
数据一致性仍然依赖于原生的mysql半同步复制;
引入zk，整个系统的逻辑变得更加复杂;
2.4. 共享存储
共享存储实现了数据库服务器和存储设备的解耦，不同数据库之间的数据同步不再依赖于MySQL的原生复制功能，而是通过磁盘数据同步的手段，来保证数据的一致性。
2.4.1. SAN共享储存
SAN的概念是允许存储设备和处理器（服务器）之间建立直接的高速网络（与LAN相比）连接，通过这种连接实现数据的集中式存储。常用架构如下：
使用共享存储时，MySQL服务器能够正常挂载文件系统并操作，如果主库发生宕机，备库可以挂载相同的文件系统，保证主库和备库使用相同的数据。
优点：
两节点即可，部署简单，切换逻辑简单；
很好的保证数据的强一致性；
不会因为MySQL的逻辑错误发生数据不一致的情况；
缺点：
需要考虑共享存储的高可用；
价格昂贵；
2.4.2. DRBD磁盘复制
DRBD是一种基于软件、基于网络的块复制存储解决方案，主要用于对服务器之间的磁盘、分区、逻辑卷等进行数据镜像，当用户将数据写入本地磁盘时，还会将数据发送到网络中另一台主机的磁盘上，这样的本地主机(主节点)与远程主机(备节点)的数据就可以保证实时同步。常用架构如下：
当本地主机出现问题，远程主机上还保留着一份相同的数据，可以继续使用，保证了数据的安全。
DRBD是linux内核模块实现的快级别的同步复制技术，可以与SAN达到相同的共享存储效果。
优点：
两节点即可，部署简单，切换逻辑简单；
相比于SAN储存网络，价格低廉；
保证数据的强一致性；
缺点：
对io性能影响较大；
从库不提供读操作；
2.5. 分布式协议
分布式协议可以很好解决数据一致性问题。比较常见的方案如下：
2.5.1. MySQL cluster
MySQL cluster是官方集群的部署方案，通过使用NDB存储引擎实时备份冗余数据，实现数据库的高可用性和数据一致性。
优点：
全部使用官方组件，不依赖于第三方软件；
可以实现数据的强一致性；
缺点：
国内使用的较少；
配置较复杂，需要使用NDB储存引擎，与MySQL常规引擎存在一定差异；
至少三节点；
2.5.2. Galera
基于Galera的MySQL高可用集群， 是多主数据同步的MySQL集群解决方案，使用简单，没有单点故障，可用性高。常见架构如下：
优点：
多主写入，无延迟复制，能保证数据强一致性；
有成熟的社区，有互联网公司在大规模的使用；
自动故障转移，自动添加、剔除节点；
缺点：
需要为原生MySQL节点打wsrep补丁
只支持innodb储存引擎
至少三节点；
2.5.3. POAXS
Paxos 算法解决的问题是一个分布式系统如何就某个值（决议）达成一致。这个算法被认为是同类算法中最有效的。Paxos与MySQL相结合可以实现在分布式的MySQL数据的强一致性。常见架构如下：
优点：
多主写入，无延迟复制，能保证数据强一致性；
有成熟理论基础；
自动故障转移，自动添加、剔除节点；
缺点：
只支持innodb储存引擎
至少三节点；
3. 总结
随着人们对数据一致性的要求不断的提高，越来越多的方法被尝试用来解决分布式数据一致性的问题，如MySQL自身的优化、MySQL集群架构的优化、Paxos、Raft、2PC算法的引入等等。
而使用分布式算法用来解决MySQL数据库数据一致性的问题的方法，也越来越被人们所接受，一系列成熟的产品如PhxSQL、MariaDB Galera Cluster、Percona XtraDB Cluster等越来越多的被大规模使用。
随着官方MySQL Group Replication的GA，使用分布式协议来解决数据一致性问题已经成为了主流的方向。期望越来越多优秀的解决方案被提出，MySQL高可用问题可以被更好的解决。
如何新建立一个mysql实例？
在原有实例下创建副本应该可以达到效果。
大多情况下，需要可靠而有效地克隆 MySQL 实例数据。这包括 MySQL 高可用的解决方案，其中需要在将实例加入组复制集群之前配置实例，或者在经典复制模型中将其添加为 Slave。
为复制拓扑而创建 MySQL 副本一直很麻烦。涉及的步骤很多，首先要备份 MySQL 服务器，通过网络将备份传输到我们想要添加到复制集的新 MySQL 节点，然后在该节点上恢复备份并手动启动 MySQL 服务器。为了高可用，最好还要将其正确设置备份的 GTID，并启动并运行群集。涉及的手动步骤数量过多不利于高可用。CLONE 插件解决了这个问题并简化了副本配置。使您可以使用 MySQL 客户端（和 SQL 命令）来配置新节点并在发生时观察克隆进度。无需手动处理多个步骤并维护自己的基础架构来配置新的 MySQL 节点。
MySQL 8.0.17 引入了 CLONE SQL 语句，使当前的 MySQL 服务器成为另一个运行在不同节点的 MySQL 服务器的“克隆”。我们将执行 clone 语句的服务器实例称为“受体”。克隆的源服务器实例称为“供体”。供体克隆以一致的快照存储在 InnoDB 存储引擎中的所有数据和元数据，以替换受体中的数据。
成功执行 CLONE SQL 语句后，将自动重新启动受体服务器。重新启动涉及恢复克隆的快照数据，就像用老方法复制数据一样。恢复完成后，受体就是供体的克隆版，随时可以使用！
这里有一些关于克隆过程的重要注意事项。
不克隆 MySQL 配置参数，并且受体保留所有原始配置参数，如克隆之前。这样做是因为许多配置可能特定于节点（例如 PORT），因此保留它们似乎是一个不错的选择。另一方面，一些存储配置确实需要在供体和受体之间匹配（例如 innodbpagesize），如果这样的配置参数不匹配，CLONE 将报告错误。
CLONE 插件不会克隆二进制日志。
CLONE 插件目前仅支持 InnoDB 存储引擎。在其他存储引擎（如 MyISAM 和 CSV）中创建的表将被克隆为空表。克隆基础架构的设计允许克隆 MySQL 支持的任何存储引擎。但是，只有 InnoDB 序列化和反序列化方法已经实现并经过测试。
克隆会阻止供体中的所有并发 DDL。
需要注意的事实是受体放弃所有数据以及任何二进制日志，以便成为供体实例的克隆。在执行 CLONE 之前，如果认为有必要，需要备份当前受体数据。
北大青鸟设计培训：mysql服务器架构可扩展性特点？
服务器架构随着应用场景的不同采用的架构方式也是不一样的，而今天我们就通过案例分析来简单学习一下，在服务器架构中的可扩展性都有哪些特点。
MySQL的可扩展性架构的可扩展性往往和并发是息息相关，没有并发的增长，也就没有必要做高可扩展性的架构，这里对可扩展性进行简单介绍一下，常用的扩展手段有以下两种Scale-up:纵向扩展，通过替换为更好的机器和资源来实现伸缩，提升服务能力Scale-out:横向扩展,通过加节点(机器)来实现伸缩，提升服务能力对于互联网的高并发应用来说，无疑Scaleout才是出路，通过纵向的买更的机器一直是我们所避讳的问题，也不是长久之计，在scaleout的理论下，可扩展性的理想状态是什么?可扩展性的理想状态一个服务，当面临更高的并发的时候，能够通过简单增加机器来提升服务支撑的并发度，且增加机器过程中对线上服务无影响(nodowntime)，这就是可扩展性的理想状态!MySQL架构的演变MySQL简单网站架构(V1.0)一个简单的小型网站或者应用背后的架构可以非常简单,数据存储只需要一个mysqlinstance就能满足数据读取和写入需求(这里忽略掉了数据备份的实例)，处于这个时间段的网站，一般会把所有的信息存到一个databaseinstance里面。
在这样的架构下，电脑培训来看看数据存储的瓶颈是什么?单实例单业务，依然存在V1.0所述瓶颈，遇到瓶颈时可以考虑往本文更高V版本升级,若是读请求导致达到性能瓶颈可以考虑往V3.0升级，其他瓶颈考虑往V4.0升级
怎样获取 mysql数据库服务器地址
你要用什么远程管理？一般mysql都是用phpmyadmin管理的，也就是一个PHP程序，你在LOCALHOST上装上PHPMYADMIN就可以管理了啊，远程在线式的，MYSQL不像SQL SERVER，通过本地程序化管理.
MySQL安装错误
重新安装个试试
点击下载：官方最新版mysql
MySQL的3个主要组成部分
1、负载均衡节点(mysql)
负载均衡节点(也叫SQL节点)是用来访问集群数据的。相关的软件，就是我们平时所使用的MySQL数据库软件；也就是由/etc/init.d/mysql脚本来管理的那个服务。
2、存储节点(ndbd)
数据存储节点是用来保存集群数据的，其服务的启停是由脚本/etc/init.d/mysql-ndb来管理的。
3、管理节点(ndbd-mgm)
管理节点是用来管理集群内其他节点的，比如提供配置信息、启动或停止节点、执行备份等。其服务的启停是由/etc/init.d/mysql-ndb-mgm脚本来管理的。由于这类节点是管理者，所以管理节点必须首先启动，然后其他两类节点再启动。
mysql cluster的优缺点
一、优点：
1、99.999 ％的高可用性
2、快速的自动失效切换
3、灵活的分布式体系结构，没有单点故障
4、高吞吐量和低延迟
5、可扩展性强，支持在线扩容
二、缺点：
1、存在很多限制，比如：不支持外键，数据行不能超过8K（不包括BLOB和text中的数据）
2、部署、管理、配置很复杂
3、占用磁盘空间大，内存大
4、备份和恢复不方便
5、复杂的sql查询性能一般
主要结构
1、管理(MGM)节点：
这类节点的作用是管理MySQLCluster内的其他节点，如提供配 置数据、启动并停止节点、运行备份等。由于这类节点负责管理其他节点的配置，应在启动其他节点之前首先启 动这类节点。MGM节点是用命令“ndb_mgmd”启动的。对硬件没什么要求，差一点的机器完全能够胜任。默认端口1186。
2、数据节点：
这类节点用于保存Cluster的数据。数据节点的数目与副本的数目相关，是片段的倍数。例如，对于两个副本，每个副本有两个片段，那么就有4个数据节点。不过没有必要设置多个副本。数据节点是用命令“ndbd”启动的。可以选择大内存，cpu也相对来讲不错的，尤其是以后ndbmtd对多核Cpu的支持。默认端口2202
3、SQL节点：
这是用来访问Cluster数据的节点。对于MySQLCluster，客户端节点是使用NDBCluster存储引擎的传统MySQL服务器。通常，SQL节点是使用命令“mysqld–ndbcluster”启动的，或将“ndbcluster”添加到“my.cnf”后使用“mysqld”启动。对cpu要求较高，选择多核，高频CPU较好。
新增功能
1、更强内存性能和可扩展性：
根据SysBench标准，MySQL Cluster 7.4在只读工作负载上的性能比MySQL Cluster 7.3提高了近50%，读写操作性能也提高了40%。性能改进可通过SQL或任何由MySQL Cluster支持的本地NoSQL 应用程序接口得到实现，包括Java, C++,HTTP, Memcached和JavaScript/node.js。此外，MySQL Cluster 7.4还创造了新纪录，即通过32个数据节点实现每秒2亿条NoSQL查询，以及通过 16个数据节点每秒查询近250万SQL语句
2、改进的工作负载效率分析：
现在，用户可以在MySQL 集群上使用相同的记忆优化表高效运行涉及复杂分析和随机搜索的应用负载，这为OLTP工作负载提供了亚毫秒级别的超低延迟和高水平的并发性能。这些内存表可以和基于磁盘的表共同使用
3、新的跨地域冗余功能实现跨数据中心的高可用性：
最新版本的MySQL Cluster7.4提供冲突性事务传回功能，并能在跨地域集群之间实现灵活可用、即时更新的复制功能，使得应用可以自由向任意站点发送查询或写入命令，同时完全不影响一致性
4、高级管理功能：
MySQL Cluster为内部部署和基于云的部署提供了以下改进：
新的分布式内存使用和数据库操作报告，提高管理效率;
其他性能调优选项;
更快的网络维护操作，包括软件升级速度提高多达5倍
mysql怎样创建数据库服务器
需要用到集群，负载均衡及mysql
复制(replication)；
下面提供一个系统模型你可以参考一下：
集群的结构为一个主MySQL服务器(Master)服务器与多个从属MySQL服务器(Slave)建立复制(replication)连接，主服务器与从属服务器实现一定程度上的数据同步，多个从属服务器存储相同的数据副本，实现数据冗余，提供容错功能。部署开发应用系统时，对数据库操作代码进行优化，将写操作(如UPDATE、INSERT)定向到主服务器，把大量的查询操作(SELECT)定向到从属服务器，实现集群的负载均衡功能。如果主服务器发生故障，从属服务器将转换角色成为主服务器，使应用系统为终端用户提供不间断的网络服务;主服务器恢复运行后，将其转换为从属服务器，存储数据库副本，继续对终端用户提供数据查询检索服务。
