MYSQL 基于GTID的复制

2023-11-10 来源：一二三四网

1.概述

从MYSQL5.6 开始，mysql开始支持GTID复制。

基于日志点复制的缺点：

从那个二进制日志的偏移量进行增量同步，如果指定错误会造成遗漏或者重复，导致数据不一致。

基于GTID复制：

1.从服务器会告诉主服务器已执行的事务的GTID值。

2.主库会告诉从哪些GTID事务没有被执行。

同一个事务在指定的从库执行一次。

什么是GTID

GTID即全局事务ID,器保证为每一个在主上提交的事务在复制集群中可以生成一个唯一的ID.

GTID=source_id:transaction_id

source_id:是主库的server UUID，在数据目录的auto.cnf 文件中。

transaction_id: 从1开始的一个序列。

2.基于GTID复制的步骤

1.在主DB服务器上建立复制帐号。

和日志点是一样的。

2.配置主数据库服务器

bin_log =mysql-bin

server_id=1001

gtid_mode=on

enforce-gtid-consiste:强制事务一致性，保证事务的安全

不能使用：

1.create table 。select

2.在事务中使用create temporary table 建立临时表，使用关联更新事务表和非事务表。

log-slave-updates=on

在从服务器中记录从主服务器传过来的日志数据。

使用GTID 5.6 必须使用此参数，5.7可以不使用。

3.配置从服务器。

server_id=1002

relay_log=relay_log

gtid_mode=on

enforce-gtid-consistency

建议配置

read_only=on

保证从服务器数据安全性

master_info_reposistory=TABLE

relay_log_info_reposistory=TABLE

从服务器连接主服务器的信息和中继日志存放咱 master_info，和relay_log中。

4.初始化从服务器数据。

mysqldump --master-data=2 -single-transaction

xtarbackup –slave-info

记录备份时最后的事务GTID值。

导出数据

mysqldump --single-transaction --master-data=2 --triggers -routines --all-databases -uroot -p -P3308 >all2.sql

导入数据

mysql -uroot -p -P3309 < all2.sql

5.启动基于GTID的复制

change master to master-host=’主服务IP’,

master_user=’repl’,

master_password=’password’,

master_auto_position=1

change master to MASTER_HOST=‘192.168.1.106‘, MASTER_PORT=3308, MASTER_USER=‘repl‘, MASTER_PASSWORD=‘repl‘, master_auto_position=1;

start slave;

show slave status G;

技术分享

在启动slave时报错。

ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository

解决办法：

reset slave;重置slave

再启动 slave

start slave;

测试同步：

1.在主库创建一张表，插入记录。

2.在从库查询验证是否正确，经验证配置正确。

MYSQL 基于GTID的复制

标签：

小编还为您整理了以下内容，可能对您也有帮助：

与MySQL传统复制相比，GTID有哪些独特的复制姿势

前言

GTID(Global Transaction ID)是MySQL5.6引入的功能，可以在集群全局范围标识事务，用于取代过去通过binlog文件偏移量定位复制位置的传统方式。借助GTID，在发生主备切换的情况下，MySQL的其它Slave可以自动在新主上找到正确的复制位置，这大大简化了复杂复制拓扑下集群的维护，也减少了人为设置复制位置发生误操作的风险。另外，基于GTID的复制可以忽略已经执行过的事务，减少了数据发生不一致的风险。

GTID虽好，要想运用自如还需充分了解其原理与特性，特别要注意与传统的基于binlog文件偏移量复制方式不一样的地方。本文概述了关于GTID的几个常见问题，希望能对理解和使用基于GTID的复制有所帮助。

GTID长什么样

根据官方文档定义，GTID由source_id加transaction_id构成。

GTID = source_id:transaction_id

上面的source_id指示发起事务的MySQL实例，值为该实例的server_uuid。server_uuid由MySQL在第一次启动时自动生成并被持久化到auto.cnf文件里，transaction_id是MySQL实例上执行的事务序号，从1开始递增。例如：

