189 8069 5689
一、上传RPM包到服务器上 二、安装mysql服务器端rpm -ivhMySQL-server-5.5.8-1.rhel5.x86_64.rpm 三、安装mysql客户端 rpm -ivhMySQL-client-5.5.8-1.rhel5.x86_64.rpm 四、创建目录 在/data下创建目录，把原来的数据目录/var/lib/mysql 移到/data/mysql/data1和/data/mysql/data2下，并修改mysql目录以及子目录权限 PS:安装后默认的几个重要目录 目录 内容/var/lib/mysql 数据文件，日志文件等等/usr/bin客户端程序和脚本/usr/share/mysql 错误消息和字符集文件/etc/rc.d/init.d/mysql 启动脚本文件 创建目录 修改权限 五、修改并上传配置文件my.cnf 从服务器上的/usr/share/mysql目录中把my-innodb-heavy-4G.cnf拷贝一份到本地。编辑其内容增加数据文件和日志文件的目录，修改socket目录。 六、用mysql_multi启动多个服务 启动：mysqld_multi --defaults-file=/etc/my.cnf start1,2 查看是否启动：mysqld_multi --defaults-file=/etc/my.cnfreport 1 七、查看端口是否打开 八、连接进入指定的mysql服务器 mysql -u root -S/tmp/mysql1.sock 或者mysql -uroot -P3307 -h127.0.0.1 九、记得关闭防火墙
公司主营业务：做网站、网站设计、移动网站开发等业务。帮助企业客户真正实现互联网宣传，提高企业的竞争能力。成都创新互联是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化，感谢他们对我们的高要求，感谢他们从不同领域给我们带来的挑战，让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。成都创新互联推出石家庄免费做网站回馈大家。
大多情况下，需要可靠而有效地克隆 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 之前，如果认为有必要，需要备份当前受体数据。
rpm包安装的mysql怎样添加多实例
1、yum安装mysql：
[root@localhost Desktop]# cat /etc/yum.repos.d/rhel-local.repo
[rhel-source]
name=Red Hat Enterprise Linux $releasever - $basearch - Source
baseurl=file://"/media/RHEL_6.1 i386 Disc 1"/Server
enabled=1
gpgcheck=0
gpgkey=
[root@localhost Desktop]# yum install mysql
Loaded plugins: product-id, refresh-packagekit, subscription-manager
Updating Red Hat repositories.
rhel-source | 4.0 kB 00:00 ...
rhel-source/primary_db | 2.4 MB 00:00 ...
Setting up Install Process
Resolving Dependencies
-- Running transaction check
--- Package mysql.i686 0:5.1.52-1.el6_0.1 will be installed
-- Finished Dependency Resolution
Dependencies Resolved
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
mysql i686 5.1.52-1.el6_0.1 rhel-source 898 k
Transaction Summary
================================================================================
Install 1 Package(s)
Total download size: 898 k
Installed size: 2.3 M
Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Warning: RPMDB altered outside of yum.
Installing : mysql-5.1.52-1.el6_0.1.i686 1/1
duration: 712(ms)
Installed products updated.
Installed:
mysql.i686 0:5.1.52-1.el6_0.1
Complete!
[root@localhost Desktop]#
在同一主机上，同时开启多个不同的服务器端口，同时运行多个MySQL服务进程。MySQL是一个关系型数据库管理系统，由瑞典MySQLAB公司开发，属于Oracle旗下产品。多实例部署是在同一主机上，同时开启多个不同的服务器端口(如:3306、3307)，同时运行多个MySQL服务进程，这些服务通过不同的socket监听不同的服务器端口来提供服务。MySQL是最流行的关系型数据库管理系统之一，在WEB应用方面，MySQL是最好的应用软件之一。
这种架构一般用在以下三类场景
1. 备份多台 Server 的数据到一台如果按照数据切分方向来讲，那就是垂直切分。比如图 2，业务 A、B、C、D 是之前拆分好的业务，现在需要把这些拆分好的业务汇总起来备份，那这种需求也很适用于多源复制架构。实现方法我大概描述下：业务 A、B、C、D 分别位于 4 台 Server，每台 Server 分别有一个数据库来隔离前端的业务数据，那这样，在从库就能把四台业务的数据全部汇总起来，而不需要做额外的操作。那没有多源复制之前，要实现这类需求，只能在汇总机器上搭建多个 MySQL 实例，那这样势必会涉及到跨库关联的问题，不但性能急剧下降，管理多个实例也没有单台来的容易。
2. 用来聚合前端多个 Server 的分片数据。
同样，按照数据切分方向来讲，属于水平切分。比如图 3，按照年份拆分好的数据，要做一个汇总数据展现，那这种架构也非常合适。实现方法稍微复杂些：比如所有 Server 共享同一数据库和表，一般为了开发极端透明，前端配置有分库分表的中间件，比如爱可生的 DBLE。
3. 汇总并合并多个 Server 的数据
第三类和第一种场景类似。不一样的是不仅仅是数据需要汇总到目标端，还得合并这些数据，这就比第一种来的相对复杂些。比如图 4，那这样的需求，是不是也适合多源复制呢？答案是 YES。那具体怎么做呢？