mysql主从同步产生的 Error_code = 1062 或 1032问题

本文记录了一次MySQL主从同步过程中遇到的1062和1032错误的处理过程,包括错误产生的原因及解决方案。

mysql主从同步导致1062和1032问题

事情起因

不知道为什么mysql的数据库所在磁盘空间满了。导致主从出现数据不一致。可是我并不知道是空间满了引起的,各种办法使用了,mysql却停不了。登陆mysql也没办执行命令。然后就

```
    kill -9 mysql's pid
```

结果就悲剧了。mysql的主从被破坏。(这个是时候才想起来看一下磁盘空间问题,已经晚了)想了很多方式,还是没办法解决。最后决定重新做一下从库。进入主题。


==友情提示:千万不要 kill -9 谁用谁知道==


下面是我操作的具体步骤

  1. 拉取主库的备份文件。恢复从库数据。
  2. 设置从库的binlog日志和pos点。
  3. 启动重复,开启复制。

悲剧开始

  1. 主从出现问题,输入:show slave status \G; 这个时候出现了Error_code: 1062的错误。附上当时的主从的状态和错误日志。

    Slave_IO_Running: Yes
    Slave_SQL_Running: No
    2016-06-09 00:07:07 23352 [ERROR] Error reading packet from server: Lost connection to MySQL server during query ( server_errno=2013)
    2016-06-09 00:07:07 23352 [Note] Slave I/O thread killed while reading event
    2016-06-09 00:07:07 23352 [Note] Slave I/O thread exiting, read up to log 'mysql-bin-190.000667', position 9049889
    2016-06-09 00:07:07 23352 [Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.
    2016-06-09 00:07:07 23352 [Warning] Slave SQL: If a crash happens this configuration does not guarantee that the relay log info will be consistent, Error_code: 0
    2016-06-09 00:07:07 23352 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin-190.000666' at position 2935199, relay log './mysql3306-relay-bin.000002' position: 2935366
    2016-06-09 00:07:07 23352 [Note] 'SQL_SLAVE_SKIP_COUNTER=1' executed at relay_log_file='./mysql3306-relay-bin.000002', relay_log_pos='2935366', master_log_name='mysql-bin-190.000666', master_log_pos='2935199' and new position at relay_log_file='./mysql3306-relay-bin.000002', relay_log_pos='2935750', master_log_name='mysql-bin-190.000666', master_log_pos='2935583' 
    2016-06-09 00:07:07 23352 [Note] Slave I/O thread: connected to master 'sync@10.251.192.108:3306',replication started in log 'mysql-bin-190.000667' at position 9049889
    2016-06-09 00:07:08 23352 [ERROR] Slave SQL: Could not execute Write_rows event on table asy.pm_camera_recordrate; Duplicate entry '913df478e36f4f888505874ddec59240' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin-190.000666, end_log_pos 2944382, Error_code: 1062
    2016-06-09 00:07:08 23352 [Warning] Slave: Duplicate entry '913df478e36f4f888505874ddec59240' for key 'PRIMARY' Error_code: 1062

    解决方式:在my.cnf文件中加入如下代码到[mysqld]。重启mysql

    slave-skip-errors = 1062
  2. 执行完第一步。由于数据问题,又出现了。Error_code: 1032错误。

解决方式:在my.cnf文件中加入如下代码到[mysqld]。重启mysql

```
slave-skip-errors = 1062,1032
```

如果能预估到错误数据比较少。也可以用如下代码。每次执行只跳过一个事务。

```
stop slave;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1 ;
start slave ;
```

可能出现的问题

跳过1062和1032错误 。可能会导致日志中出现警告信息。所以在在my.cnf文件中加入如下代码到[mysqld]。重启mysql可解决问题。

```
binlog_format=mixed
```

反思问题起因

  1. 在从库由于使用了 kill -9 杀掉了mysql线程。可能导致了mysql的事务回滚。也有可能导致了mysql中继日志出现问题。
  2. 在拉取备份文件恢复的时候。由于拉取了最新的备份数据。恢复数据的时候。只是重设了同步的binlog文件和pos点。并没有修改中继日志的起点。导致了中继日志中的数据应该是比数据库中的备份点数据更早了。然后产生了1062主键冲突和1032删除数据不存在的错误。

以上类容纯属猜想,并未真正验证,如有理解错误,欢迎大家指正,谢谢!

[mysql@gaussdb12 log]$ mysqlbinlog --base64-output=decode-rows -v mysql-bin.000009 --start-position=1377 > mysql-bin.000009.log [mysql@gaussdb12 log]$ [mysql@gaussdb12 log]$ more mysql-bin.000009.log /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/; /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/; DELIMITER /*!*/; # at 1377 #200122 10:10:43 server id 330602 end_log_pos 1442 CRC32 0x9bde31e6 GTID last_committed=3 sequence_number=4 rbr_only=no SET @@SESSION.GTID_NEXT= '9c0f0bd7-3b52-11ea-b2f5-000c291e2519:32'/*!*/; # at 1442 #200122 10:10:43 server id 330602 end_log_pos 1565 CRC32 0x07275b09 Query thread_id=6 exec_time=0 error_code=0 use `dbtest1`/*!*/; SET TIMESTAMP=1579659043/*!*/; SET @@session.pseudo_thread_id=6/*!*/; SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/; SET @@session.sql_mode=1436549120/*!*/; SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/; /*!\C utf8 *//*!*/; SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/; SET @@session.lc_time_names=0/*!*/; SET @@session.collation_database=DEFAULT/*!*/; DROP TABLE `tab2` /* generated by server */ /*!*/; # at 1565 #200122 10:10:47 server id 330602 end_log_pos 1630 CRC32 0x5b73e3dd GTID last_committed=4 sequence_number=5 rbr_only=no SET @@SESSION.GTID_NEXT= '9c0f0bd7-3b52-11ea-b2f5-000c291e2519:33'/*!*/; # at 1630 #200122 10:10:47 server id 330602 end_log_pos 1753 CRC32 0xadd86b23 Query thread_id=6 exec_time=0 error_code=0 SET TIMESTAMP=1579659047/*!*/; DROP TABLE `tab3` /* generated by server */ /*!*/; # at 1753 #200122 10:10:52 server id 330602 end_log_pos 1818 CRC32 0x639aca9b GTID last_committed=5 sequence_number=6 rbr_only=no SET @@SESSION.GTID_NEXT= '9c0f0bd7-3b52-11ea-b2f5-000c291e2519:34'/*!*/; # at 1818 #200122 10:10:52 server id 330602 end_log_pos 1941 CRC32 0x41816cc3 Query thread_id=6 exec_time=0 error_code=0 --More--(0%) [1]+ Stopped more mysql-bin.000009.log [mysql@gaussdb12 log]$ more mysql-bin.000009.log /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/; /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/; DELIMITER /*!*/; # at 1377 #200122 10:10:43 server id 330602 end_log_pos 1442 CRC32 0x9bde31e6 GTID last_committed=3 sequence_number=4 rbr_only=no SET @@SESSION.GTID_NEXT= '9c0f0bd7-3b52-11ea-b2f5-000c291e2519:32'/*!*/; # at 1442 #200122 10:10:43 server id 330602 end_log_pos 1565 CRC32 0x07275b09 Query thread_id=6 exec_time=0 error_code=0 use `dbtest1`/*!*/; SET TIMESTAMP=1579659043/*!*/; SET @@session.pseudo_thread_id=6/*!*/; SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/; SET @@session.sql_mode=1436549120/*!*/; SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/; /*!\C utf8 *//*!*/; SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/; SET @@session.lc_time_names=0/*!*/; SET @@session.collation_database=DEFAULT/*!*/; DROP TABLE `tab2` /* generated by server */ /*!*/; # at 1565 #200122 10:10:47 server id 330602 end_log_pos 1630 CRC32 0x5b73e3dd GTID last_committed=4 sequence_number=5 rbr_only=no SET @@SESSION.GTID_NEXT= '9c0f0bd7-3b52-11ea-b2f5-000c291e2519:33'/*!*/; # at 1630 #200122 10:10:47 server id 330602 end_log_pos 1753 CRC32 0xadd86b23 Query thread_id=6 exec_time=0 error_code=0 SET TIMESTAMP=1579659047/*!*/; DROP TABLE `tab3` /* generated by server */ /*!*/; # at 1753 #200122 10:10:52 server id 330602 end_log_pos 1818 CRC32 0x639aca9b GTID last_committed=5 sequence_number=6 rbr_only=no SET @@SESSION.GTID_NEXT= '9c0f0bd7-3b52-11ea-b2f5-000c291e2519:34'/*!*/; # at 1818 #200122 10:10:52 server id 330602 end_log_pos 1941 CRC32 0x41816cc3 Query thread_id=6 exec_time=0 error_code=0 SET TIMESTAMP=1579659052/*!*/; DROP TABLE `tab4` /* generated by server */ /*!*/; # at 1941 #200122 10:41:51 server id 330602 end_log_pos 2006 CRC32 0x4892fb28 GTID last_committed=6 sequence_number=7 rbr_only=no SET @@SESSION.GTID_NEXT= '9c0f0bd7-3b52-11ea-b2f5-000c291e2519:35'/*!*/; # at 2006 #200122 10:41:51 server id 330602 end_log_pos 3158 CRC32 0x9bde3958 Query thread_id=6 exec_time=1 error_code=0 use `dbtest2`/*!*/; SET TIMESTAMP=1579660911/*!*/; CREATE TABLE `tab3` ( `ID` int(11) NOT NULL AUTO_INCREMENT, `TABLE_CATALOG` varchar(512) NOT NULL DEFAULT '', `TABLE_SCHEMA` varchar(64) NOT NULL DEFAULT '', `TABLE_NAME` varchar(64) NOT NULL DEFAULT '', `TABLE_TYPE` varchar(64) NOT NULL DEFAULT '', 解读发生了什么事物
最新发布
11-29
<think> 首先,用户的问题是关于解读MySQL二进制日志文件的。用户提到使用mysqlbinlog命令解析mysql-bin.000009文件并输出到mysql-bin.000009.log文件。现在,用户想知道这个.log文件内容所记录的事件。 从引用中,我了解到: - 引用[1]:MySQL二进制日志通常存储在/var/log/mysql下,名为mysql-bin.000*格式。使用mysqlbinlog工具查看这些日志。 - 引用[3]:二进制日志记录DDL和DML操作(如INSERT, UPDATE, DELETE),但不包括SELECT。文件是二进制格式,需要用mysqlbinlog查看。 - 引用[4]:展示了如何使用mysqlbinlog命令查看日志,并可能导出到文件。 用户已经执行了类似的操作:mysqlbinlog --no-defaults mysql-bin.000009 > mysql-bin.000009.log。所以,mysql-bin.000009.log文件包含了解析后的日志内容。 现在,我需要解释这个.log文件的内容所记录的事件。根据MySQL文档,二进制日志记录数据库的所有更改事件,包括: - DDL语句:如CREATE, ALTER, DROP DATABASE/TABLE等。 - DML语句:如INSERT, UPDATE, DELETE。 - 其他事件:如事务开始和提交、事件时间戳、服务器ID、位置信息等。 mysqlbinlog工具将这些二进制事件解析为可读的文本格式。输出文件内容通常包括: 1. **事件头**:每个事件都有一个头,包括时间戳、事件类型、服务器ID、结束位置等。 2. **SQL语句**:对于数据更改事件,它会显示实际的SQL语句。 3. **额外信息**:如事务ID、线程ID、执行时间等。 标准输出格式类似于: ``` # at 1234 #200101 12:34:56 server id 1 end_log_pos 5678 SET TIMESTAMP=1577864096/*!*/; BEGIN /*!*/; # at 5678 #200101 12:35:00 server id 1 end_log_pos 7890 UPDATE table_name SET column='value' WHERE id=1 /*!*/; # at 7890 #200101 12:35:01 server id 1 end_log_pos 9102 COMMIT/*!*/; ``` - `# at NNNN` 表示事件的开始位置。 - `#YYYYMMDD HH:MM:SS server id X end_log_pos YYYY` 表示时间戳、服务器ID和结束位置。 - 然后是SQL语句。 事件类型包括: - `Query_event`: SQL查询,如DDLDML。 - `Table_map_event`: 表映射信息。 - `Write_rows_event`, `Update_rows_event`, `Delete_rows_event`: 行更改事件。 - `Xid_event`: 事务提交事件。 在解析后的日志中,这些事件以文本形式呈现。 用户想解读这些事件,意思是理解日志文件中记录了什么操作。 所以,在我的回答中,我应该: 1. 解释mysql-bin.000009.log文件的内容结构。 2. 描述常见的事件类型和它们的含义。 3. 提供如何读取和理解这些事件的指导。 4. 如果需要,给出示例。 由于用户已经解析了日志,焦点在解读内容上。 参考用户的历史:用户之前询问了MySQL日志相关的问题,但在这个查询中,用户提供了引用,所以我应该基于这些引用和一般知识回答。 回答结构: - 先确认用户的操作:用户已经使用mysqlbinlog解析了日志文件。 - 然后解释.log文件的内容:它包含了MySQL二进制日志中记录的所有事件的可读形式。 - 详细说明事件类型:如DDL、DML操作。 - 提供解读步骤:如何查看文件、识别事件等。 - 最后,生成相关问题。 系统指令要求: - 所有行内数学表达式用$...$,但这里不涉及数学,所以可能不需要。 - 独立公式用$$...$$,也不需要。 - LaTeX语法正确:不适用。 - 使用中文回答。 - 生成相关问题:在最后添加相关问题。 - 回答中引用的段落末尾自然地添加引用标识:从提供的引用中引用。 提供的引用有: - [^1]:关于日志位置和命令。 - [^2]:关于日志轮换。 - [^3]:关于二进制日志内容。 - [^4]:命令示例。 - [^5]:显示日志文件。 我可以引用这些来支持我的回答。 例如,当解释二进制日志记录DDL和DML时,引用[^3]。 当提到日志位置时,引用[^1]。 用户真正的需求是解读日志文件事件,所以我会集中在内容解读上。 回答大纲: 1. **介绍**:解释mysql-bin.000009.log文件是什么,它是如何生成的。 2. **内容结构**:描述日志文件的典型内容格式。 3. **事件类型**:详细解释常见的事件类型,如: - 查询事件(DDL和DML) - 行事件(INSERT, UPDATE, DELETE) - 事务事件(BEGIN, COMMIT) - 其他事件(如时间戳、位置) 4. **如何解读**:给出一个简单的指南,如何读取文件并理解事件。 5. **示例**:提供一个简化的示例内容并解释。 6. **结论**:总结日志文件的重要性。 最后,生成相关问题。 相关问题想法: 1. 如何过滤mysqlbinlog输出以只显示特定表的事件? 2. MySQL二进制日志的配置选项有哪些? 3. 如何使用二进制日志进行数据恢复? 4. 二进制日志中的事件时间戳如何解读? 确保回答用中文。 </think>根据您的查询,您已经使用 `mysqlbinlog` 命令将 MySQL 二进制日志文件 `mysql-bin.000009` 解析并输出到 `mysql-bin.000009.log` 文件中。这个 `.log` 文件包含了 MySQL 二进制日志的可读文本形式,记录了数据库的所有更改事件,包括数据定义语言(DDL)和数据操作语言(DML)操作。MySQL 二进制日志(binlog)是 MySQL 用于记录数据库更改的机制,主要用于复制、数据恢复和审计[^3]。下面我将逐步解释如何解读 `mysql-bin.000009.log` 文件的内容所记录的事件。回答基于 MySQL 的一般知识以及您提供的引用内容(如日志位置、命令示例等)。 ### 1. **日志文件的基本结构和内容概述** - **生成过程**:您使用的命令类似于 `mysqlbinlog --no-defaults mysql-bin.000009 > mysql-bin.000009.log`,这会将二进制文件转换为可读的文本格式。MySQL 二进制日志默认存储在 `/var/log/mysql/` 目录下(引用[^1]),文件名为 `mysql-bin.000*` 格式。 - **内容组成**:解析后的 `.log` 文件包含一系列“事件”(events),每个事件代表一个数据库操作元信息。事件包括: - **事件头**:提供事件的元数据,如时间戳、事件类型、服务器 ID、日志位置等。 - **事件体**:记录实际的操作详情,例如 SQL 语句行级更改。 - 二进制日志只记录更改数据的操作(如 INSERT、UPDATE、DELETE、CREATE、ALTER 等),不包括 SELECT 查询(引用[^3])。 - **典型结构**:每个事件以注释行(以 `#` 开头)描述元数据,后跟 SQL 语句操作细节。例如: ``` # at 123456 #240101 10:00:00 server id 1 end_log_pos 123789 CRC32 0xabcdefgh SET TIMESTAMP=1700000000/*!*/; BEGIN /*!*/; # at 123789 #240101 10:00:05 server id 1 end_log_pos 124567 Query thread_id=10 exec_time=0 error_code=0 UPDATE users SET name='John' WHERE id=1 /*!*/; # at 124567 #240101 10:00:06 server id 1 end_log_pos 124890 Xid = 15 COMMIT/*!*/; ``` 在这个示例中: - `# at NNNNN` 表示事件的开始位置(在日志文件中的字节偏移)。 - `#YYYYMMDD HH:MM:SS server id X end_log_pos YYYY` 表示事件的时间戳、服务器 ID 和结束位置(引用[^3])。 - `SET TIMESTAMP` 设置操作的时间点。 - `BEGIN` 和 `COMMIT` 表示事务的开始和提交。 - `UPDATE` 语句是具体的 DML 操作。 ### 2. **常见事件类型及其解读** MySQL 二进制日志事件主要分为几类,每个事件在 `.log` 文件中以特定格式呈现。以下是最常见的事件类型及如何解读它们: - **Query Event(查询事件)**: - **描述**:记录 DDL(如 CREATE、ALTER、DROP) DML(如 INSERT、UPDATE、DELETE)语句。这是最常见的类型。 - **如何识别**:事件头中包含 `Query` 关键字,后跟 SQL 语句。 - **示例解读**: ``` # at 100000 #240101 09:30:00 server id 1 end_log_pos 100500 Query thread_id=5 exec_time=0 error_code=0 CREATE TABLE test (id INT PRIMARY KEY, name VARCHAR(50)) /*!*/; ``` - **解读**:在 2024 年 1 月 1 日 09:30:00,服务器 ID 1 执行了一个创建表的操作(DDL),线程 ID 为 5,执行时间为 0 毫秒,无错误。`end_log_pos 100500` 表示该事件结束于位置 100500。 - **Row Events(行事件)**: - **描述**:记录行级更改(如 INSERT、UPDATE、DELETE),通常用于基于行的复制。与 Query Event 不同,Row Events 不直接显示 SQL 语句,而是显示更改的行数据(包括前后值)。 - **如何识别**:事件头中包含 `Write_rows`(INSERT)、`Update_rows`(UPDATE) `Delete_rows`(DELETE)关键字。事件体以二进制格式显示行数据,但 `mysqlbinlog` 会将其解析为可读形式。 - **示例解读**: ``` # at 200000 #240101 10:15:00 server id 1 end_log_pos 200400 Table_map: `db`.`users` mapped to number 142 # at 200400 #240101 10:15:01 server id 1 end_log_pos 200800 Update_rows: table id 142 flags: STMT_END_F ### UPDATE `db`.`users` ### WHERE ### @1=1 /* INT meta=0 nullable=0 is_null=0 */ ### @2='OldName' /* VARSTRING(100) meta=100 nullable=1 is_null=0 */ ### SET ### @1=1 /* INT meta=0 nullable=0 is_null=0 */ ### @2='NewName' /* VARSTRING(100) meta=100 nullable=1 is_null=0 */ /*!*/; ``` - **解读**:首先,`Table_map` 事件将表 `db.users` 映射到内部 ID 142(用于后续行事件)。然后,`Update_rows` 事件更新了 `users` 表中 ID 为 1 的行,将名字从 'OldName' 改为 'NewName'。`WHERE` 部分指定条件,`SET` 部分指定新值。列以 `@1`、`@2` 形式引用(对应表列顺序)。 - **Transaction Events(事务事件)**: - **描述**:记录事务的开始和提交,用于确保数据一致性。 - **如何识别**:`BEGIN` 表示事务开始,`COMMIT` `Xid` 表示事务提交。 - **示例解读**: ``` # at 150000 #240101 09:45:00 server id 1 end_log_pos 150123 GTID 0-1-100 SET @@session.gtid_next='0-1-100'/*!*/; BEGIN /*!*/; ... # at 150789 #240101 09:45:10 server id 1 end_log_pos 150900 Xid = 100 COMMIT/*!*/; ``` - **解读**:`BEGIN` 开始一个新事务,`GTID`(全局事务标识符)用于复制场景。`Xid` 事件(事务提交)包含事务 ID(100),表示该事务成功提交。 - **其他事件**: - **Format Description Event**:日志文件的第一个事件,描述 binlog 格式版本。 - **Rotate Event**:当日志文件轮换时发生,例如切换到新文件(如 `mysql-bin.000010`),引用[^2]提到日志轮换后新操作会写入下一个文件。 - **Heartbeat Event**:用于主从复制中的健康检查。 - **时间戳和位置信息**:每个事件都包含时间戳(可转换为日期时间)和日志位置(用于恢复复制),引用[^4]展示了如何使用时间戳过滤事件。 ### 3. **如何解读 `mysql-bin.000009.log` 文件的实用步骤** 要理解您生成的 `mysql-bin.000009.log` 文件内容,请按以下步骤操作: 1. **打开文件**:使用文本编辑器(如 `vi`、`nano` `cat`)查看文件。例如: ```bash cat mysql-bin.000009.log ``` 2. **顺序阅读事件**:事件按发生顺序排列。从文件顶部开始,查找 `# at` 行以识别事件边界。 3. **关注关键部分**: - 时间戳(如 `#240101 10:00:00`):转换为实际日期时间(格式为年月日 时分秒)。 - 事件类型(如 `Query`、`Update_rows`):确定操作类型。 - SQL 语句数据:分析具体操作,注意表名和列值。 4. **搜索特定操作**:如果想查找特定事件(如所有 UPDATE),在文件中搜索关键词如 `UPDATE` `Update_rows`。 5. **理解事务上下文**:事务以 `BEGIN` 开始,`COMMIT` 结束。如果事件在事务中,它们具有原子性(全部成功全部失败)。 6. **错误排查**:如果日志包含错误(如 `error_code` 非零),它可能指示操作失败原因(引用[^1]提到错误日志在 `error.log` 中,但 binlog 也可能记录相关事件)。 ### 4. **重要注意事项** - **日志文件大小和轮换**:MySQL 二进制日志文件会轮换(如当文件大小达到阈值),旧文件被归档(引用[^2])。`mysql-bin.000009` 是特定序列的文件,解析后文件不会再有新写入。 - **安全与隐私**:日志可能包含敏感数据(如用户信息),确保文件权限安全。 - **用途**:这些事件可用于数据恢复(如通过 `mysqlbinlog` 重放日志)、复制同步审计数据库更改(引用[^4])。 - **位置信息**:`end_log_pos` 值在日志分析中很重要,例如用于指定恢复点(如 `mysqlbinlog --start-position=123456`)。 总之,`mysql-bin.000009.log` 文件记录了 MySQL 服务器在指定时间段内的所有数据库更改事件,包括具体的 SQL 操作、事务和时间戳。通过阅读事件类型和内容,您可以重建数据库操作历史。如果您提供日志文件的片段,我可以帮助更详细地解读特定事件。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值