e6954592-8dba-11e6-af0e-fa163e1cf111:1

一组连续的事务可以用‘-‘连接的事务序号范围表示。例如

e6954592-8dba-11e6-af0e-fa163e1cf111:1-5

更一般的情况是GTID的集合。GTID集合可以包含来自多个source_id的事务，它们之间用逗号分隔；如果来自同一source_id的事务序号有多个范围区间，各组范围之间用冒号分隔，例如：

e6954592-8dba-11e6-af0e-fa163e1cf111:1-5:11-18,

e6954592-8dba-11e6-af0e-fa163e1cf3f2:1-27

即，GTID集合拥有如下的形式定义：

gtid_set:

uuid_set [, uuid_set] ...

| ‘‘

uuid_set:

uuid:interval[:interval]...

uuid:

hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh

[0-9|A-F]

interval:

n[-n]

(n >= 1)

如何查看GTID

可以通过MySQL的几个变量查看相关的GTID信息。

gtid_executed

在当前实例上执行过的GTID集合; 实际上包含了所有记录到binlog中的事务。所以，设置set sql_log_bin=0后执行的事务不会生成binlog 事件，也不会被记录到gtid_executed中。执行RESET MASTER可以将该变量置空。

gtid_purged

binlog不可能永远驻留在服务上，需要定期进行清理(通过expire_logs_days可以控制定期清理间隔)，否则迟早它会把磁盘用尽。gtid_purged用于记录已经被清除了的binlog事务集合，它是gtid_executed的子集。只有gtid_executed为空时才能手动设置该变量，此时会同时更新gtid_executed为和gtid_purged相同的值。gtid_executed为空意味着要么之前没有启动过基于GTID的复制，要么执行过RESET MASTER。执行RESET MASTER时同样也会把gtid_purged置空，即始终保持gtid_purged是gtid_executed的子集。

gtid_next

会话级变量，指示如何产生下一个GTID。可能的取值如下:

1）AUTOMATIC：

自动生成下一个GTID，实现上是分配一个当前实例上尚未执行过的序号最小的GTID。

2）ANONYMOUS：

设置后执行事务不会产生GTID。

3）显式指定的GTID：

可以指定任意形式合法的GTID值，但不能是当前gtid_executed中的已经包含的GTID，否则，下次执行事务时会报错。

这些变量可以通过show命令查看，比如：

如何产生GTID

GTID的生成受gtid_next控制。在Master上，gtid_next是默认的AUTOMATIC,即在每次事务提交时自动生成新的GTID。它从当前已执行的GTID集合（即gtid_executed）中，找一个大于0的未使用的最小值作为下个事务GTID。同时在binlog的实际的更新事务事件前面插入一条set gtid_next事件。

以下是一条insert语句生成的binlog记录：

在Slave上回放主库的binlog时，先执行set gtid_next ...，然后再执行真正的insert语句，确保在主和备上这条insert对应于相同的GTID。

一般情况下，GTID集合是连续的，但使用多线程复制(MTS)以及通过gtid_next进行人工干预时会导致gtid空洞。比如下面这样：

继续执行事务，MySQL会分配一个最小的未使用GTID，也就是从出现空洞的地方分配GTID，最终会把空洞填上。

这意味着严格来说我们即不能假设GTID集合是连续的，也不能假定GTID序号大的事务在GTID序号小的事务之后执行，事务的顺序应由事务记录在binlog中的先后顺序决定。

GTID的持久化

GTID相关的信息存储在binlog文件中，为此MySQL5.6新增了下面2个binlog事件。

Previous_gtids_log_event在每个binlog文件的开头部分，记录在该binlog文件之前已执行的GTID集合。

Gtid_log_event即前面看到的set gtid_next ...,它出现在每个事务的前面，表明下一个事务的gtid。

示例如下：

MySQL服务器启动时，通过读binlog文件，初始化gtid_executed和gtid_purged,使它们的值能和上次MySQL运行时一致。

