本文目錄一覽:
- 1、MYSQL複製data文件下的innodb引擎資料庫,提示1146錯誤,將原ibdata1拷到data文件夾下服務又起不來??
- 2、如何打開朋友傳過來的Mysql資料庫
- 3、MySQL所建的表拷到其他機器上打不開
- 4、MySQL資料庫打不開。
- 5、mysql不是安裝在默認路徑下,結果把在我電腦上建的資料庫拷到別的機器上就不能用,怎麼解決啊
- 6、拷回的mysql資料庫文件不能用
MYSQL複製data文件下的innodb引擎資料庫,提示1146錯誤,將原ibdata1拷到data文件夾下服務又起不來??
需要徹底停止MySQL的所有服務,才能拷貝ibdata1文件,否則MySQL的安全機制不允許。
如何打開朋友傳過來的Mysql資料庫
如何往裡面添加一個
字元型,長度為36
的欄位?a:你需要把那個shows.myd
所在的那個文件夾拷貝到mysql安裝目錄的data目錄下。
如果你是默認安裝,應該在c:\program
files\mysql\mysql
server
5.0\data\
注意是整個shows那些文件所在的目錄。連目錄一起拷貝哈。按你的描述,就應該是data目錄了。
將d:\data1\下的data目錄拷貝到c:\program
files\mysql\mysql
server
5.0\data\下面。
完成之後,重啟mysql看看,可以運行services.msc
在裡面找到mysql
重新啟動mysql。(前提是你安裝的時候配置了mysql服務,我想你應該配置了吧)
重啟之後
進入命令行,
然後mysql
-uroot
-p
進入mysql
show
databases;
看看能不能看到一個叫data資料庫。
如果能看到,恭喜你,
繼續下面的命令。
如果不行,看後面的方法b。
use
dataalter
table
shows
add
列名
類型
長度
等等舉例:增加一個int型名為id的列
alter
table
shows
add
id
int(11)
not
null
default
‘0’;
alter
table
shows
add
name
varchar(32)
not
null
default
”;
如果需要指定列的位置,假如加入的列在number列後面。那麼
alter
table
shows
add
id
int(11)
not
null
default
‘0’
after
number;方法b。
如果按之前說的文件拷貝方式,重啟進入mysql後看不到data
這個資料庫,那麼可能是你們的mysql版本不一致造成的,應該說這個可能性很大。
那麼,你讓你朋友給你導出資料庫內容。
用mysqldump命令。
mysqldump
-uroot
-p
-d
資料庫名.表名
sss.sql
你拿到這個sss.sql後
再把它導入到你的mysql資料庫。
在cmd下運行
mysql
-uroot
-p
testsss.sql或者在mysql命令行下運行use
testsource
sss.sql
這樣shows表就導入到你的test資料庫了。
剩下的就簡單了哈。和前面沒啥差別。
MySQL所建的表拷到其他機器上打不開
在資料庫表丟失或損壞的情況下,備份你的資料庫是很重要的。如果發生系統崩潰,你肯定想能夠將你的表儘可能丟失最少的數據恢復到崩潰發生時的狀態。有時,正是MySQL管理員造成破壞。管理員已經知道表以破壞,用諸如vi或Emacs等編輯器試圖直接編輯它們,這對錶絕對不是件好事!
備份資料庫兩個主要方法是用mysqldump程序或直接拷貝資料庫文件(如用cp、cpio或tar等)。每種方法都有其優缺點:
mysqldump與MySQL伺服器協同操作。直接拷貝方法在伺服器外部進行,並且你必須採取措施保證沒有客戶正在修改你將拷貝的表。如果你想用文件系統備份來備份資料庫,也會發生同樣的問題:如果資料庫表在文件系統備份過程中被修改,進入備份的表文件主語不一致的狀態,而對以後的恢復表將失去意義。文件系統備份與直接拷貝文件的區別是對後者你完全控制了備份過程,這樣你能採取措施確保伺服器讓表不受干擾。
mysqldump比直接拷貝要慢些。
mysqldump生成能夠移植到其它機器的文本文件,甚至那些有不同硬體結構的機器上。直接拷貝文件不能移植到其它機器上,除非你正在拷貝的表使用MyISAM存儲格式。ISAM表只能在相似的硬體結構的機器上拷貝。在MySQL 3.23中引入的MyISAM表存儲格式解決了該問題,因為該格式是機器無關的,所以直接拷貝文件可以移植到具有不同硬體結構的機器上。只要滿足兩個條件:另一台機器必須也運行MySQL 3.23或以後版本,而且文件必須以MyISAM格式表示,而不是ISAM格式。
不管你使用哪種備份方法,如果你需要恢復資料庫,有幾個原則應該遵守,以確保最好的結果:
定期實施備份。建立一個計劃並嚴格遵守。
讓伺服器執行更新日誌。當你在崩潰後需要恢複數據時,更新日誌將幫助你。在你用備份文件恢複數據到備份時的狀態後,你可以通過運行更新日誌中的查詢再次運用備份後面的修改,這將資料庫中的表恢復到崩潰發生時的狀態。
以文件系統備份的術語講,資料庫備份文件代表完全傾倒(full dump),而更新日誌代表漸進傾倒(incremental dump)。
使用一種統一的和易理解的備份文件命名機制。象backup1、buckup2等不是特別有意義。當實施你的恢復時,你將浪費時間找出文件里是什麼東西。你可能發覺用資料庫名和日期構成備份文件名會很有用。例如:
%mysqldump samp_db /usr/archives/mysql/samp_db.1999-10-02
%mysqldump menagerie /usr/archives/mysql/menagerie.1999-10-02
你可能想在生成備份後壓縮它們。備份一般都很大!你也需要讓你的備份文件有過期期限以避免它們填滿你的磁碟,就象你讓你的日誌文件過期那樣。
用文件系統備份備份你的備份文件。如果遇上了一個徹底崩潰,不僅清除了你的數據目錄,也清除了包含你的資料庫備份的磁碟驅動器,你將真正遇上了麻煩。也要備份你的更新日誌。
將你的備份文件放在不同於用於你的資料庫的文件系統上。這將降低由於生成備份而填滿包含數據目錄的文件系統的可能性。
用於創建備份的技術同樣對拷貝資料庫到另一台機器有用。最常見地,一個資料庫被轉移到了運行在另一台主機上的伺服器,但是你也可以將數據轉移到同一台主機上的另一個伺服器。
1、使用mysqldump備份和拷貝資料庫
當你使用mysqldumo程序產生資料庫備份文件時,預設地,文件內容包含創建正在傾倒的表的CREATE語句和包含表中行數據的INSERT語句。換句話說,mysqldump產生的輸出可在以後用作mysql的輸入來重建資料庫。
你可以將整個資料庫傾倒進一個單獨的文本文件中,如下:
%mysqldump samp_db /usr/archives/mysql/samp_db.1999-10-02
輸出文件的開頭看起來象這樣:
# MySQL Dump 6.0
#
# Host: localhost Database: samp_db
#—————————————
# Server version 3.23.2-alpha-log
#
# Table structure for table ‘absence’
#
CREATE TABLE absence(
student_id int(10) unsigned DEFAULT ‘0’ NOT NULL,
date date DEFAULT ‘0000-00-00’ NOT NULL,
PRIMARY KEY (student_id,date)
);
#
# Dumping data for table ‘absence’
#
INSERT INTO absence VALUES (3,’1999-09-03′);
INSERT INTO absence VALUES (5,’1999-09-03′);
INSERT INTO absence VALUES (10,’1999-09-08′);
……
文件剩下的部分有更多的INSERT和CREATE TABLE語句組成。
如果你想壓縮備份,使用類似如下的命令:
%mysqldump samp_db | gzip /usr/archives/mysql/samp_db.1999-10-02.gz
如果你要一個龐大的資料庫,輸出文件也將很龐大,可能難於管理。如果你願意,你可以在mysqldump命令行的資料庫名後列出單獨的表名來傾到它們的內容,這將傾倒文件分成較小、更易於管理的文件。下例顯示如何將samp_db資料庫的一些表傾到進分開的文件中:
%mysqldump samp_db student score event absence grapbook.sql
%mysqldump samp_db member president hist-league.sql
如果你生成準備用於定期刷新另一個資料庫內容的備份文件,你可能想用–add-drop-table選項。這告訴伺服器將DROP TABLE IF EXISTS語句寫入備份文件,然後,當你取出備份文件並把它裝載進第二個資料庫時,如果表已經存在,你不會得到一個錯誤。
如果你倒出一個資料庫以便能把資料庫轉移到另一個伺服器,你甚至不必創建備份文件。要保證資料庫存在於另一台主機,然後用管道傾倒資料庫,這樣mysql能直接讀取mysqldump的輸出。例如:你想從主機pit-viper.snake.net拷貝資料庫samp_db到boa.snake.net,可以這樣很容易做到:
%mysqladmin -h boa.snake.net create samp_db
%mysqldump samp_db | mysql -h boa.snake.net samp_db
以後,如果你想再次刷新boa.snake.net上的資料庫,跳過mysqladmin命令,但要對mysqldump加上–add-drop-table以避免的得到表已存在的錯誤:
%mysqldump –add-drop-table samp_db | mysql -h boa.snake.net samp_db
mysqldump其它有用的選項包括:
–flush-logs和–lock-tables組合將對你的資料庫檢查點有幫助。–lock-tables鎖定你正在傾倒的所有表,而–flush-logs關閉並重新打開更新日誌文件,新的更新日誌將只包括從備份點起的修改資料庫的查詢。這將設置你的更新日誌檢查點位備份時間。(然而如果你有需要執行個更新的客戶,鎖定所有表對備份期間的客戶訪問不是件好事。)
如果你使用–flush-logs設置檢查點到備份時,有可能最好是傾倒整個資料庫。如果你傾倒單獨的文件,較難將更新日誌檢查點與備份文件同步。在恢復期間,你通常按資料庫為基礎提取更新日誌內容,對單個表沒有提取更新的選擇,所以你必須自己提取它們。
預設地,mysqldump在寫入前將一個表的整個內容讀進內存。這通常確實不必要,並且實際上如果你有一個大表,幾乎是失敗的。你可用–quick選項告訴mysqldump只要它檢索出一行就寫出每一行。為了進一步優化傾倒過程,使用–opt而不是–quick。–opt選項打開其它選項,加速數據的傾倒和把它們讀回。
用–opt實施備份可能是最常用的方法,因為備份速度上的優勢。然而,要警告你,–opt選項確實有代價,–opt優化的是你的備份過程,不是其他客戶對資料庫的訪問。–opt選項通過一次鎖定所有表阻止任何人更新你正在傾倒的任何錶。你可在一般資料庫訪問上很容易看到其效果。當你的資料庫一般非常頻繁地使用,只是一天一次地調節備份。
一個具有–opt的相反效果的選項是–dedayed。該選項使得mysqldump寫出INSERT DELAYED語句而不是INSERT語句。如果你將數據文件裝入另一個資料庫並且你想是這個操作對可能出現在該資料庫中的查詢的影響最小,–delayed對此很有幫助。
–compress選項在你拷貝資料庫到另一台機器上時很有幫助,因為它減少網路傳輸位元組的數量。下面有一個例子,注意到–compress對與遠端主機上的伺服器通信的程序才給出,而不是對與本地主機連接的程序:
%mysqldump –opt samp_db | mysql –compress -h boa.snake.net samp_db
mysqldump有很多選項,詳見《MySQL參考手冊》。
2、使用直接拷貝資料庫的備份和拷貝方法
另一種不涉及mysqldump備份資料庫和表的方式是直接拷貝資料庫表文件。典型地,這用諸如cp、tar或cpio實用程序。本文的例子使用cp。
當你使用一種直接備份方法時,你必須保證表不在被使用。如果伺服器在你則正在拷貝一個表時改變它,拷貝就失去意義。
保證你的拷貝完整性的最好方法是關閉伺服器,拷貝文件,然後重啟伺服器。如果你不想關閉伺服器,要在執行表檢查的同時鎖定伺服器。如果伺服器在運行,相同的制約也適用於拷貝文件,而且你應該使用相同的鎖定協議讓伺服器「安靜下來」。
假設伺服器關閉或你已經鎖定了你想拷貝的表,下列顯示如何將整個samp_db資料庫備份到一個備份目錄(DATADIR表示伺服器的數據目錄):
%cd DATADIR
%cp -r samp_db /usr/archive/mysql
單個表可以如下備份:
%cd DATADIR/samp_db
%cp member.* /usr/archive/mysql/samp_db
%cp score.* /usr/archive/mysql/samp_db
….
當你完成了備份時,你可以重啟伺服器(如果關閉了它)或釋放加在表上的鎖定(如果你讓伺服器運行)。
要用直接拷貝文件把一個資料庫從一台機器拷貝到另一台機器上,只是將文件拷貝到另一台伺服器主機的適當數據目錄下即可。要確保文件是MyIASM格式或兩台機器有相同的硬體結構,否則你的資料庫在另一台主機上有奇怪的內容。你也應該保證在另一台機器上的伺服器在你正在安裝資料庫表時不訪問它們。
3、複製資料庫(Replicating Database)
複製(Replication)類似於拷貝資料庫到另一台伺服器上,但它的確切含義是實時地保證兩個資料庫的完全同步。這個功能將在3.23版中出現,而且還不很成熟,因此本文不作詳細介紹。
4、用備份恢複數據
資料庫損壞的發生有很多原因,程度也不同。如果你走運,你可能僅損壞一兩個表(如掉電),如果你倒霉,你可能必須替換整個數據目錄(如磁碟損壞)。在某些情況下也需要恢復,比如用戶錯誤地刪除了資料庫或表。不管這些倒霉事件的原因,你將需要實施某種恢復。
如果表損壞但沒丟失,嘗試用myisamchk或isamchk修復它們,如果這樣的損壞可有修復程序修復,你可能根本不需要使用備份文件。關於表修復的過程,見《資料庫維護與修復》。
恢復過程涉及兩種信息源:你的備份文件和個更新日誌。備份文件將表恢復到實施備份時的狀態,然而一般表在備份與發生問題之間的時間內已經被修改,更新日誌包含了用於進行這些修改的查詢。你可以使用日誌文件作為mysql的輸入來重複查詢。這已正是為什麼要啟用更新日誌的原因。
恢復過程視你必須恢復的信息多少而不同。實際上,恢復整個資料庫比單個表跟容易,因為對於資料庫運用更新日誌比單個表容易。
4.1 恢復整個資料庫
首先,如果你想恢復的資料庫是包含授權表的mysql資料庫,你需要用–skip-grant-table選項運行伺服器。否則,它會抱怨不能找到授權表。在你已經恢復表後,執行mysqladmin flush-privileges告訴伺服器裝載授權標並使用它們。
將資料庫目錄內容拷貝到其它某個地方,如果你在以後需要它們。
用最新的備份文件重裝資料庫。如果你用mysqldump產生的文件,將它作為mysql的輸入。如果你用直接從資料庫拷貝來的文件,將它們直接拷回資料庫目錄,然而,此時你需要在拷貝文件之前關閉資料庫,然後重啟它。
使用更新日誌重複做備份以後的修改資料庫表的查詢。對於任何可適用的更新日誌,將它們作為mysql的輸入。指定–one-database選項使得mysql只執行你有興趣恢復的資料庫的查詢。如果你知道你需要運用所有更新日誌文件,你可以在包含日誌的目錄下使用這條命令:
% ls -t -r -1 update.[0-9]* | xargs cat | mysql –one-database db_name
ls命令生成更新日誌文件的一個單列列表,根據伺服器產生它們的次序排序(主意:如果你修改任何一個文件,你將改變排序次序,這導致更新日誌一錯誤的次序被運用。)
很可能你會是運用某幾個更新日誌。例如,自從你備份以來產生的更新日誌被命名為update.392、update.393等等,你可以這樣重新運行:
%mysql –one-database db_name update.392
%mysql –one-database db_name update.393
…..
如果你正在實施恢復且使用更新日誌恢復由於一個錯誤建議的DROP DATABASE、DROP TABLE或DELETE語句造成丟失的信息,在運用更新日誌之前,要保證從其中刪除這些語句。
4.2 恢復單個表
恢復單個表較為複雜。如果你用一個由mysqldump生成的備份文件,並且它不包含你感興趣的表的數據,你需要從相關行中提取它們並將它們用作mysql的輸入。這是容易的部分。難的部分是從只運用於該表的更新日誌中拉出片斷。你會發覺mysql_find_rows實用程序對此很有幫助,它從更新日誌中提取多行查詢。
另一個可能性是使用另一台伺服器恢復整個資料庫,然後拷貝你想要的表文件到原資料庫中。這可能真的很容易!當你將文件拷回資料庫目錄時,要確保原資料庫的伺服器關閉
MySQL資料庫打不開。
添加mysql安裝路徑。首先右鍵單擊「我的電腦(wind7是「計算機」)」—「屬性」–“高級系統設置”,彈出「系統屬性」界面
單擊「環境變數」,彈出「環境變數」窗口,如圖
找到「系統變數」下的「path」,選中path,點擊編輯,在path中加入mysql的安裝路徑,我的是d:\program
files\mysql\mysql
server
5.1\bin,故在path末尾加入d:\program
files\mysql\mysql
server
5.1\bin路徑。最後「確定」保存。
有時是mysql沒許可權讀取你指定導入盤符的許可權。這時我們打開dos命令窗口,找到「運行」鍵入「cmd」命令
mysql沒許可權讀取你指定導入盤符的許可權時,我們把sql文件放在temp目錄下(linux在/tmp,windows在c:/windows/temp),這個目錄默認所有用戶都可以讀取的。
最後打開dos窗口,鍵入
mysql安裝路徑mysql
-u用戶名
-p密碼
,啟動mysql。再鍵入命令
mysqlsource
盤符:\導入的資料庫名.sql,即可導入mysql資料庫。
mysql不是安裝在默認路徑下,結果把在我電腦上建的資料庫拷到別的機器上就不能用,怎麼解決啊
這個MYSQL有不同版本的,直接拷貝DATA文件夾裡面的文件去別人,可能高版本的會兼容;還有如果直接導出資料庫.sql,這樣一般可以的,不行的話就用命令行來恢復,我在伺服器上移動資料庫也碰到過這個問題。
拷回的mysql資料庫文件不能用
如果從庫上表 t 數據與主庫不一致,導致複製錯誤,整個庫的數據量很大,重做從庫很慢,如何單獨恢復這張表的數據?通常認為是不能修復單表數據的,因為涉及到各表狀態不一致的問題。下面就列舉備份單表恢復到從庫會面臨的問題以及解決辦法:
場景 1
如果複製報錯後,沒有使用跳過錯誤、複製過濾等方法修復主從複製。主庫數據一直在更新,從庫數據停滯在報錯狀態(假設 GTID 為 aaaa:1-100)。
修復步驟:
在主庫上備份表 t (假設備份快照 GTID 為 aaaa:1-10000);
恢復到從庫;
啟動複製。
這裡的問題是複製起始位點是 aaaa:101,從庫上表 t 的數據狀態是領先其他表的。aaaa:101-10000 這些事務中只要有修改表 t 數據的事務,就會導致複製報錯 ,比如主鍵衝突、記錄不存在(而 aaaa:101 這個之前複製報錯的事務必定是修改表 t 的事務)
解決辦法:啟動複製時跳過 aaaa:101-10000 這些事務中修改表 t 的事務。
正確的修復步驟:
1. 在主庫上備份表 t (假設備份快照 GTID 為 aaaa:1-10000),恢復到從庫;
2. 設置複製過濾,過濾表 t:
CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE = (‘db_name.t’);
3. 啟動複製,回放到 aaaa:10000 時停止複製(此時從庫上所有表的數據都在同一狀態,是一致的);
START SLAVE UNTIL SQL_AFTER_GTIDS = ‘aaaa:10000’;
4. 刪除複製過濾,正常啟動複製。
注意事項:這裡要用 mysqldump –single-transaction –master-data=2,記錄備份快照對應的 GTID
場景 2
如果複製報錯後,使用跳過錯誤、複製過濾等辦法修復了主從複製。主、從庫數據一直在更新。
修復步驟:
在主庫上備份表 t (假設備份快照 GTID為 aaaa:1-10000);
停止從庫複製,GTID為 aaaa:1-20000;
恢復表 t 到從庫;
啟動複製。
這裡的問題是複製起始位點是 aaaa:20001,aaaa:10000-20000 這些事務將不會在從庫上回放,如果這裡面有修改表 t 數據的事務,從庫上將丟失這部分數據。
解決辦法:從備份開始到啟動複製,鎖定表 t,保證 aaaa:10000-20000 中沒有修改表 t 的事務。
正確修復步驟:
對錶 t 加讀鎖;
在主庫上備份表 t;
停止從庫複製,恢復表 t;
啟動複製;
解鎖表 t。
如果是大表,這裡可以用可傳輸表空間方式備份、恢復表,減少鎖表時間。
原創文章,作者:小藍,如若轉載,請註明出處:https://www.506064.com/zh-tw/n/284653.html