基於Xtrabackup備份集來恢復某個誤刪除的表（drop）

来源:https://www.cnblogs.com/aaron8219/archive/2018/07/26/9375190.html
-Advertisement-
Play Games

Preface Yesterday,I've demonstratated how to rescue a droped and a truncated table based on mysqldump backup.Let's see what's different in rescuing th ...


  Preface       Yesterday,I've demonstratated how to rescue a droped and a truncated table based on mysqldump backup.Let's see what's different in rescuing them based on a backup set made by Xtrabackup.Binlog is also indispensable,if we want to rerieve all the incremental data of them.   Framework  
Hostname IP/Port Identity OS Version MySQL Version GTID Mode Binlog Format
zlm2 192.168.1.101/3306 master CentOS 7.0 5.7.21 on row
zlm3 192.168.1.102/3306 slave CentOS 7.0 5.7.21 on row
  Precedure   Step 1: Destroy the table.   Generate a backup with Xtrabackup first. 
 1 [root@zlm2 07:57:40 ~]
 2 #innobackupex --defaults-file=/data/mysql/mysql3306/my.cnf -uroot -pPassw0rd /data/backup
 3 xtrabackup: recognized server arguments: --datadir=/data/mysql/mysql3306/data --tmpdir=/data/mysql/mysql3306/tmp --open_files_limit=65535 --server-id=1013306 --log_bin=/data/mysql/mysql3306/logs/mysql-bin --innodb_buffer_pool_size=100M --innodb_data_file_path=ibdata1:100M:autoextend --innodb_flush_log_at_trx_commit=2 --innodb_log_buffer_size=8M --innodb_log_file_size=100M --innodb_log_files_in_group=3 --innodb_max_dirty_pages_pct=50 --innodb_file_per_table=1 --innodb_io_capacity=2000 --innodb_flush_method=O_DIRECT --server-id=1013306 
 4 xtrabackup: recognized client arguments: --datadir=/data/mysql/mysql3306/data --tmpdir=/data/mysql/mysql3306/tmp --open_files_limit=65535 --server-id=1013306 --log_bin=/data/mysql/mysql3306/logs/mysql-bin --innodb_buffer_pool_size=100M --innodb_data_file_path=ibdata1:100M:autoextend --innodb_flush_log_at_trx_commit=2 --innodb_log_buffer_size=8M --innodb_log_file_size=100M --innodb_log_files_in_group=3 --innodb_max_dirty_pages_pct=50 --innodb_file_per_table=1 --innodb_io_capacity=2000 --innodb_flush_method=O_DIRECT --server-id=1013306 
 5 180727 07:57:43 innobackupex: Starting the backup operation
 6 
 7 IMPORTANT: Please check that the backup run completes successfully.
 8            At the end of a successful backup run innobackupex
 9            prints "completed OK!".
10 
11 ... //Omitted the procedure.
12 
13 180727 07:57:56 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
14 xtrabackup: The latest check point (for incremental): '10141351562'
15 xtrabackup: Stopping log copying thread.
16 .180727 07:57:56 >> log scanned up to (10141351571)
17 
18 180727 07:57:56 Executing UNLOCK TABLES
19 180727 07:57:56 All tables unlocked
20 180727 07:57:56 [00] Copying ib_buffer_pool to /data/backup/2018-07-27_07-57-43/ib_buffer_pool
21 180727 07:57:56 [00]        ...done
22 180727 07:57:56 Backup created in directory '/data/backup/2018-07-27_07-57-43/'
23 MySQL binlog position: filename 'mysql-bin.000035', position '954887', GTID of the last change '1b7181ee-6eaf-11e8-998e-080027de0e0e:1-3730220'
24 180727 07:57:56 [00] Writing /data/backup/2018-07-27_07-57-43/backup-my.cnf
25 180727 07:57:56 [00]        ...done
26 180727 07:57:56 [00] Writing /data/backup/2018-07-27_07-57-43/xtrabackup_info
27 180727 07:57:56 [00]        ...done
28 xtrabackup: Transaction log of lsn (10141351562) to (10141351571) was copied.
29 180727 07:57:56 completed OK!

 

