【MySQL篇】Percona XtraBackup物理备份工具的基础理论概述（第一篇，总共五篇）

💫《博主介绍》：✨又是一天没白过，我是奈斯，DBA一名✨

💫《擅长领域》：✌️擅长Oracle、MySQL、SQLserver、阿里云AnalyticDB for MySQL(分布式数据仓库)、Linux，也在扩展大数据方向的知识面✌️

💖💖💖大佬们都喜欢静静的看文章，并且也会默默的点赞收藏加关注💖💖💖

哈喽各位小伙伴们，从这篇文章开始回归MySQL数据库，如标题所示，让我们一起探索一款备受赞誉的 100%开源的物理备份工具——Percona XtraBackup 。在MySQL的开源社区版本中，虽然提供了mysqldump和mysqlpump这样的逻辑备份工具，但对于处理超大数据量的MySQL数据库来说，这些逻辑备份工具往往显得力不从心，备份速度缓慢，甚至可能出现卡顿现象。在这种情况下，物理备份工具就显得尤为重要。

其实在MySQL社区版8.0.17引入了clone插件这一物理克隆数据工具，允许在本地或从远程MySQL服务器实例中克隆数据（传输数据），对于clone插件可以用来备份实例、数据目录迁移、搭建MGR、搭建主从复制等操作，所以说通过对于clone制定脚本也是可以实现备份实例的，但是clone是8.0.17版本之后才引入的，所以对于之前的版本就只能使用逻辑备份工具，那么就需要一款物理备份工具解决8.0.17版本之前超大数据量的MySQL实例的备份问题。而在其企业版中虽然存在MySQL Enterprise Backup（MEB）这一强大的物理备份解决方案，但其高昂的费用却令许多用户望而却步。幸运的是，Percona公司为我们带来了一个完美的替代方案——Percona XtraBackup。

Percona XtraBackup不仅在功能和稳定性上可以与官方的MySQL Enterprise Backup相媲美，更在兼容性上紧跟MySQL社区版本的更新步伐，确保及时支持最新的MySQL社区版本。因此，无论是对于追求性能的大型数据库，还是对于预算有限的用户来说，Percona XtraBackup都是一个值得深入了解和使用的物理备份工具。在接下来的文章中，我们将详细展开介绍Percona XtraBackup的各项功能和特点，帮助大家更好地掌握这一强大的物理备份工具。

用一篇文章是不能将Percona XtraBackup工具讲明白的，所以我将理论、命令、备份策略、异机恢复、使用场景等分成五篇去介绍，即使分为五篇也有部分内容没有涵盖到，所以这五篇文章都是精华，学会了之后就可以完全应对在平时使用Percona XtraBackup工具的相关工作内容了，五篇文章的内容分别如下：

第一篇：Percona XtraBackup物理备份工具的基础理论概述（当前篇）
第二篇：Percona XtraBackup工具备份指南：常用备份命令详解与实践
第三篇：Percona XtraBackup标准化全库完整备份策略
第四篇：Percona XtraBackup异机恢复：基于全库恢复 or 基于时间点恢复
第五篇：物理克隆数据clone插件、逻辑备份工具mysqldump/mysqlpump和物理备份Percona XtraBackup三种工具的区别和各自的使用场景总汇

在开始讲解Percona XtraBackup(PXB)之前先回顾一下物理克隆数据clone插件，对比一下clone Plugin与XtraBackup：

(1)在实现上，两者都有FILE COPY和REDO COPY阶段，但Clone Plugin比XtraBackup多了一个PAGE COPY，由此带来的好处是，Clone Plugin的恢复速度比XtraBackup更快。

(2)XtraBackup没有Redo Archiving特性，有可能出现未拷贝的Redo日志被覆盖的情况。

(3)GTID下建立复制，无需额外执行set global gtid_purged操作。

对物理克隆数据clone插件有兴趣的小伙伴可以参考我之前的文章哦，Clone技术涉及到理论介绍、本地克隆方式介绍、远程克隆方式介绍，所以都整理到一篇中着实会感觉到阅读疲劳，所以我将分为三篇文章介绍，三篇文章分别如下：