gtid_executed被设置为最新的binlog文件中Previous_gtids_log_event和所有Gtid_log_event的并集。

gtid_purged为最老的binlog文件中Previous_gtids_log_event。

由于这两个重要的变量值记录在binlog中，所以开启gtid_mode时必须同时在主库上开启log_bin在备库上开启log_slave_updates。

但是，在MySQL5.7中没有这个。MySQL5.7中，新增加一个系统表mysql.gtid_executed用于持久化已执行的GTID集合。当主库上没有开启log_bin或在备库上没有开启log_slave_updates时，mysql.gtid_executed会跟用户事务一起每次更新。否则只在binlog日志发生rotation时更新mysql.gtid_executed。

如何配置基于GTID的复制

MySQL服务器的my.cnf配置文件中增加GTID相关的参数

log_bin= /mysql/binlog/mysql_bin

log_slave_updates= true

gtid_mode= ON

enforce_gtid_consistency= true

relay_log_info_repository = TABLE

relay_log_recovery= ON

然后在Slave上指定MASTER_AUTO_POSITION = 1执行CHANGE MASTER TO即可。比如：

CHANGE MASTER TO MASTER_HOST=‘node1‘,MASTER_USER=‘repl‘,MASTER_PASSWORD=‘repl‘,MASTER_AUTO_POSITION=1;

基于GTID的复制如何工作

在MASTER_AUTO_POSITION = 1的情况下，MySQL会使用COM_BINLOG_DUMP_GTID协议进行复制。过程如下：

备库发起复制连接时，将自己的已接受和已执行的gtids的并集(后面称为slave_gtid_executed)发送给主库。即下面的集合：

UNION(@@global.gtid_executed, Retrieved_gtid_set - last_received_GTID)

主库将自己的gtid_executed与slave_gtid_executed的差集的binlog发送给Slave。主库的binlog mp过程如下：

检查slave_gtid_executed是否是主库gtid_executed的子集，如否那么主备数据可能不一致，报错。

检查主库的purged_executed是否是slave_gtid_executed的子集，如否代表缺失备库需要的binlog,报错

从最后一个Binlog开始扫描，获取文件头部的PREVIOUS_GTIDS_LOG_EVENT，如果它是slave_gtid_executed的子集，则这是需要发送给Slave的第一个binlog文件，否则继续向前扫描。

从第3步找到的binlog文件的开头读取binlog记录，判断binlog记录是否已被包含在slave_gtid_executed中，如果已包含跳过不发送。

从上面的过程可知，在指定MASTER_AUTO_POSITION = 1时，Master发送哪些binlog记录给Slave，取决于Slave的gtid_executed和Retrieved_Gtid_Set以及Master的gtid_executed，和relay_log_info以及master_log_info中保存的复制位点没有关系。

如何修复复制错误

在基于GTID的复制拓扑中，要想修复Slave的SQL线程错误，过去的SQL_SLAVE_SKIP_COUNTER方式不再适用。需要通过设置gtid_next或gtid_purged完成，当然前提是已经确保主从数据一致，仅仅需要跳过复制错误让复制继续下去。比如下面的场景：

在从库上创建表tb1

mysql> set sql_log_bin=0;

Query OK, 0 rows affected (0.00 sec)

mysql> create table tb1(id int primary key,c1 int);

Query OK, 0 rows affected (1.06 sec)

mysql> set sql_log_bin=1;

Query OK, 0 rows affected (0.00 sec)

在主库上创建表tb1：

mysql> create table tb1(id int primary key,c1 int);

Query OK, 0 rows affected (1.06 sec)

由于从库上这个表已经存在，从库的复制SQL线程出错停止。

上面的输出可以知道，从库已经执行过的事务是‘e10c75be-5c1b-11e6-ab7c-000c296078ae:1-5‘,执行出错的事务是‘e10c75be-5c1b-11e6-ab7c-000c296078ae:6‘，当前主备的数据其实是一致的，可以通过设置gtid_next跳过这个出错的事务。