Continue to execute dml operation. 
 1 (zlm@192.168.1.101 3306)[sysbench]>show tables;
 2 +--------------------+
 3 | Tables_in_sysbench |
 4 +--------------------+
 5 | sbtest1            |
 6 | sbtest2            |
 7 | sbtest3            |
 8 | sbtest4            |
 9 | sbtest5            |
10 | sbtest6            |
11 | sbtest7            |
12 +--------------------+
13 7 rows in set (0.00 sec)
14 
15 (zlm@192.168.1.101 3306)[sysbench]>select count(*) from sbtest7;
16 +----------+
17 | count(*) |
18 +----------+
19 |    10000 |
20 +----------+
21 1 row in set (0.00 sec)
22 
23 (zlm@192.168.1.101 3306)[sysbench]>show master status;
24 +------------------+----------+--------------+------------------+------------------------------------------------+
25 | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                              |
26 +------------------+----------+--------------+------------------+------------------------------------------------+
27 | mysql-bin.000035 |   954887 |              |                  | 1b7181ee-6eaf-11e8-998e-080027de0e0e:1-3730220 |
28 +------------------+----------+--------------+------------------+------------------------------------------------+
29 1 row in set (0.00 sec)
30 
31 (zlm@192.168.1.101 3306)[sysbench]>flush logs;
32 Query OK, 0 rows affected (0.02 sec)
33 
34 (zlm@192.168.1.101 3306)[sysbench]>delete from sbtest7 limit 10;
35 Query OK, 10 rows affected (0.00 sec)
36 
37 (zlm@192.168.1.101 3306)[sysbench]>select count(*) from sbtest7;
38 +----------+
39 | count(*) |
40 +----------+
41 |     9990 |
42 +----------+
43 1 row in set (0.00 sec)
44 
45 (zlm@192.168.1.101 3306)[sysbench]>show master status;
46 +------------------+----------+--------------+------------------+------------------------------------------------+
47 | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                              |
48 +------------------+----------+--------------+------------------+------------------------------------------------+
49 | mysql-bin.000036 |     2338 |              |                  | 1b7181ee-6eaf-11e8-998e-080027de0e0e:1-3730221 |
50 +------------------+----------+--------------+------------------+------------------------------------------------+
51 1 row in set (0.00 sec)

 

Drop table "sbtest7" in "sysbench" database on master in a certain time(our miss operation point). 
 1 (zlm@192.168.1.101 3306)[sysbench]>drop table sbtest7;
 2 Query OK, 0 rows affected (0.00 sec)
 3 
 4 (zlm@192.168.1.101 3306)[sysbench]>show tables;
 5 +--------------------+
 6 | Tables_in_sysbench |
 7 +--------------------+
 8 | sbtest1            |
 9 | sbtest2            |
10 | sbtest3            |
11 | sbtest4            |
12 | sbtest5            |
13 | sbtest6            |
14 +--------------------+
15 6 rows in set (0.00 sec)
16 
17 (zlm@192.168.1.101 3306)[sysbench]>show master status;
18 +------------------+----------+--------------+------------------+------------------------------------------------+
19 | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                              |
20 +------------------+----------+--------------+------------------+------------------------------------------------+
21 | mysql-bin.000036 |     2523 |              |                  | 1b7181ee-6eaf-11e8-998e-080027de0e0e:1-3730222 |
22 +------------------+----------+--------------+------------------+------------------------------------------------+
23 1 row in set (0.00 sec)

 

Step 2: Begin to restore backup set.   Copy the backup set to another server(mine is zlm3) with newly initialized instance of MySQL. 
 1 [root@zlm2 08:03:12 /data/backup]
 2 #ls -l
 3 total 4
 4 drwxr-x--- 6 root root 4096 Jul 27 07:57 2018-07-27_07-57-43
 5 
 6 [root@zlm2 08:03:15 /data/backup]
 7 #tar cf innobkex_full.tar 2018-07-27_07-57-43/
 8 
 9 [root@zlm2 08:03:42 /data/backup]