MySQL篇—自带物理克隆数据工具Clone插件介绍（第一篇，总共三篇）_mysql clone-CSDN博客

MySQL篇—通过Clone插件进行本地克隆数据（第二篇，总共三篇）_插件clone-CSDN博客

MySQL篇—通过Clone插件进行远程克隆数据（第三篇，总共三篇）_mysql clone-CSDN博客

那么下面开始步入今天的正题！！！

PXB介绍：

PXB特点和优势：

PXB缺点：

PXB版本发展：

PXB官方文档介绍：

PXB官方下载地址：

PXB备份后目录里面相关文件介绍：

PXB深入解析和备份原理：

一、备份流程：

二、恢复流程（2个阶段，先数据一致性，再restore）

PXB介绍：

Percona XtraBackup是一个开源的热备份实用程序，适用于基于MySQL的服务器，可以在计划的维护窗口中保持数据库的完全可用性。

无论是全天候高负载服务器还是低事务量服务器，Percona XtraBackup都旨在实现无缝备份，而不会中断服务器在生产环境中的性能。Percona XtraBackup（PXB）是一个100%的开源备份解决方案，为那些希望从MySQL的全面、响应迅速和成本灵活的数据库支持中获益的组织提供商业支持。

PXB支持对InnoDB做热备，支持部分备份、完全备份、增量备份、差异备份（注：percona还发布过innobackup收费版，之后被mysql收购）

PXB特点和优势：

特点：

1）速度快，文件copy。

2）备份粒度小。

3）支持备份日志和参数文件。

4）最适合大数据量的备份

5）备份为二进制文件，不可编辑，数据库的一个副本（mysql的逻辑备份是sql文件，可编辑）

优势：

1）支持官方mysql、percona、mariaDB

2）备份速度快，支持并行、支持压缩、支持加密、支持自动实例备份检验、恢复速度快、支持在线迁移表

3）执行在线热备份整个库的InnoDB、XtraDB表。不会影响正在执行的事务，不锁表，不会产生性能问题（innodb支持，非innodb不支持）

4）可在上一次整库备份基础上做增量备份(innodb only)

5）以流的形式产生备份，可以直接保存到远程机器上，节约磁盘空间

6）备份时不会增大服务器负载，快速完成备份鉴定，并能迅速恢复备份数据，从而提高在线时间

PXB缺点：

1）不支持脱机备份（mysql关闭情况下）

2）不支持直接备份到磁带设备

3）不支持云备份

4）如果备份myisam，还存在阻塞（加锁），innodb支持在线备份（热备DDL、DML）

5）缺点是在增量备份的时候，作为备份基础的全备文件不能压缩，否则备份失效；增量的时候，表结构变更的话，变更部分备份无效。

PXB版本发展：

PXB目前最新分为多个版本，包括2.4版本、8.0版本、8.1、8.2、8.3版本。每个版本对应支持不同的MySQL版本。

percona xtrabackup版本	MySQL版本支持
2.4	支持MySQL5.5、5.6和5.7版本
8.0	支持MySQL 8.0版本
8.1	支持MySQL 8.1版本
8.2	支持MySQL 8.2版本
8.3	支持MySQL 8.3版本
需要注意：PXB版本和MySQL版本有严格的对应关系，不同的PXB版本只能备份对应的MySQL版本。比如：在MySQL5.7中，只能使用2.4版本，不能使用8.0版本备份（MySQL5.7使用8.0版本报：Please use Percona XtraBackup 2.4 for this database）在MySQL8.0中，只能使用8.0版本，不能使用2.4版本备份（MySQL8.0使用2.4版本报：Please use Percona Xtrabackup 8.0.x for backups and restores）

在xtrabackup 2.4产品中，包括了2个命令innobackupex，xtrabackup。xtrabackup命令主要备份innodb和xtraDB两种表。innobackupex命令则封闭了xtrabackup，同时可以备份myisam数据表。也就是说xtrabackup命令整合了innobackupex命令全部的功能，支持了非innodb表，再早期的版本都是使用innobackupex命令备份，如果有innodb表，它会自动调用xtrabackup脚本来备份innodb表；使用xtrabackup也会调用innobackupex备份非innodb表。如下是2.4版本中的命令：

