mysql怎么从同一个mysql服务器拷贝数据库

在Mysql程序中有我自己的一个数据库共5张表，里边数据不算太多。我现在想把他们全部弄到另一台电脑中去，该怎么弄，如果不用其它的软件工具，只用Mysql自已的程序不知可否？

注：不用考虑 *** 作系统。

---------------------------------------------------------------

在dos命令提示符下使用mysqldump命令进行备份.

如下:

C:\Documents and Settings\Administrator>mysqldump yinshi >c:\\backup.txt -uroot

-p12142022

说明:yinshi是我的数据库名,里面有5张表c:\\backup.txt 是我备份出来文件名和路径

-u,-p参数后面跟的分别是用户名和密码.

将你备份出来的文件我这里是backup.txt拷贝到另一台机上,再在dos命令提示符下用mysql命令,进行恢复,如下:

C:\Documents and Settings\Administrator>mysql <c:\\backup.txt -uroot -p12142022

or

mysql>source backup.txt(这里backup.txt在放在data目录下)

---------------------------------------------------------------

如果另一台机器上也安装了mysql，可以直接导入

C:\mysql\bin>mysqldump -h172.20.6.250 -udeveloper -p123456 --opt server_databasename | mysql -hlocalhost -uroot -C obj_databasename

172.20.6.250源服务器ip

developer源服务器连接用户名

---------------------------------------------------------------

有两种办法。

1、在B机器上装mysql。

将A机器上的mysql/data下的你的数据库目录整个拷贝下来。

将B机器上的mysql服务停止。

找到B机器上的mysql/data目录，将你拷贝的目录粘贴进去，然后启动mysql服务就可以了。

2、使用SQL语句备份和恢复

你可以使用SELECT INTO OUTFILE语句备份数据，并用LOAD DATA INFILE语句恢复数据。这种方法只能导出数据的内容，不包括表的结构，如果表的结构文件损坏，你必须要先恢复原来的表的结构。

语法：

SELECT * INTO {OUTFILE | DUMPFILE} ’file_name’ FROM tbl_name

LOAD DATA [LOW_PRIORITY] [LOCAL] INFILE ’file_name.txt’ [REPLACE | IGNORE]

INTO TABLE tbl_name

SELECT ... INTO OUTFILE ’file_name’

MySQL 8.0.17 clone 插件的安装和验证过程

安装非常简单，与安装其他插件的工作方式相同。下面是安装克隆插件的命令行：

 master [localhost:45008] ((none)) >INSTALL PLUGIN clone SONAME 'mysql_clone.so'Query OK, 0 rows affected (0.00 sec)

以及如何检查克隆插件是否处于活动状态：master [localhost:45008] ((none)) >SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINSWHERE PLUGIN_NAME LIKE 'clone'+-------------+---------------+| PLUGIN_NAME | PLUGIN_STATUS |+-------------+---------------+| clone | ACTIVE |+-------------+---------------+1 row in set (0.00 sec)

请注意，这些步骤需要在 Donor（供体）和 Recipient（受体，也成为 Slave）上都执行。执行安装后，插件将在重新启动后自动加载，因此您不必再担心这一点。接下来，我们将在 Donor 上创建具有必要权限的用户，这样我们就可以远程连接到实例来克隆它。

master [localhost:45008] ((none)) >create user clone_user@'%' identified by 'sekret'

Query OK, 0 rows affected (0.01 sec)

master [localhost:45008] ((none)) >GRANT BACKUP_ADMIN ON *.* TO 'clone_user'@'%'

Query OK, 0 rows affected (0.00 sec)

作为安全措施，我建议将百分号 ％ 替换为从机的 IP、主机名或网络掩码，以便只有未来的从服务器才能接受连接。现在，从服务器上，克隆用户需要CLONE_ADMIN 权限来替换从机数据，在克隆 *** 作期间阻止 DDL 并自动重新启动服务器。

slave1 [localhost:45009] ((none)) >create user clone_user@'localhost' identified by 'sekret'

Query OK, 0 rows affected (0.01 sec)

slave1 [localhost:45009] ((none)) >GRANT CLONE_ADMIN ON *.* TO 'clone_user'@'localhost'

Query OK, 0 rows affected (0.00 sec)

接下来，安装并验证插件，并在主和从服务器上创建用户。

克隆过程

如上所述，克隆过程可以在本地或远程执行。此外，它支持复制，这意味着克隆 *** 作从捐赠者提取和传输复制坐标并将其应用于收件人。它可用于 GTID 或非 GTID 复制。因此，要开始克隆过程，首先，让我们确保有一个有效的供体（Master）。这由 clone_valid_donor_list 参数控制。由于它是动态参数，您可以在服务器运行时进行更改。使用 show variables 命令将显示参数是否具有有效的供体（Master）：slave1 [localhost:45009] ((none)) >SHOW VARIABLES LIKE 'clone_valid_donor_list'+------------------------+-------+| Variable_name | Value |+------------------------+-------+| clone_valid_donor_list | |+------------------------+-------+1 row in set (0.01 sec)

例子中，我们需要对它进行设置：slave1 [localhost:45009] ((none)) >set global clone_valid_donor_list = '127.0.0.1:45008'Query OK, 0 rows affected (0.00 sec)

下一步不是强制性的，但使用默认的 log_error_verbosity，错误日志不会显示有关克隆进度的大量信息。所以，对于这个例子，我会将详细程度调整到更高的级别（在供体和受体机上）：mysql >set global log_error_verbosity=3Query OK, 0 rows affected (0.00 sec)

现在，让我们在受体（Slave）上开始克隆过程：slave1 [localhost:45009] ((none)) >CLONE INSTANCE FROM clone_user@127.0.0.1:45008 identified by 'sekret'Query OK, 0 rows affected (38.58 sec)

这种架构一般用在以下三类场景

1. 备份多台 Server 的数据到一台如果按照数据切分方向来讲，那就是垂直切分。比如图 2，业务 A、B、C、D 是之前拆分好的业务，现在需要把这些拆分好的业务汇总起来备份，那这种需求也很适用于多源复制架构。实现方法我大概描述下：业务 A、B、C、D 分别位于 4 台 Server，每台 Server 分别有一个数据库来隔离前端的业务数据，那这样，在从库就能把四台业务的数据全部汇总起来，而不需要做额外的 *** 作。那没有多源复制之前，要实现这类需求，只能在汇总机器上搭建多个 MySQL 实例，那这样势必会涉及到跨库关联的问题，不但性能急剧下降，管理多个实例也没有单台来的容易。

2. 用来聚合前端多个 Server 的分片数据。

同样，按照数据切分方向来讲，属于水平切分。比如图 3，按照年份拆分好的数据，要做一个汇总数据展现，那这种架构也非常合适。实现方法稍微复杂些：比如所有 Server 共享同一数据库和表，一般为了开发极端透明，前端配置有分库分表的中间件，比如爱可生的 DBLE。

3. 汇总并合并多个 Server 的数据

第三类和第一种场景类似。不一样的是不仅仅是数据需要汇总到目标端，还得合并这些数据，这就比第一种来的相对复杂些。比如图 4，那这样的需求，是不是也适合多源复制呢？答案是 YES。那具体怎么做呢？

---