10 #ls -l
11 total 187384
12 drwxr-x--- 6 root root      4096 Jul 27 07:57 2018-07-27_07-57-43
13 -rw-r--r-- 1 root root 191877120 Jul 27 08:03 innobkex_full.tar
14 
15 [root@zlm2 08:03:48 /data/backup]
16 #scp innobkex_full.tar zlm3:/data/backup
17 root@zlm3's password: 
18 innobkex_full.tar                                                                                                  100%  183MB  91.5MB/s   00:02    
19 
20 [root@zlm2 08:04:39 /data/backup]
21 #

 

Prepare to restore the table "sbtest7". 
 1 [root@zlm3 08:05:13 /data/backup]
 2 #ls -l
 3 total 187380
 4 -rw-r--r-- 1 root root 191877120 Jul 27 08:04 innobkex_full.tar
 5 
 6 [root@zlm3 08:05:15 /data/backup]
 7 #tar xf innobkex_full.tar 
 8 
 9 [root@zlm3 08:05:20 /data/backup]
10 #ls -l
11 total 187384
12 drwxr-x--- 6 root root      4096 Jul 27 07:57 2018-07-27_07-57-43
13 -rw-r--r-- 1 root root 191877120 Jul 27 08:04 innobkex_full.tar
14 
15 [root@zlm3 08:06:06 /data/backup]
16 #cd 2018-07-27_07-57-43/
17 
18 [root@zlm3 08:06:22 /data/backup/2018-07-27_07-57-43]
19 #ls -l
20 total 102464
21 -rw-r----- 1 root root       495 Jul 27 07:57 backup-my.cnf
22 -rw-r----- 1 root root      8988 Jul 27 07:57 ib_buffer_pool
23 -rw-r----- 1 root root 104857600 Jul 27 07:57 ibdata1
24 drwxr-x--- 2 root root      4096 Jul 27 07:57 mysql
25 drwxr-x--- 2 root root      8192 Jul 27 07:57 performance_schema
26 drwxr-x--- 2 root root      8192 Jul 27 07:57 sys
27 drwxr-x--- 2 root root      4096 Jul 27 07:57 sysbench
28 -rw-r----- 1 root root        71 Jul 27 07:57 xtrabackup_binlog_info
29 -rw-r----- 1 root root       121 Jul 27 07:57 xtrabackup_checkpoints
30 -rw-r----- 1 root root       587 Jul 27 07:57 xtrabackup_info
31 -rw-r----- 1 root root      2560 Jul 27 07:57 xtrabackup_logfile
32 
33 [root@zlm3 08:06:23 /data/backup/2018-07-27_07-57-43]
34 #cd sysbench/
35 
36 [root@zlm3 08:06:25 /data/backup/2018-07-27_07-57-43/sysbench]
37 #ls -l
38 total 71768
39 -rw-r----- 1 root root       61 Jul 27 07:57 db.opt
40 -rw-r----- 1 root root     8632 Jul 27 07:57 sbtest1.frm
41 -rw-r----- 1 root root 10485760 Jul 27 07:57 sbtest1.ibd
42 -rw-r----- 1 root root     8632 Jul 27 07:57 sbtest2.frm
43 -rw-r----- 1 root root 10485760 Jul 27 07:57 sbtest2.ibd
44 -rw-r----- 1 root root     8632 Jul 27 07:57 sbtest3.frm
45 -rw-r----- 1 root root 10485760 Jul 27 07:57 sbtest3.ibd
46 -rw-r----- 1 root root     8632 Jul 27 07:57 sbtest4.frm
47 -rw-r----- 1 root root 10485760 Jul 27 07:57 sbtest4.ibd
48 -rw-r----- 1 root root     8632 Jul 27 07:57 sbtest5.frm
49 -rw-r----- 1 root root 10485760 Jul 27 07:57 sbtest5.ibd
50 -rw-r----- 1 root root     8632 Jul 27 07:57 sbtest6.frm
51 -rw-r----- 1 root root 10485760 Jul 27 07:57 sbtest6.ibd
52 -rw-r----- 1 root root     8632 Jul 27 07:57 sbtest7.frm
53 -rw-r----- 1 root root 10485760 Jul 27 07:57 sbtest7.ibd
54 
55 [root@zlm3 08:06:27 /data/backup/2018-07-27_07-57-43/sysbench]
56 #mv sbtest7* ../
57 
58 [root@zlm3 08:06:38 /data/backup/2018-07-27_07-57-43/sysbench]
59 #ls -l
60 total 61516
61 -rw-r----- 1 root root       61 Jul 27 07:57 db.opt
62 -rw-r----- 1 root root     8632 Jul 27 07:57 sbtest1.frm
63 -rw-r----- 1 root root 10485760 Jul 27 07:57 sbtest1.ibd
64 -rw-r----- 1 root root     8632 Jul 27 07:57 sbtest2.frm
65 -rw-r----- 1 root root 10485760 Jul 27 07:57 sbtest2.ibd
66 -rw-r----- 1 root root     8632 Jul 27 07:57 sbtest3.frm
67 -rw-r----- 1 root root 10485760 Jul 27 07:57 sbtest3.ibd
68 -rw-r----- 1 root root     8632 Jul 27 07:57 sbtest4.frm
69 -rw-r----- 1 root root 10485760 Jul 27 07:57 sbtest4.ibd
70 -rw-r----- 1 root root     8632 Jul 27 07:57 sbtest5.frm
71 -rw-r----- 1 root root 10485760 Jul 27 07:57 sbtest5.ibd
72 -rw-r----- 1 root root     8632 Jul 27 07:57 sbtest6.frm
73 -rw-r----- 1 root root 10485760 Jul 27 07:57 sbtest6.ibd
74 
75 [root@zlm3 08:06:39 /data/backup/2018-07-27_07-57-43/sysbench]
76 #rm -f sbtest* //Delete all those irrelevant tables which I'm not going to rescue.It can extremly reduce the content I need.
77 
78 [root@zlm3 08:06:45 /data/backup/2018-07-27_07-57-43/sysbench]
79 #mv ../sbtest* .
80 
81 [root@zlm3 08:06:57 /data/backup/2018-07-27_07-57-43/sysbench]
82 #ls -l
83 total 10256
84 -rw-r----- 1 root root       61 Jul 27 07:57 db.opt
85 -rw-r----- 1 root root     8632 Jul 27 07:57 sbtest7.frm
86 -rw-r----- 1 root root 10485760 Jul 27 07:57 sbtest7.ibd

 

