找回密码
 注册
查看: 1391|回复: 4

MySQL/mariadb误删ibdata1 ib_logfile0,ib_logfile1 恢复方法

[复制链接]

1

主题

0

回帖

12

积分

管理员

积分
12
QQ
发表于 2021-12-15 01:00:03 | 显示全部楼层 |阅读模式
MySQL误删ibdata1 ib_logfile0,ib_logfile1 恢复方法:
4 }1 p0 L6 j# V2 W  n7 k3 [, D5 q" v9 K
恢复的步骤和数据库版本没有太大关系。" S3 a4 s# K! v; f0 y" e
在linux操作系统中,如果文件从操作系统级别别rm掉,之前打开的文件进程仍持有相应的文件句柄,/ a5 a/ K# `* ~" E$ S2 P/ O) H
所指向的文件仍然可以读写,且该文件的描述符可以从/proc目录中获得(不关闭MySQLd情况下).+ ?% R# b; {2 k3 W

% u2 b. ]" B! h) Y( }8 P在删除3个文件后,MySQLd 仍是可以运行,对外服务的,MySQL一只保持InnoDB文件打开,因此,
1 a* k- T: j/ D+ A/ y5 w& n1 F4 }在工作中有必要监控文件是否存在。/ {7 F" ]* j( k& u
发现文件被删除之后,不能重启InnoDB,因为启动InnoDB,检测到ibdata1,ib_logfile0,ib_logfile1
! g. {5 K' k/ N9 D# l: Y不存在,所以,将创建对应的空文件,InnoDB数据字典是空的,InnoDB无法使用原先存在的ibd文件,故,
6 r- S! s4 P5 m# y3 _" c& Q1 ?' DMySQL不重启,快速恢复删除的文件是可能的。! w1 c5 w+ P+ A

! C( s0 d/ S2 ]! B, M在MySQLd运行过程中,ibdata1,ib_logfile0,ib_logfile1一直运行在* k' {! H, j* {% r
/proc/mysql.pid/fd目录下,其中vm-mysql.pid是mysql进程的PID,获取方法:
( G+ p5 e( h3 u7 N4 r: U. S[root@mysql ~]# ls -l /proc/$(cat /opt/mysql/data2/mysql.pid)/fd | grep -e ibdata -e ib_* L% X7 P# M) [5 G7 ^9 O
lrwx------ 1 root root 64 Oct 16 14:16 10 -> /opt/mysql/data2/ib_logfile1 (deleted)  ^1 t& A6 h, R) B! G0 d% W5 z
lrwx------ 1 root root 64 Oct 16 14:16 4 -> /opt/mysql/data2/ibdata1 (deleted)8 g& M9 J3 M) @1 t. M( }
lrwx------ 1 root root 64 Oct 16 14:16 9 -> /opt/mysql/data2/ib_logfile0 (deleted)
( M% Y# y" {% D( l! N1 u4 F0 r( w( r7 K, w( n! J
但是,我们不能简单copy回源目录中,因在buffer pool有已经修改的页,这些页没有被写入磁盘,如果改变的页
$ C0 z5 k# y- U$ \* A3 b8 N8 T- u3 h没有永久写入,数据将会丢失,这些导致数据损坏和丢失。
9 L! k: {8 s* S同样原因,我们不能做MySQL备份,仅能coping那些文件。
$ J9 A# ?% {3 B因此,我们必须确保所有的修改全写入磁盘中。
0 j. x$ s, p" ^6 P  {! s我们现在能做的阻止写,且等待InnoDB刷新所有的页。: c! E" K; M9 N; i8 L! X
1.为了阻止写,我们要么停止应用程序或锁表。. Y6 y1 o' w+ h+ }  u9 i' P" ?0 o
MariaDB [(none)]> flush tables with read lock;. |. [% T5 @! ]5 X+ Z6 q
Query OK, 0 rows affected (0.01 sec)0 K. \5 m/ e% A8 P' F" I
7 M( l; \  b7 `! h
2. show engine innodb status 中脏页刷新到磁盘,
6 L" B) R* c, {* O( o---, n- F+ M( }$ T; L! e6 Z
LOG6 h) ?5 x2 R4 G- V; ?
---
& J, t' N$ f) `( g: uLog sequence number 0 50355" B' {- @4 U/ m  k" U0 C% p
Log flushed up to   0 50355
! N- g+ ^" w/ ^' j4 |Last checkpoint at  0 50355
6 _$ u4 \- x' O" u: y) F0 pending log writes, 0 pending chkp writes7 |4 L# J  F1 L
39 log i/o's done, 0.00 log i/o's/second6 P: R1 k) \9 r9 _% ~
+ H8 c3 s) L$ u' [% h! ?
加速脏页刷新,设置dirty pages percentage to zero:
( S3 H' u. l9 |6 C* ?. qMariaDB [(none)]> set global innodb_max_dirty_pages_pct=0;
: {2 V6 E& W3 y! R7 pQuery OK, 0 rows affected (0.00 sec)
& C. I, d" o' C6 r7 a& ]
0 x4 n" f. O+ \# l$ n/ G/ w5 K3.确保所有后台进程已经完成自己的工作,也是重要的。3 ^! v& \1 {- h0 Z" Z$ [; @
注意,插入缓冲线程,它的大小等于1
3 `% u8 a4 [% a" U-------------------------------------
# h* i+ c/ Z' X8 ^( m% fINSERT BUFFER AND ADAPTIVE HASH INDEX  u. Q  F# w) @8 t2 ?
-------------------------------------: T8 X7 P. U4 P" X) z7 L: \
Ibuf: size 1, free list len 0, seg size 2,
3 `+ R* i3 Y9 J( o0 h7 x2 R0 inserts, 0 merged recs, 0 merges
# L6 }3 G6 p9 `. L7 d/ xHash table size 34679, node heap has 1 buffer(s)
5 \- g! j9 O0 P% c" |0.00 hash searches/s, 0.00 non-hash searches/s0 |- Y. s8 I# ?& [4 K

: v1 D, [0 q! l4 Z6 h- I  t4.后台写进程purge thread,清除所有事务。1 w1 b0 B# G) p0 [% C/ e2 Q" X9 Y
------------
$ r' P/ h3 Y! p. RTRANSACTIONS8 s6 g8 M& L( y! F6 A$ Q$ E5 a
------------6 n9 l6 u* }8 N9 L  Y$ ?+ o$ U
Trx id counter 0 784$ |6 i- S; {. g6 O0 {) |6 F
Purge done for trx's n:o < 0 0 undo n:o < 0 0
+ d4 S  I$ s/ v" h) _但是,如果上次事务没有需要清理操作Trx id计数比较大(如,SELECT),
( q2 I/ ?/ ^1 {4 \在这种情况下,至少要保证InnoDB不再做任何写动作。
( t2 r# H& X7 X--------
, j4 A% s2 d/ s! Q# kFILE I/O1 v: A) B7 C" f. Q. k
--------! y2 H5 j9 }  h8 p  `% A7 H
I/O thread 0 state: waiting for i/o request (insert buffer thread)
" U5 e4 c1 M% g& rI/O thread 1 state: waiting for i/o request (log thread)! f% Q2 I5 s. ~7 z: _
I/O thread 2 state: waiting for i/o request (read thread)* Z& L9 [& V7 _" w. [/ \
I/O thread 3 state: waiting for i/o request (write thread)
, I( b7 D7 o( _Pending normal aio reads: 0, aio writes: 0,  u6 L# W& v' Y1 G: a9 C
ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
+ J$ \* C, U1 s  z" z, |$ H, Z( PPending flushes (fsync) log: 0; buffer pool: 02 U- T& m+ ~# y
0 OS file reads, 81 OS file writes, 59 OS fsyncs. ]# {" r) x- O8 c; i9 j
0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s; B' Y$ ^% n5 T1 Z7 q( U  w
( H  E" S  s5 y2 W
经历了4步,所有被修改脏页刷新到磁盘,现在开始copy InnoDB 文件到源目录:( A" L6 D, G! G/ H/ @
[root@mysql ~]# cp /proc/$(cat /opt/mysql/data2/mysql.pid)/fd/4 /opt/mysql/data2/ibdata15 Q% [5 P: N5 ]" p) F2 |
[root@mysql ~]# cp /proc/$(cat /opt/mysql/data2/mysql.pid)/fd/9 /opt/mysql/data2/ib_logfile0# k2 |, [1 t, U5 N! {( s
[root@mysql ~]# cp /proc/$(cat /opt/mysql/data2/mysql.pid)/fd/10 /opt/mysql/data2/ib_logfile1
" K/ s% m7 ^; w- d5 z0 o" H& f3 k" n; ~9 o* @4 r
5.修改ib*所属用户1 P; v- C2 X$ |" y
chown -R mysql ib*# ~. l  ^" m* K% z- j

- R4 H0 G: g; `6.重启MySQLd; o: [* E% Q5 ^. B7 A
........
# F: s; L9 Y1 c* r* Y5 L  D+ L& M- ~: M; [
结论:; o& G( S- j& E+ I9 j: X2 u6 L' K3 g
1.监控InnoDB文件 ibdata 和 ib_logfile* 是否存在7 D  F; H+ g9 o0 H$ n% r
2.清楚恢复策略,否则不要重启MySQLd3 z* I" m$ t( p2 p; h* c0 ^

1

主题

0

回帖

12

积分

管理员

积分
12
QQ
 楼主| 发表于 2021-12-15 01:00:04 | 显示全部楼层
于是再/ect/my.cnf中加入max_connections=1000    wait_timeout=5这两个配置
, {+ l+ p6 R5 O- `
2 K9 |, b8 v! \( H& B0 T! ~; E. @4 ~6 |/ i7 R+ |' [5 p

6 _* b4 {# n' C( O# ]& R3 W& M重启mysql,启动成功,但是项目却无法打开,又重新打开mysql日志发现他一直无休止的重启,百度搜了好多办法都不行
$ n& y, d7 X  s9 h: {- _% T& |. m7 Z6 ]5 C2 U
后来看到这段配置8 v0 n0 G7 z+ T9 O

# [6 q5 L! j" q! ?  @1 r% m. n3 `
6 p) D& {' x( _1 s- _- ^; r' G  I+ e! g3 X$ ?- J4 H
我想应该是因为文件问题导致ibdata1损坏了,然后从1 到6全部都试了一遍,效果却是然并卵
) I2 K- V( g& {) j
6 {0 L: y4 w2 e8 K到最后是这样配置的
6 x& d3 a4 \9 d6 }0 _! H* V* k5 H. ?: F
https://img-blog.csdn.net/20180511171205193?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dsX2FuZw==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70
' g0 ]9 x5 X9 }* W% v1 z" |! J& P) c4 `
然后重启mysql没有问题,然后打开项目发现还是访问不了,后来发现tomcat停了,重启tomcat,完美解决
& Z6 Y6 q% d1 T( H. g- T6 x

1

主题

0

回帖

12

积分

管理员

积分
12
QQ
 楼主| 发表于 2021-12-15 01:00:05 | 显示全部楼层
操作步骤:
2 Q$ O( P% w9 d4 ]

1

主题

0

回帖

12

积分

管理员

积分
12
QQ
 楼主| 发表于 2021-12-15 01:00:06 | 显示全部楼层

概念:0 i, d/ c% H( b
事務日誌或稱redo日誌,在mysql中默認以ib_logfile0,ib_logfile1名稱存在,可以手工修改參數,調節開啟幾組日誌來服務於當前mysql數據庫,mysql采用順序,循環寫方式,每開啟一個事務時,會把一些相關信息記錄事務日誌中(記錄對數據文件數據修改的物理位置或叫做偏移量);4 D9 x  \, U* s% [) p6 Z4 `" r5 ]
這個系列文件個數由參數innodb_log_files_in_group控制,若設置為4,則命名為ib_logfile0~3。
' k9 u2 q9 ~0 n; |這些文件的寫入是順序、循環寫的,logfile0寫完從logfile1繼續,logfile3寫完則logfile0繼續。
; M  m1 r- g- ]; b1 Q+ z7 ?- L9 j  a4 O; X+ ?  u
作用:
. H+ y2 t6 g  H8 w& W在系統崩潰重啟時,作事務重做;在系統正常時,每次checkpoint時間點,會將之前寫入事務應用到數據文件中。/ z7 K' V6 V5 ]- w

( S- z8 s- y9 [2 Y* z$ ?Ib_logfile的checkpoint field
/ t9 W  U( a0 g! R3 n4 i3 D實際上不僅要記錄checkpoint做到哪兒(LOG_CHECKPOINT_LSN),還要記錄用到了哪個位置(LOG_CHECKPOINT_OFFSET)等其他信息。所以在ib_logfile0的頭部預留了空間,用於記錄這些信息。
* c% h( L8 R/ t) v因此即使使用後面的logfile,每次checkpoint完成後,ib_logfile0都是要更新的。同時你會發現所謂的順序寫盤,也並不是絕對的
5 g, j, F) L( {7 @, J8 ^' ?- x相關的一些數字3 {, C8 W: ?* a" t' v9 S1 y
a) InnoDB留了兩個checkpoint filed,按照註釋的解釋,目的是為了能夠“write alternately”3 M3 W, g5 ~+ L% W) [0 A+ @/ i
b) 每個checkpint field需要的大小空間為304字節。(相關定義在log0log.h)
, |% N9 n! e3 S5 \  uc) 第一個checkpoint的起始位置在ib_logfile0的第512字節(OS_FILE_LOG_BLOCK_SIZE)處;
0 z% S. W& p0 T. R  C; t& Xd) 第二個在1536 (3 * OS_FILE_LOG_BLOCK_SIZE)字節處。
6 p9 o& [7 j- r4 T; e6 h) M$ V& `) N$ u* t# `4 Z6 I
( \; i8 n& q1 y5 R2 Q: U# }
特點:
+ Y) H( i, N( A/ oredo log只是記錄所有innodb表數據的變化。
2 q, \1 M% w7 u  Sredo log只是記錄正在執行中的dml以及ddl語句。) d) v- F. Z- D' s& Q
redo log可以作為異常down機或者介質故障後的數據恢復使用

引入一個問題:在m/s環境中,innodb寫完ib_logfile後,服務異常關閉,會不會主庫能用ib_logfile恢復數據,而binlog沒寫導致從庫同步時少了這個事務?從而導致主從不一致;redo日誌寫入方式:1.ib_logfile寫入當前事務更新數據,並標上事務準備trx_prepare2.寫入bin-log3.ib_logfile當前事務提交提交trx_commit恢復方式:如果ib_logfile已經寫入事務準備,那麽在恢復過程中,會依據bin-log中該事務是否存在恢復數據。假設:1)結束後異常,因沒有寫入bin-log,從庫不會同步這個事務,主庫上,重啟時,在恢復日誌中這個事務沒有commit,即rollback這個事務.2)結束後異常,這會bin-log已經寫入,從庫會同步這個事務。主庫依據恢復日誌和bin-log,也正常恢復此事務綜上描述:bin-log寫入完成,主從會正常完成事務;bin-log沒有寫入,主從庫rollback事務;不會出現主從庫不一致問題.
( E, f5 F8 ^7 W相關參數(全局&靜態):innodb_log_buffer_sizeinnodb_log_file_sizeinnodb_log_files_in_groupinnodb_log_group_home_dirinnodb_flush_log_at_trx_commitinnodb_log_buffer_size:事務日誌緩存區,可設置1M~8M,默認8M,延遲事務日誌寫入磁盤,把事務日誌緩存區想象形如"漏鬥"狀,會不停向磁盤記錄緩存的日誌記錄,而何時寫入通過參數innodb_flush_log_at_trx_commit控制,稍後解釋,啟用大的事務日誌緩存,可以將完整運行大事務日誌,
4 s# U* i0 C: e- n. q3 M7 D% n暫時存放在事務緩存區中,不必(事務提交前)寫入磁盤保存,同時也起到節約磁盤空間占用;innodb_log_file_size:控制事務日誌ib_logfile的大小,範圍5MB
~4G;所有事務日誌ib_logfile0+ib_logfile1+..累加大小不能超過4G,事務日誌大,checkpoint會少,節省磁盤IO,但是大的事務日誌意味著數據庫crash時,恢復起來較慢.引入問題:修改該參數大小,導致ib_logfile文件的大小和之前存在的文件大小不匹配解決方式:在幹凈關閉數據庫情況下,刪除ib_logfile,而後重啟數據庫,會自行創建該文件;innodb_log_files_in_group:DB中設置幾組事務日誌,默認是2;innodb_log_group_home_dir:事務日誌存放目錄,不設置,ib_logfile0...存在在數據文件目錄下innodb_flush_log_at_trx_commit:控制事務日誌何時寫盤和刷盤,安全遞增:0,2,1事務緩存區:log_buffer;0:每秒一次事務緩存區刷新到文件系統,同時文件系統到磁盤同步,但是事務提交時,不會觸發log_buffer到文件系統同步;2:每次事務提交時,會把事務緩存區日誌刷新到文件系統中去,且每秒文件系統到磁盤同步;1:每次事務提交時刷新到磁盤,最安全;適用環境:0:磁盤IO能力有限,安全方便較差,無復制或復制延遲可以接受,如日誌性業務,mysql損壞丟失1s事務數據;2:數據安全性有要求,可以丟失一點事務日誌,復制延遲也可以接受,OS損壞時才可能丟失數據;1:數據安全性要求非常高,且磁盤IO能力足夠支持業務,如充值消費,敏感業務;
: b: p. }% j5 Z  I: k
( K0 {& q* @' s

引入ib_logfile的寫入策略

1、基本概念3 B$ e8 V9 ]/ x* ?5 A: \
a)、ib_logfile文件個數由innodb_log_files_in_group配置決定,若為2,則在datadir目錄下有兩個文件,命令從0開始,分別為ib_logfile0和ib_logfile.: _( x% J. w" w) J$ u$ @
b)、文件為順序寫入,當達到最後一個文件末尾時,會從第一個文件開始順序復用。) P7 |' [. a0 B5 r) i
c)、lsn: Log Sequence Number,是一個遞增的整數。 Ib_logfile中的每次寫入操作都包含至少1個log,每個log都帶有一個lsn。在內存page修復過程中,只有大於page_lsn的log才會被使用。
7 z# ~- E, M' F1 c' P' p, Rd)、lsn的保存在全局變量log_sys中。遞增數值等於每個log的實際內容長度。即如果新增的一個log長度是len,則log_sys->lsn += len.( F1 K# R' R& J  \
e)、ib_logfile每次寫入以512(OS_FILE_LOG_BLOCK_SIZE)字節為單位。實際寫入函數 log_group_write_buf (log/log0log.c)
2 S$ m( `9 {% s% Y2 G' hf)、每次寫盤後是否flush,由參數innodb_flush_log_at_trx_commit控制。/ C! x* U' L# @/ Q* D% f  W

- v& P  Z( n' g- C4 N6 e4 u: H; m
2、log_sys介紹
' a' x9 X8 o7 jlog_sys是一個全局內存結構。以下說明幾個成員的意義。: P# w9 ]! X* n. K/ {% ]

lsn表示已經分配的最後一個lsn的值。
written_to_all_lsnn表示實際已經寫盤的lsn。需要這個值是因為並非每次生成log後就寫盤。
flushed_to_disk_lsn表示刷到磁盤的lsn。需要這個值是因為並非每次寫盤後就flush。
buf待寫入的內容保存在buf中
buf_sizebuf的大小。由配置中innodb_log_buffer_size決定,實際大小為innodb_log_buffer_size /16k * 16k。
buf_next_to_writebuf中下一個要寫入磁盤的位置
buf_freebuf中實際內容的最後位置。當buf_free> buf_next_to_write時,說明內存中還有數據未寫盤。


: Y# R* N- @: O, J- _2 i6 |4 K  |% u
! J$ h; O  p" d* X- e
3、相關更新- q5 Z. k, j8 T, }. R5 b0 R
用一個簡單的更新語句來說明log_sys以及ib_logfile的更新內容的過程。假設我們的更新只涉及到非索引的固定長度字段。
0 T* @* y1 T: Q0 K- e6 sa) 在bufferpool中寫入undo log。 對於一個單一的語句,需要先創建一個undolog頭。& ~! g# H' o0 n3 U. Q1 @/ a
b) 在bufferpool中寫入undo log的實際內容。
1 j' Z6 o; n3 h# U& \c) 在log_sys->buf中寫入buffer page的更新內容。此處保存了更新的完整信息。) J7 j5 n3 r8 I1 e  ?; B
d) 在log_sys->buf中寫入啟動事務(trx_prepare)的日誌( c  I1 t- O8 ?% i. B! j
e) 將c、d更新的log內容寫入ib_logfile中。" }& ~( Z, K- [1 j; y
f) 在log_sys->buf中寫入事務結束(trx_commit)的日誌
! ?" S9 A9 ]+ l! A: _/ N8 |2 p0 Q% \g) 將f步驟的log內容寫入ib_logfile中。  V, f/ |7 V3 ~0 K: M

1 ~1 e7 ~# S* a  Q1 g4、說明& o0 T- X- o, {" A& l% Z
a) 完成上述所有操作時,數據文件還沒有更新。
; {5 T2 S, T1 ]/ h6 }b) 每次寫入log_sys->buf時同時更新lsn和buf_free。 每次寫ib_logfile時同時更新written_to_all_lsn和buf_next_to_write;
& S6 M  |0 ], d5 }c) 每次寫ib_logfile時以512字節為對齊,如需寫入600字節,則實際寫入1k。寫到最後一個文件末尾則從第一個文件重復使用。; S3 q3 T" |+ a. z0 m. A& _1 ~
d) 從上述流程看到,在a~d過程中若出現異常關閉,由於沒有寫入到磁盤中,因此整個事務放棄;若在e剛完成時出現異常關閉,雖然事務內容已經寫盤,但沒有提交。在重啟恢復的時候,發現這個事務還沒有提交,邏輯上整個事務放棄。 (重啟日誌中會有Found 1 prepared transaction(s) in InnoDB字樣)。在g完成後出現異常關閉,則能夠在重啟恢復中正常提交。
, k) k* T3 C- r$ a, ^2 p
0 V5 `9 K2 S, K8 z; }0 g3 R$ q在e和f之間會寫mysql的bin-log,若bin-log寫完前異常關閉,事務無效,bin-log寫入成功後,則異常重啟後能夠根據bin-log恢復事務的修改。
, [) t1 K* W5 X8 Y7 B
# S( Y* Z7 |% F! d2 Ve) 若涉及到索引更新,在步驟c之後會增加索引更新的log。由於索引可能有merge過程,因此在merge過程中會另外增加寫入一個log。但事務完全提交仍在步驟g中。索引的更新由於已經寫盤,並不會因此丟失。

1

主题

0

回帖

12

积分

管理员

积分
12
QQ
 楼主| 发表于 2021-12-15 01:00:07 | 显示全部楼层
ib_logfile0 记录系统的回滚,重做日志。
5 e  e2 g8 e2 e8 z: y+ p
4 J- J6 V* z, ]7 dmysql-bin.000011 系统的所有更新记录。8 S' p5 @* q$ x; K! {9 D$ P
5 A2 t5 r3 }' A3 z9 N2 {

* b' |: n: Q& P7 \- m如果需要更详细的则建议看一下数据库原理方面的教材,应该有一个章节讲这个redo,undo 日志的。
( @7 U1 q: z9 U- q,ib_logfile0是重做日志,记录的是文件的物理更改         
! M! j% e% Y) e- Lmysql-bin.000011是数据库更新日志  记录的是逻辑更改
' A) Q# \5 {6 D, A. |
7 ]& {+ |1 T  _9 ]$ }& },
. M9 X4 @8 b. ]4 ~ib_logfile0是重做日志,也就是 在你修改数据之前,会先把 修改的操作 作为日志先记录下来。
! _. J/ I: W: M0 `- J6 u7 j) o        
. J; D/ n' N$ x; N+ v* a; W9 Emysql-bin.000011是二进制日志,格式是二进制的,但是这个日志更加有用,比如 在我们做 数据库的主从复制时,这个二进制日志就是关键,mysql会把日志发送到slave,salve会接收日志,然后解析日志,把里面的sql语句重新应用到数据库里,于是就能同步数据了。
  g: }, B  r1 S,ib_logfile0:记录的是redo log和undo log的信息,这里记录的基本是commit之前的数据。7 [1 M+ L. j' H$ P& F

- `7 U/ ^' Y' n* V' D% _- wmysql-bin.000011:记录的是已经执行完毕的对数据库的dml和ddl信息,这里记录的基本是commit之后的数据信息。
您需要登录后才可以回帖 登录 | 注册

本版积分规则

返回首页|Archiver|手机版|小黑屋|易陆发现技术论坛 ( 蜀ICP备2026014127号-1 )

GMT+8, 2026-6-12 00:18 , Processed in 0.054918 second(s), 29 queries .

Powered by Discuz! X5.0

© 2001-2026 Discuz! Team.

快速回复 返回顶部 返回列表