从2.4版本之后innobackupex功能全部集成到xtrabackup命令里面，innobackupex作为xtrabackup的一个软链接（不是linux层面的软连接哦），并且MySQL对内容进行了处理，敲2个命令会出现不同的参数。在8.0之后命令innobackupex取消，所有功能整合到xtrabackup命令中。如下8.0版本中的命令：

PXB官方文档介绍：

PXB2.4版本：Percona XtraBackup

PXB8.0版本：Percona XtraBackup

PXB8.3版本：Percona XtraBackup

PXB官方下载地址：

通过链接可以一键下载不同的PXB版本，省时又省力，下载超链接👉Software Downloads - Percona👈

PXB备份后目录里面相关文件介绍：

除了备份所有的存储引擎类型表外，还会生成其他记录文件。

1）backup-my.cnf：备份命令用到的配置选项信息

2）xtrabackup_binlog_info：记录当前备份时写入的二进制文件和position点和gtid点信息

3）xtrabackup_checkpoints：存放备份的起始位置begin lsn和结束位置的end lsn，增量备份需要这个lsn。各个字段说明：

  backup_type = 备份类型

from_lsn = 备份开始的lsn

to_lsn = checkpoint的lsn

last_lsn = 备份结束的lsn，也就是数据刷盘的lsn

compact = 是否压缩。0表示没有

recover_binlog_info = 需要恢复的二进制信息。0表示没有

4）xtrabackup_info：备份的一些信息。各个字段说明：

uuid = uuid信息

name =

tool_name = 工具名称

tool_command = 备份命令

tool_version = 工具版本

ibbackup_version =

server_version = 数据库版本

start_time = 备份开始时间

end_time = 备份结束时间

lock_time = 加锁时间

binlog_pos = 记录当前备份时写入的二进制文件和position点信息

innodb_from_lsn = 备份开始的lsn

innodb_to_lsn = checkpoint的lsn

partial = 是否增量备份。N表示就是全备

incremental =

format = 文件格式，一般是file

  compact = 是否打包

  compressed = 是否压缩

encrypted = 是否加密

5）xtrabackup_logfile：备份的重做日志文件

PXB深入解析和备份原理：

xtrabackup以rw读写模式打开innodb的数据文件，用内置的innodb库来打开文件。xtrabackup每次读写1M的数据，就是64个页（一个页大小16K）。读写redo是每次512k

一、备份流程：

第一步：start xtrabackup_log：

运行innobackupex命令会开启xtrabackup_log监控线程，实时检测redo log文件的变化，将新备份过程中新写入到事务日志中的日志拷贝到innobackup_log（start xtrabackup_log）中，同时开启xtrabackup拷贝线程，开始拷贝innodb文件

第二步：增量备份（只有进行增量的时候才进行的步骤，不进行增量备份忽略此步骤）

对比自上次innodb备份（只对比innodb表，非innodb表不对比，因为xtrabackup支持对innodb进行一致性检验，非innodb不能进行一致性检验）后变化的数据页，当lsn>xtrabackup_check points中的lsn进行增量备份

第二步：copy innodb file

拷贝innodb相关文件（.ibd、.frm、ibdata、undo）

第三步：flush tables witch read lock;

在拷贝innodb文件结束后进行，对非innodb文件加锁，innodb的不受影响

第四步：copy 非innodb file

拷贝非innodb相关文件（MYD、MYI、frm）



第五步：unlock tables解锁表



第六步：记录当前的binlog log position



第七步：停止xtrabackup_log监控线程

总结：

对全备文件进行xtrabackup_log日志回放，并对提交的事务进行重做（apply redo log recored），同时回滚未提交的事务（undo space）。这个过程叫prepare预准备阶段（类似于oracle的recover过程，但是不追二进制）[prepare过程中，恢复备份集的日志，会启动一个mysqld的服务进程，来做恢复实现一致性，但是只针对innodb表有些，非innodb表是不能进行一致性恢复，在恢复的时候是恢复所有的，只是一致性非innodb不能实现]。