Apply the redo logfile. 
 1 [root@zlm3 08:06:58 /data/backup/2018-07-27_07-57-43/sysbench]
 2 #innobackupex --defaults-file=/data/mysql/mysql3306/my.cnf --apply-log /data/backup/2018-07-27_07-57-43/
 3 xtrabackup: recognized server arguments: --innodb_checksum_algorithm=crc32 --innodb_log_checksum_algorithm=strict_crc32 --innodb_data_file_path=ibdata1:100M:autoextend --innodb_log_files_in_group=3 --innodb_log_file_size=104857600 --innodb_fast_checksum=0 --innodb_page_size=16384 --innodb_log_block_size=512 --innodb_undo_directory=./ --innodb_undo_tablespaces=0 --server-id=1013306 --redo-log-version=1 
 4 xtrabackup: recognized client arguments: --innodb_checksum_algorithm=crc32 --innodb_log_checksum_algorithm=strict_crc32 --innodb_data_file_path=ibdata1:100M:autoextend --innodb_log_files_in_group=3 --innodb_log_file_size=104857600 --innodb_fast_checksum=0 --innodb_page_size=16384 --innodb_log_block_size=512 --innodb_undo_directory=./ --innodb_undo_tablespaces=0 --server-id=1013306 --redo-log-version=1 
 5 180727 08:08:41 innobackupex: Starting the apply-log operation
 6 
 7 IMPORTANT: Please check that the apply-log run completes successfully.
 8            At the end of a successful apply-log run innobackupex
 9            prints "completed OK!".
