如何将mysql的一个完整数据库全部复制到另外一个数据库?

Posted 2023-05-09

不能将A库的数据导出.sql之后再导入到B库,因为我根本不知道导入的路径是什么, 如果用语言直接操作? 就是不知道那个路径名嘛 我要知道是哪个盘的话就不用问了嘛

如果从库上表 t 数据与主库不一致，导致复制错误，整个库的数据量很大，重做从库很慢，如何单独恢复这张表的数据？通常认为是不能修复单表数据的，因为涉及到各表状态不一致的问题。下面就列举备份单表恢复到从库会面临的问题以及解决办法：

场景 1

如果复制报错后，没有使用跳过错误、复制过滤等方法修复主从复制。主库数据一直在更新，从库数据停滞在报错状态（假设 GTID 为 aaaa:1-100）。

修复步骤：

在主库上备份表 t （假设备份快照 GTID 为 aaaa:1-10000）；

恢复到从库；

启动复制。

这里的问题是复制起始位点是 aaaa:101，从库上表 t 的数据状态是领先其他表的。aaaa:101-10000 这些事务中只要有修改表 t 数据的事务，就会导致复制报错 ，比如主键冲突、记录不存在（而 aaaa:101 这个之前复制报错的事务必定是修改表 t 的事务）

解决办法：启动复制时跳过 aaaa:101-10000 这些事务中修改表 t 的事务。

正确的修复步骤：

1. 在主库上备份表 t （假设备份快照 GTID 为 aaaa:1-10000），恢复到从库；

2. 设置复制过滤，过滤表 t：

CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE = (\'db_name.t\');


3. 启动复制，回放到 aaaa:10000 时停止复制（此时从库上所有表的数据都在同一状态，是一致的）;

START SLAVE UNTIL SQL_AFTER_GTIDS = \'aaaa:10000\';


4. 删除复制过滤，正常启动复制。

注意事项：这里要用 mysqldump --single-transaction --master-data=2，记录备份快照对应的 GTID

场景 2

如果复制报错后，使用跳过错误、复制过滤等办法修复了主从复制。主、从库数据一直在更新。

修复步骤：

在主库上备份表 t （假设备份快照 GTID为 aaaa:1-10000）；

停止从库复制，GTID为 aaaa:1-20000；

恢复表 t 到从库；

启动复制。

这里的问题是复制起始位点是 aaaa:20001，aaaa:10000-20000 这些事务将不会在从库上回放，如果这里面有修改表 t 数据的事务，从库上将丢失这部分数据。

解决办法：从备份开始到启动复制，锁定表 t，保证 aaaa:10000-20000 中没有修改表 t 的事务。

正确修复步骤：

对表 t 加读锁；

在主库上备份表 t；

停止从库复制，恢复表 t；

启动复制；

解锁表 t。

如果是大表，这里可以用可传输表空间方式备份、恢复表，减少锁表时间。

参考技术A 数据库实际就是很多表的集合
所以复制库就是复制表
将表导出到
sql
文件
然后再导入 参考技术B 用
sql语句
就行了
开始→运行→输入cmd，进入命令行模式，把目录切换到数据库bin目录下
mysqldump
-u
用户名
-p
密码
--database
数据库名
>
D:abc.sql
创建一个数据库，名字和原来的相同。
mysql
-u
用户名
-p
密码
--database
数据库名
<
D:abc.sql

如何复制MySQL数据库或表到另外一台服务器

使用这种方法前，我们需要先下载一个MySQL客户端工具SqlYog。点击这里下载并安装

下面我们开始复制数据库：
1、打开SqlYog community Edition，分别在不同的选项卡中打开源数据库服务器与目标数据库服务器，这一点很重。

在源数据库服务器选项卡中你将看到所有数据库列表。
2、在需要复制迁移的数据库上右击，在弹出菜单中选择“Copy Database to Different Host/Database”
3、在弹出对话框中，我们能看到源数据库服务器及目标服务器，在左边，通过勾选复选框来选择需要复制迁移的对象，如表、函数、触发器等，也可以选择所有对象。
4、在右边选择需要迁移的目标服务器或数据库
5、根据你的需要选择复制类型：“Structure and Data”或“Structure only”，即“结构和数据”或“仅结构”。
6、选择结束后点击“Copy”按钮开始复制，知道数据迁移结束。 参考技术A 1、如果系统和mysql版本都一致，你可以直接把mysql打个包，放到另一台服务器上去后，启动mysql即可使用
2、或者只复制数据库目录，但是得看表用的哪种存储结构，例如data/db01
3、或者只复制表，也得看表用的哪种存储结构，例如data/db01/user01.*
4、或者用mysqldump导出数据，mysql导入数据，例如：
mysqldump -uuser01 -p123456 db01 > db01.sql
恢复数据
mysql -uuser01 -p123456 -Ddb01 < db01.sql 参考技术B

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=3;Query 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)