在从库上执行以下SQL：

mysql> set gtid_next=‘e10c75be-5c1b-11e6-ab7c-000c296078ae:6‘;

Query OK, 0 rows affected (0.00 sec)

mysql> begin;

Query OK, 0 rows affected (0.00 sec)

mysql> commit;

Query OK, 0 rows affected (0.00 sec)

mysql> set gtid_next=‘AUTOMATIC‘;

Query OK, 0 rows affected (0.00 sec)

mysql> start slave;

Query OK, 0 rows affected (0.02 sec)

设置gtid_next的方法一次只能跳过一个事务，要批量的跳过事务可以通过设置gtid_purged完成。假设下面的场景：

主库上已执行的事务

从库上已执行的事务

假设经过修复从库已经和主库的数据一致了，但由于复制错误Slave的SQL线程依然处于停止状态。现在可以通过把从库的gtid_purged设置为和主库的gtid_executed一样跳过不一致的GTID使复制继续下去，步骤如下。

在从库上执行

此时从库的Executed_Gtid_Set已经包含了主库上‘1-10‘的事务，再开启复制会从后面的事务开始执行，就不会出错了。

mysql> start slave;

Query OK, 0 rows affected (0.01 sec)

使用gtid_next和gtid_purged修复复制错误的前提是，跳过那些事务后仍可以确保主备数据一致。如果做不到，就要考虑pt-table-sync或者拉备份的方式了。

GTID与备份恢复

在做备份恢复的时候，有时需要恢复出来的MySQL实例可以作为Slave连上原来的主库继续复制，这就要求从备份恢复出来的MySQL实例拥有和数据一致的gtid_executed值。这也是通过设置gtid_purged实现的，下面看下mysqlmp做备份的例子。

1、通过mysqlmp进行备份

通过mysqlmp做一个全量备份：

[root@node1 ~]# mysqlmp --all-databases --single-transaction --routines --events --host=127.0.0.1 --port=3306 --user=root > mp.sql

生成的mp.sql文件里包含了设置gtid_purged的语句

SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN;

SET @@SESSION.SQL_LOG_BIN= 0;

...

SET @@GLOBAL.GTID_PURGED=‘e10c75be-5c1b-11e6-ab7c-000c296078ae:1-10‘;

...

SET @@SESSION.SQL_LOG_BIN = @MYSQLDUMP_TEMP_LOG_BIN;

恢复数据前需要先通过reset master清空gtid_executed变量

[root@node2 ~]# mysql -h127.1 -e ‘reset master‘

[root@node2 ~]# mysql -h127.1 <mp.sql

否则执行设置GTID_PURGED的SQL时会报下面的错误

ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.

此时恢复出的MySQL实例的GTID_EXECUTED和备份时点一致：

由于恢复出的MySQL实例已经被设置了正确的GTID_EXECUTED，以master_auto_postion = 1的方式CHANGE MASTER到原来的主节点即可开始复制。

CHANGE MASTER TO MASTER_HOST=‘node1‘, MASTER_USER=‘repl‘, MASTER_PASSWORD=‘repl‘, MASTER_AUTO_POSITION = 1

如果不希望备份文件中生成设置GTID_PURGED的SQL，可以给mysqlmp传入--set-gtid-purged=OFF关闭。

2、通过Xtrabackup进行备份

相比mysqlmp，Xtrabackup是效率更高并且被广泛使用的备份方式。使用Xtrabackup进行备份的举例如下。

通过Xtrabackup创一个全量备份（可以在Slave上创建备份，以避免对主库的性能冲击）

innobackupex --defaults-file=/etc/my.cnf --host=127.1 --user=root --password=mysql --no-timestamp --safe-slave-backup --slave-info /mysql/bak

应用日志

innobackupex --apply-log /mysql/bak