10 
11 innobackupex version 2.4.12 based on MySQL server 5.7.19 Linux (x86_64) (revision id: 170eb8c)
12 xtrabackup: cd to /data/backup/2018-07-27_07-57-43/
13 
14 ... //Omitted.
15 
16 InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0
17 InnoDB: New log files created, LSN=10141352841
18 InnoDB: Highest supported file format is Barracuda.
19 InnoDB: Log scan progressed past the checkpoint lsn 10141352972
20 InnoDB: Doing recovery: scanned up to log sequence number 10141352981 (0%)
21 InnoDB: Database was not shutdown normally!
22 InnoDB: Starting crash recovery.
23 InnoDB: xtrabackup: Last MySQL binlog file position 954219, file name mysql-bin.000035
24 InnoDB: Removed temporary tablespace data file: "ibtmp1"
25 InnoDB: Creating shared tablespace for temporary tables
26 InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
27 InnoDB: File './ibtmp1' size is now 12 MB.
28 InnoDB: 96 redo rollback segment(s) found. 1 redo rollback segment(s) are active.
29 InnoDB: 32 non-redo rollback segment(s) are active.
30 InnoDB: Waiting for purge to start
31 InnoDB: 5.7.19 started; log sequence number 10141352981
32 xtrabackup: starting shutdown with innodb_fast_shutdown = 1
33 InnoDB: page_cleaner: 1000ms intended loop took 18267ms. The settings might not be optimal. (flushed=0 and evicted=0, during the time.)
34 InnoDB: FTS optimize thread exiting.
35 InnoDB: Starting shutdown...
36 InnoDB: Shutdown completed; log sequence number 10141353000
37 180727 08:09:03 completed OK!
38 
39 [root@zlm3 08:09:03 /data/backup/2018-07-27_07-57-43/sysbench]
40 #cd ..
41 
42 [root@zlm3 08:11:14 /data/backup/2018-07-27_07-57-43]
43 #ls -l
44 total 430144
45 -rw-r----- 1 root root       495 Jul 27 07:57 backup-my.cnf
46 -rw-r----- 1 root root      8988 Jul 27 07:57 ib_buffer_pool
47 -rw-r----- 1 root root 104857600 Jul 27 08:09 ibdata1
48 -rw-r----- 1 root root 104857600 Jul 27 08:09 ib_logfile0
49 -rw-r----- 1 root root 104857600 Jul 27 08:08 ib_logfile1
50 -rw-r----- 1 root root 104857600 Jul 27 08:08 ib_logfile2
51 -rw-r----- 1 root root  12582912 Jul 27 08:09 ibtmp1
52 drwxr-x--- 2 root root      4096 Jul 27 07:57 mysql
53 drwxr-x--- 2 root root      8192 Jul 27 07:57 performance_schema
54 drwxr-x--- 2 root root      8192 Jul 27 07:57 sys
55 drwxr-x--- 2 root root        55 Jul 27 08:06 sysbench
56 -rw-r----- 1 root root        71 Jul 27 07:57 xtrabackup_binlog_info
57 -rw-r--r-- 1 root root        24 Jul 27 08:08 xtrabackup_binlog_pos_innodb
58 -rw-r----- 1 root root       121 Jul 27 08:08 xtrabackup_checkpoints
59 -rw-r----- 1 root root       587 Jul 27 07:57 xtrabackup_info
60 -rw-r----- 1 root root   8388608 Jul 27 08:08 xtrabackup_logfile
61 -rw-r--r-- 1 root root         1 Jul 27 08:08 xtrabackup_master_key_id
62 
63 [root@zlm3 08:11:15 /data/backup/2018-07-27_07-57-43]
64 #cat xtrabackup_binlog_info
65 mysql-bin.000035    954887    1b7181ee-6eaf-11e8-998e-080027de0e0e:1-3730220
66 
67 [root@zlm3 08:11:21 /data/backup/2018-07-27_07-57-43]
68 #cat xtrabackup_binlog_pos_innodb
69 mysql-bin.000035    954219
70 
71 //The result of "show master status;" on zlm2.
72 (zlm@192.168.1.101 3306)[(none)]>show master status;
73 +------------------+----------+--------------+------------------+------------------------------------------------+
74 | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                              |
75 +------------------+----------+--------------+------------------+------------------------------------------------+
76 | mysql-bin.000036 |     2523 |              |                  | 1b7181ee-6eaf-11e8-998e-080027de0e0e:1-3730222 | //The newest GTID is "uuid:1-3730222"
77 +------------------+----------+--------------+------------------+------------------------------------------------+
78 1 row in set (0.00 sec)

 

