X3.5報(bào)錯(cuò)iscuz! Database Error Time: 2025-07-09 09:10:31 +0000 IP: 106.114.19.94 BackTraceID: 59cb452e586e4b2051a78baead4af84b (1146)

q18341427

Discuz! Database Error

Time: 2025-07-09 09:10:31 +0000 IP: 106.114.19.94 BackTraceID: 59cb452e586e4b2051a78baead4af84b

(1146) Table 'doutaoziyuan.common_syscache' doesn't existSELECT * FROM common_syscache WHERE `cname` IN('announcements','onlinelist','forumlinks','heats','historyposts','onlinerecord','userstats','diytemplatenameforum','plugin','pluginlanguage_system','setting','style_default','cronnextrun')

PHP Debug



直接打包的數(shù)據(jù)庫(kù)文件 恢復(fù)就成這樣了！?。。。。。?！

環(huán)境：windows Server 2008  R2  寶塔8.2.2

數(shù)據(jù)庫(kù)版本：MySQL5.6

PHP版本：7.4

打開(kāi)數(shù)據(jù)庫(kù)顯示數(shù)據(jù)庫(kù)中沒(méi)有表。

1 貢獻(xiàn)

最佳答案

可以聯(lián)系我嘗試處理恢復(fù)數(shù)據(jù)

• 耗子
• 發(fā)表于2025-7-13 23:16:24
• 詳細(xì)答案 >

湖中沉

common_syscache表不見(jiàn)了，你干了什么導(dǎo)致數(shù)據(jù)表都沒(méi)了？
按照你說(shuō)的打包恢復(fù)數(shù)據(jù)，你怎么打包的？mysql的innodb可不是把數(shù)據(jù)文件復(fù)制過(guò)去就能用的，這完全是錯(cuò)誤的方法

q18341427

X3.4都是直接打包的數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)這樣直接放進(jìn)去正常，就這一個(gè)站這樣?。。。。。?！

恢復(fù)之前打包的的數(shù)據(jù)庫(kù)也提示這個(gè)錯(cuò)誤?。。。?！

X3.5不能直接打包的么？

q18341427

湖中沉 發(fā)表于 2025-7-9 17:30
common_syscache表不見(jiàn)了，你干了什么導(dǎo)致數(shù)據(jù)表都沒(méi)了？
按照你說(shuō)的打包恢復(fù)數(shù)據(jù)，你怎么打包的？mysql的i ...

X3.4一直都這樣備份的正常的

湖中沉

q18341427 發(fā)表于 2025-7-9 17:30
X3.4都是直接打包的數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)這樣直接放進(jìn)去正常，就這一個(gè)站這樣?。。。。。?！

恢復(fù)之前打包的的數(shù) ...

X3.4這樣操作也是不對(duì)的，且這和X3.4還是X3.5無(wú)關(guān)，而和mysql的數(shù)據(jù)引擎有關(guān)，X3.5開(kāi)始使用的是innodb引擎。

數(shù)據(jù)備份正確的方法從來(lái)不是復(fù)制文件，而是用數(shù)據(jù)管理軟件導(dǎo)出備份。以前錯(cuò)誤的方法勉強(qiáng)沒(méi)出錯(cuò)，不代表是正確的方式

q18341427

湖中沉 發(fā)表于 2025-7-9 17:32
X3.4這樣操作也是不對(duì)的，且這和X3.4還是X3.5無(wú)關(guān)，而和mysql的數(shù)據(jù)引擎有關(guān)，X3.5開(kāi)始使用的是innodb引 ...

好幾個(gè)站呢！?。。?！

X3.4一直這樣直接打包 恢復(fù)多少次了 ！

3.5的第一次恢復(fù) 就這樣了

大佬！還有解決辦法么？

天外飄仙

q18341427 發(fā)表于 2025-7-9 17:30
X3.4都是直接打包的數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)這樣直接放進(jìn)去正常，就這一個(gè)站這樣?。。。。。?！

恢復(fù)之前打包的的數(shù) ...

X3.5 不能這樣打包數(shù)據(jù)庫(kù)的!

要導(dǎo)出SQL 文件 再 導(dǎo)入恢復(fù), 或者是 用dz后臺(tái)的 數(shù)據(jù)庫(kù)備份恢復(fù)功能

q18341427

天外飄仙 發(fā)表于 2025-7-9 17:37
X3.5 不能這樣打包數(shù)據(jù)庫(kù)的!

要導(dǎo)出SQL 文件 再 導(dǎo)入恢復(fù), 或者是 用dz后臺(tái)的 數(shù)據(jù)庫(kù)備份恢復(fù)功能 ...

原備份文件全這這樣打包的，還有解決辦法么？  

天外飄仙

q18341427 發(fā)表于 2025-7-9 17:40
原備份文件全這這樣打包的，還有解決辦法么？

修復(fù)倒是可以, 但是代價(jià)會(huì)比較大;

原服務(wù)器 數(shù)據(jù)已經(jīng)不在了嗎?  建議直接到 原服務(wù)器 重新備份數(shù)據(jù)庫(kù)呢;

q18341427

天外飄仙 發(fā)表于 2025-7-9 18:31
修復(fù)倒是可以, 但是代價(jià)會(huì)比較大;

原服務(wù)器 數(shù)據(jù)已經(jīng)不在了嗎?  建議直接到 原服務(wù)器 重新備份數(shù)據(jù)庫(kù)呢; ...

原服務(wù)器硬盤(pán)報(bào)廢了