ps注意：oracle的物理工具rman恢复是先restore还原然后再recover恢复，在recover时到达数据一致性；而mysql的物理工具xtrabackup恢复是先对数据进行一致性，然后再还原。mysql和oracle的物理工具柜恢复是相反的。oracle先restore还原，再recover一致性；xtrabackup先prepare recover一致性，再restore还原。



备份日志解析
210601 15:48:13 innobackupex: Starting the backup operation         ###开始备份操作
IMPORTANT: Please check that the backup run completes successfully.         
           At the end of a successful backup run innobackupex
           prints "completed OK!".                                  ###检查备份状态是否OK
.....
xtrabackup: cd to /var/lib/mysql                                    ###进到数据目录，由参数datadir控制
xtrabackup: open files limit requested 0, set to 1024               ###由/etc/security/limits.conf文件的 nofile 参数控制。看出最大打开1024个文件，那么太小会报错
xtrabackup: using the following InnoDB configuration:
xtrabackup:   innodb_data_home_dir = .
xtrabackup:   innodb_data_file_path = ibdata1:76M;ibdata2:12M:autoextend
xtrabackup:   innodb_log_group_home_dir = ./                          ###读取innodb配置的参数
xtrabackup:   innodb_log_files_in_group = 2
xtrabackup:   innodb_log_file_size = 50331648
InnoDB: Number of pools: 1
210601 15:48:13 >> log scanned up to (552639295)                      ###innodb日志序列号
xtrabackup: Starting x threads for parallel data files transfer       ###xtrabackup启动x个线程进行并行数据文件传输（和在备份时指定的parallel参数的值有关）
210912 21:05:07 [02] Copying ./ibdata1 to /mysql/app/2021-09-12_21-05-06/ibdata1
210912 21:05:07 [01] Copying ./ibdata2 to /mysql/app/2021-09-12_21-05-06/ibdata2
210912 21:05:07 [02]        ...done
210912 21:05:07 >> log scanned up to (2688357)
210912 21:05:08 [01] Copying .//undo001 to /mysql/app/2021-09-12_21-05-06/undo001
210912 21:05:08 [01]        ...done
210912 21:05:08 >> log scanned up to (2688357)
210912 21:05:08 [01]        ...done                                      ###拷贝innodb物理文件
.....................
210912 21:05:09 [02] Copying ./itpuxdb1/itpuxtb1.ibd to /mysql/app/2021-09-12_21-05-06/itpuxdb1/itpuxtb1.ibd
210912 21:05:09 [02]        ...done
210912 21:05:09 [01] Copying ./itpuxdb1/itpuxtb2.ibd to /mysql/app/2021-09-12_21-05-06/itpuxdb1/itpuxtb2.ibd
210912 21:05:09 [01]        ...done
210912 21:05:09 >> log scanned up to (2688357)
210601 15:48:18 Executing FLUSH NO_WRITE_TO_BINLOG TABLES...  
210601 15:48:18 Executing FLUSH TABLES WITH READ LOCK...                 ###对非innodb文件进行加锁备份，在innodb文件拷贝完成之后进行（备份myisam，还存在加锁）
210601 15:48:18 Starting to backup non-InnoDB tables and files           ###开始备份非innodb文件
210601 15:48:18 [01] Copying ./mysql/db.opt to /mysql/app/2021-06-01_15-48-13/mysql/db.opt
210601 15:48:18 [01]        ...done
210601 15:48:18 [01] Copying ./mysql/db.frm to /mysql/app/2021-06-01_15-48-13/mysql/db.frm
210601 15:48:18 [01]        ...done                                                  ###拷贝非innodb物理文件
210601 15:48:18 [01] Copying ./mysql/db.MYI to /mysql/app/2021-06-01_15-48-13/mysql/db.MYI
210601 15:48:18 [01]        ...done
210601 15:48:18 [01] Copying ./mysql/db.MYD to /mysql/app/2021-06-01_15-48-13/mysql/db.MYD
...................
210601 15:48:19 Finished backing up non-InnoDB tables and file                         ###结束备份非innodb文件
210912 21:05:11 [00] Writing /mysql/app/2021-09-12_21-05-06/xtrabackup_binlog_info     ###记录记录当前备份时写入的二进制文件和position点和gtid点信息
210912 21:05:11 [00]        ...done
210601 15:48:19 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
xtrabackup: The latest check point (for incremental): '552639286'
xtrabackup: Stopping log copying thread.
.210601 15:48:19 >> log scanned up to (552639295)
210601 15:48:19 Executing UNLOCK TABLES                                                        ###解锁非innodb文件
210601 15:48:19 [00] Copying ib_buffer_pool to /mysql/app/2021-06-01_15-48-13/ib_buffer_pool   ###拷贝ib_buffer_pool预热文件
210601 15:48:19 [00]        ...done
210601 15:48:19 Backup created in directory '/mysql/app/2021-06-01_15-48-13/'         ###生成时间戳文件夹，格式：yyyy-mm-dd_h24-mi-ss
MySQL binlog position: filename 'itpuxdb-binlog.000018', position '154'               ###记录当前写入的二进制文件和position点信息
210601 15:48:19 [00] Writing /mysql/app/2021-06-01_15-48-13/backup-my.cnf
210601 15:48:19 [00]        ...done
210601 15:48:19 [00] Writing /mysql/app/2021-06-01_15-48-13/xtrabackup_info
210601 15:48:19 [00]        ...done
xtrabackup: Transaction log of lsn (552639286) to (552639295) was copied.
210601 15:48:20 completed OK!