Shutdown the instance on zlm3 and copy back the datafiles 
 1 [root@zlm3 08:11:28 /data/backup/2018-07-27_07-57-43]
 2 #ps aux|grep mysqld
 3 mysql     5079
您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • Oracle學習整理
    Oracle資料庫，基礎知識點整合。希望看到的大神修正補充，感激不盡。 四大基本句式： 1.添加語句基本句式 Insert into 表名(欄位名) values(對應欄位的數據) 2.刪除基本句式 delete from 表名 where 限制條件 限制條件不寫會刪除整張表的數據 3.修改基本句式 ...
  • MySQL資料庫優化方法
    一、表類型MyISAM 和 InnoDB的區別 作者：Oscarwin鏈接：https://www.zhihu.com/question/20596402/answer/211492971來源：知乎著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。 區別： 1. InnoDB支持事 ...
  • 什麼是大數據？如何成為大數據的技術大牛？
    其實大數據並不是一種概念，而是一種方法論。簡單來說，就是通過分析和挖掘全量的非抽樣的數據輔助決策。大數據可以實現的應用可以概括為兩個方向，一個是精準化定製，第二個是預測。比如像通過搜索引擎搜索同樣的內容，每個人的結果卻是大不相同的。再比如精準營銷、百度的推廣、淘寶的喜歡推薦，或者你到了一個地方，自動 ...
  • MySQL案例07:MySQL5.7併發複製隱式bug
    我們MySQL線上環境大部分使用的是5.7.18的版本，這個版本已修複了很多bug，但針對主從複製的bug還是有很多的，尤其是一些組複製、並行複製的bug尤為突出，在5.7.19版本有做相應改善和修複。所以建議5.7.19之前的版本還是不要使用mgr和併發複製的功能，如使用建議升級至5.7.19（含 ...
  • sql server 索引闡述系列七 索引填充因數與碎片
    一.概述 索引填充因數作用：提供填充因數選項是為了優化索引數據存儲和性能。 當創建或重新生成索引時，填充因數的值可確定每個葉級頁上要填充數據的空間百分比，以便在每一頁上保留一些剩餘存儲空間作為以後擴展索引的可用空間，例如：指定填充因數的值為 80 表示每個葉級頁上將有 20% 的空間保留為空，以便隨 ...
  • 如何做數據分析師？教你從零開始系統規劃大數據學習之路
    大數據的領域非常廣泛，往往使想要開始學習大數據及相關技術的人望而生畏。大數據技術的種類眾多，這同樣使得初學者難以選擇從何處下手。 本文將為你開始學習大數據的徵程以及在大數據產業領域找到工作指明道路，提供幫助。目前我們面臨的最大挑戰就是根據我們的興趣和技能選定正確的角色。 為瞭解決這個問題，我在本文詳 ...
  • mysql 開發進階篇系列 8 鎖問題 (Innodb 行鎖實現方式)
    一.概述 Innodb 行鎖是通過給索引上的索引項加鎖來實現的。這一點與（oracle，sql server）不同後者是通過在數據塊中對相應的數據行加鎖。這意味著只有通過索引條件檢索數據，innodb才使用行級鎖，否則 innodb將使用表鎖。 在實際應用中，特別要註意innodb行鎖的這一特性，不 ...
  • 高性能MySQL--MySQL數據類型介紹和最優數據類型選擇
    MySQL支持的數據類型很多，那麼選擇合適的數據類型對於獲得高性能就至關重要。那麼就先瞭解各種類型的優缺點！ 一、類型介紹 1、整型類型 整型類型有： TINYINT，SMALLINT，MEDIUMINT，INT，BIGINT 。他們分別占8，16，24，32，64位儲存空間。可存儲的整數範圍為-2 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類