查看备份目录中的xtrabackup_binlog_info文件可以找到备份时已经执行过的gtids

[root@node2 ~]# cat /mysql/bak/xtrabackup_binlog_info

mysql_bin.000001191e10c75be-5c1b-11e6-ab7c-000c296078ae:1-10

由于备份时添加了”--slave-info”选项并且从Slave节点拉取的备份，所以会生成xtrabackup_slave_info文件，也可以从这个文件里查找建立复制的SQL语句。

[root@node2 ~]# cat /mysql/bak/xtrabackup_slave_info

SET GLOBAL gtid_purged=‘e10c75be-5c1b-11e6-ab7c-000c296078ae:1-10‘;

CHANGE MASTER TO MASTER_AUTO_POSITION=1

将备份文件传送到新的节点node3的/mysql/bak目录并恢复(如果直接把备份传输到数据目录了，这一步可以省略)。

[root@node3 ~]# innobackupex --defaults-file=/etc/my.cnf --copy-back /mysql/bak

启动MySQL。

[root@node3 ~]# mysqld --defaults-file=/home/mysql/etc/my.cnf --skip-slave-start &

如果是从Slave拉的备份，一定不能直接开启Slave复制，这时的gtid_executed是错误的。需要手动设置gtid_purged后再start slave

MASTER_HOST=‘node1‘,MASTER_USER=‘repl‘,MASTER_PASSWORD=‘repl‘,MASTER_AUTO_POSITION=1;

start slave;

GTID与MHA

MHA是被广泛使用MySQL HA组件，MHA 0.56以后支持基于GTID的复制。 MHA在failover时会自动判断是否是GTID based failover，需要满足下面3个条件即为GTID based failover

所有节点gtid_mode=1

所有节点Executed_Gtid_Set不为空

至少一个节点Auto_Position=1

和之前的基于binlog文件位置的复制相比，基于GTID复制下，MHA在故障切换时的变化主要如下：

基于binlog文件位置的复制

在Master宕机后会尝试从Master上拷贝binlog日志进行补偿

如果候选Master不拥有最新的relay log，会从拥有最新relay log的Slave上生成差异的binlog传送到候选Master并实施补偿

新Master的日志补偿完成后，同样采用应用差异binlog的方式将其它Slave和新Master同步后再change master到新Master

基于GTID的复制

如果候选Master不拥有最新的relay log，让候选Master连上拥有最新relay log的Salve进行补偿。

尝试从binlog server上拉取缺失的binlog并应用

新Master的数据同步到最新后，让其它的Slave连上新Master并等待数据完成同步。并且可以给masterha_master_switch传入--wait_until_gtid_in_sync=1参数使其不等其它Slave完成数据同步，以加快切换速度。

GTID模式下MHA不会尝试从旧Master上拷贝binlog日志进行补偿，所以在MySQL进程crash而OS仍然健康的情况下，应尽量不要做主备切换而是原地重启MySQL，除非有其

如何复制mysql数据库到另一台电脑上？

有两种办法。

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’

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

如下:

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

-p12142022

mysql数据库可以直接复制吗

如果从库上表 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：

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

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

注意事项：这里要用 mysqlmp --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。

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

mysql数据库可以直接复制吗

场景 1

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

修复步骤：

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

恢复到从库；

启动复制。

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

正确的修复步骤：

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

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

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

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

注意事项：这里要用 mysqlmp --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。

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

MySQL如何复制表中的一条记录并插入

1、打开navicat软件，打开要复制表的数据库，如下图所示：

2、点击上方的“工具->数据传输”，如下图所示：

3、进去之后，左边选择的是要复制的表的数据库，右边选择的将表复制到目标数据库，如下图所示：

4、打开左边数据库对象中的“表”，选择要复制哪几张表，点击开始。

5、点击开始，会弹出一个框，点击是，等待一下，出现如下界面，复制成功，点击“关闭”。

6、可以看到表已经复制到另外一个数据库上了，如下图所示：