二、恢复流程（2个阶段，先数据一致性，再restore）

第一步：对未提交的事务进行回滚

第二步：对数据文件进行apply_log

第三步：将备份文件拷贝到mysql data目录下

总结：

对全备文件进行xtrabackup_log日志回放，并对提交的事务进行重做（apply redo log recored），同时回滚未提交的事务（undo space）。这个过程叫prepare预准备阶段（类似于oracle的recover过程，但是不追二进制）[prepare过程中，恢复备份集的日志，会启动一个mysqld的服务进程，来做恢复实现一致性，但是只针对innodb表有些，非innodb表是不能进行一致性恢复，在恢复的时候是恢复所有的，只是一致性非innodb不能实现]。

ps注意：oracle的物理工具rman恢复是先restore还原然后再recover恢复，在recover时到达数据一致性；而mysql的物理工具xtrabackup恢复是先对数据进行一致性，然后再还原。mysql和oracle的物理工具柜恢复是相反的。oracle先restore还原，再recover一致性；xtrabackup先prepare recover一致性，再restore还原。

恢复日志解析1（先进行prepare recover数据一致性，不进行拷贝）

xtrabackup: cd to /mysql/app/2021-06-29_12-05-20/
xtrabackup: This target seems to be not prepared yet.
InnoDB: Number of pools: 1
xtrabackup: xtrabackup_logfile detected: size=8388608, start_lsn=(8584146007)
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup:   innodb_data_home_dir = .
xtrabackup:   innodb_data_file_path = ibdata1:200M;ibdata2:200M;ibdata3:200M:autoextend:max:5G
xtrabackup:   innodb_log_group_home_dir = .
xtrabackup:   innodb_log_files_in_group = 1                    ###读取备份时生成的backup-my.cnf、xtrabackup_info、xtrabackup_checkpoints文件
xtrabackup:   innodb_log_file_size = 8388608                   
xtrabackup: using the following InnoDB configuration for recovery:   
xtrabackup:   innodb_data_home_dir = .
xtrabackup:   innodb_data_file_path = ibdata1:200M;ibdata2:200M;ibdata3:200M:autoextend:max:5G
xtrabackup:   innodb_log_group_home_dir = .
xtrabackup:   innodb_log_files_in_group = 1
xtrabackup:   innodb_log_file_size = 8388608
xtrabackup: Starting InnoDB instance for recovery.             ###启动innodb数据一致性效验，进行的就是recover 
.........
InnoDB: xtrabackup: Last MySQL binlog file position 1166, file name itpuxdb-binlog.000006     ###效验到二进制000006文件，1166position点
.........
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...             ###再次关闭数据库，进行第二次效验
.........
InnoDB: Setting log file ./ib_logfile101 size to 200 MB
InnoDB: Progress in MB:
 100 200
InnoDB: Setting log file ./ib_logfile1 size to 200 MB
InnoDB: Progress in MB:
 100 200
InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0
InnoDB: New log files created, LSN=8584146480
InnoDB: Opened 3 undo tablespaces
InnoDB: 3 undo tablespaces made active
InnoDB: Highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 8584146956
InnoDB: Doing recovery: scanned up to log sequence number 8584146965 (0%)
InnoDB: Database was not shutdown normally!                      ###生成临时表空间、重做日志文件（备份是不进行的），recover时再进行恢复
InnoDB: Starting crash recovery.                                  
InnoDB: xtrabackup: Last MySQL binlog file position 1166, file name itpuxdb-binlog.000006
InnoDB: Removed temporary tablespace data file: "ibtmp1"
InnoDB: Creating shared tablespace for temporary tables
InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
InnoDB: File './ibtmp1' size is now 12 MB.
InnoDB: 96 redo rollback segment(s) found. 1 redo rollback segment(s) are active.
InnoDB: 32 non-redo rollback segment(s) are active.
InnoDB: 5.7.34 started; log sequence number 8584146965
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 8584146984
210629 12:46:26 completed OK!

恢复日志解析2（进行restore还原，将文件copy）

IMPORTANT: Please check that the copy-back run completes successfully.   ###开始恢复操作（copy备份）
           At the end of a successful copy-back run innobackupex
           prints "completed OK!".                                   ###检查恢复状态是否OK
210629 13:52:07 [01] Copying undo001 to /mysql/data/3306/data1/undo001
210629 13:52:08 [01]        ...done
210629 13:52:08 [01] Copying undo002 to /mysql/data/3306/data1/undo002
210629 13:52:11 [01]        ...done
210629 13:52:11 [01] Copying undo003 to /mysql/data/3306/data1/undo003
210629 13:52:17 [01]        ...done
210629 13:52:17 [01] Copying ib_logfile0 to /mysql/data/3306/data1/ib_logfile0
210629 13:52:22 [01]        ...done                                      ###拷贝undo、重做日志、共享表空间
210629 13:52:22 [01] Copying ib_logfile1 to /mysql/data/3306/data1/ib_logfile1
210629 13:52:27 [01]        ...done
210629 13:52:27 [01] Copying ibdata1 to /mysql/data/3306/data1/ibdata1
210629 13:52:32 [01]        ...done
210629 13:52:33 [01] Copying ibdata2 to /mysql/data/3306/data1/ibdata2
210629 13:52:37 [01]        ...done
210629 13:52:38 [01] Copying ibdata3 to /mysql/data/3306/data1/ibdata3
210629 13:52:42 [01]        ...done
xtrabackup: Starting x threads for parallel data files transfer         ###xtrabackup启动x个线程进行并行数据文件传输（和在备份时指定的parallel参数的值有关）
.........
210629 13:52:42 [02] Copying ./ib_buffer_pool to /mysql/data/3306/data1/ib_buffer_pool
210629 13:52:42 [01] Copying ./itpuxdb1/itpuxzfj1.frm to /mysql/data/3306/data1/itpuxdb1/itpuxzfj1.frm
210629 13:52:42 [02]        ...done
210629 13:52:42 [01]        ...done
210629 13:52:42 [02] Copying ./itpuxdb1/db.opt to /mysql/data/3306/data1/itpuxdb1/db.opt     ###恢复ib_buffer_pool预热文件和其他表
210629 13:52:42 [02]        ...done                                        
210629 13:52:42 [01] Copying ./itpuxdb1/itpuxzfj1.ibd to /mysql/data/3306/data1/itpuxdb1/itpuxzfj1.ibd
210629 13:52:42 [01]        ...done
210629 13:52:42 [02] Copying ./xtrabackup_master_key_id to /mysql/data/3306/data1/xtrabackup_master_key
210629 13:55:39 completed OK!

呼！终于肝完了，博主从构思到排版花了2天时间，其实在写博客同时自己也相当于回顾了一遍，并且将相关知识点归纳的更加整洁了。对于理论部分而言大部分都是枯燥的，然而理论掌握的越深解决问题的速度就越快，所以各位小伙伴们，一定一定要把这篇Percona XtraBackup物理备份工具的基础理论学习透彻哦！！最后还要再说一句，三连一下，快乐加倍💓