mysql如何复制数据到同一张表？

在利用数据库开发时，常常会将一些表之间的数据互相导入。当然可以编写程序实现，但是，程序常常需要开发环境，不方便。最方便是利用sql语言直接导入。既方便而修改也简单。以下就是导入的方法。

1、表结构相同的表，且在同一数据库（如，table1,table2)

Sql ：

复制代码代码如下:

insert into table1 select * from table2 (完全复制)

insert into table1 select distinct * from table2(不复制重复纪录）

insert into table1 select top 5 * from table2 (前五条纪录)

2、不在同一数据库中（如，db1 table1,db2 table2)

sql:

[code]

insert into db1.table1 select * from db2.table2 (完全复制)

insert into db1.table1 select distinct * from db2table2(不复制重复纪录）

insert into tdb1.able1 select top 5 * from db2table2 (前五条纪录)

3、表结构不同的表或复制部分纪录（如，dn_user,dn_user2)

a. 建一个新表[DN_UserTemp]（在老表dn_user上增加一列)

复制代码代码如下:

CREATE TABLE [DN_UserTemp] ( [Num] [numeric](18, 0) IDENTITY (1, 1) NOT NULL）

[Id] [idtype] NOT NULL ,

[Name] [fntype] NOT NULL ,

[Descript] [dstype] NULL ,

[LogonNm] [idtype] NOT NULL ,

[Password] [idtype] NULL ,

[Gender] [char] (1) NULL ,

[Quited] [booltype] NOT NULL,

[OffDuty] [booltype] NOT NULL ,

[Stopped] [booltype] NOT NULL,

[OSBind] [booltype] NOT NULL,

[Domain] [idtype] NULL ,

[EMail] [fntype] NULL ,

[UnitId] [idtype] NULL ,

[BranchId] [idtype] NULL ,

[DutyId] [idtype] NULL ,

[LevelId] [idtype] NULL ,

[ClassId] [idtype] NULL ,

[TypeId] [idtype] NULL ,

[IP] [varchar] (15) COLLATE Chinese_PRC_CI_AS NULL ,

[ExpireDT] [datetime] NULL ,

[Sort] [int] NOT NULL ,

[AllowDel] [booltype] NOT NULL,

[UnitChief] [booltype] NOT NULL,

[BranchChief] [booltype] NOT NULL ,

[UnitDeputy] [booltype] NOT NULL ,

[BranchDeputy] [booltype] NOT NULL ,

[Num] [numeric](18, 0) IDENTITY (1, 1) NOT NULL

) ON [PRIMARY]

b. 将dn_uer2的数据拷入dn_usertemp

sql:insert into dn_usertemp select * from dn_user2

c.将dn_usertemp 拷入dn_user

sql:

复制代码代码如下:

declare @i int

declare @j int

declare @Name fntype

set @i=1

select @j=count(*) from dn_usertemp

while @i<@j 1

begin

select @Name=Name from dn_usertemp where Num=@i

print @Name

insert into dn_user (Name) values (@Name) where Num=@i

select @i=@i 1

end

MySql数据库复制表数据

将 proction 数据库中的 mytbl 表快速复制为 mytbl_new,2个命令如下：

复制代码代码如下:

CREATE TABLE mytbl_new LIKE proction.mytbl;

INSERT mytbl_new SELECT * FROM proction.mytbl;

第一个命令是创建新的数据表 mytbl_new ,并复制 mytbl 的数据表结构。

第二个命令是讲数据表 mytbl 中的数据复制到新表 mytbl_new 。

注：proction.mytbl是指定要复制表的数据库名称为 proction 。它是可选的。

假如没有proction. ,MySQL数据库将会假设mytbl在当前操作的数据库。

另外：在mysql数据库中复制数据为：

复制代码代码如下:

select * into desTable from sourceTable在mssql中支持，在mysql中不支持

insert into desTable select * from sourceTable

显示全文

全部栏目

MYSQL 基于GTID的复制