MySQL重定位元據目錄的內容

mysql|資料|資料目錄     10 . 2節討論了在其預設配置中的資料目錄的結構。所有資料庫和狀態檔案都包含在其中。但是，在確定資料目錄內容的布局中管理員有某些職責。本節討論為什麼要移動資料目錄的各個部分（甚至是字典本身）、可以移動什麼，以及怎樣進行這些移動。
    MySQL允許您重定位其中的資料目錄或元素。這樣做有幾個原因：
    可以用比預設定位的檔案系統更大的容量在檔案系統中放置資料目錄。
    如果資料目錄在繁忙的磁碟上，可以將其放置到較少使用的磁碟機上，以平衡物理裝置之間的磁碟活動。為了類似的原因，可以將資料庫和記錄檔放在不同的磁碟機上，或在磁碟機之間對資料庫進行再分布。
    您可以運行多個伺服器，並且每個伺服器都有屬於自己的資料目錄。這是一種解決總進程檔案描述符限制問題的方法，尤其是當不能重新設定系統的核心以得到更高的限制值時。
    某些系統將PID 檔案儲存在諸如/var/run 的目錄中。為了系統運作的一致性，您可以將MySQLPID 檔案也放在那裡。

重定位方法

    有兩種對資料目錄重定位的方法：
    可以在命令列或在一個選項檔案的[mysqld] 組上，在伺服器啟動時間指定一個選項。
    可以移動要重定位的內容，然後在原始的位置中做一個指向新位置的s y m l i n k （symbolic link，符號連結）。
    兩種方法的任何一種都不能為您進行全部的重定位工作。表10-4 綜合了可重定位的內容以及可用於重定位的方法。如果您使用一個選項檔案，可以指定在全域選項檔案/ e t c / my.cnf（Windows中的c:\my.cnf）中的選項。當前的Windows 版本還訪問系統目錄（c:\windows 或c:\N T）。
    您還可以使用預設資料目錄的選項檔案my.cnf（該目錄編譯在伺服器中）。筆者不建議使用此檔案。如果要重定位元據目錄本身，必須保持預設資料目錄的完整性，以便在資料目錄中放置一個選項檔案，該檔案將說明伺服器應該在哪裡找到“真正”的資料目錄！真亂。如果想要用一個選項檔案來指定伺服器的選項，則最好使用/ e t c / my.cnf。


估計重定位的效果

    在試圖對任何東西進行重定位之前，檢驗該操作是否將具有所期望的效果是一個好主意。筆者傾向於用d u、df 和ls -l 命令來獲得磁碟空間資訊，但是所有的命令都依賴於對檔案系統布局的正確理解。
    以下例子將顯示出一個神秘的中斷以密切注意何時估計資料目錄的重定位。假定資料目錄是/ us r / l o c a l / v a r，並且想將其移動到/ v a r / mysql，因為df 指出該/var 檔案系統有較多的可用空間（如下例所示）：

    重定位的資料目錄能釋放/usr 檔案系統中多少空間？為了尋找空間數量，可使用du-s 來查看該目錄使用了多少空間：

    這大約為13 0 MB，應該對/usr 產生相當大的變化。但這是真的嗎？可在該資料目錄/ us r 中試一下df 命令：

    真奇怪。我們請求的是包含/usr/local/var 系統檔案的可用空間，可為什麼df 報告了v a r 的空間呢？下面的ls -l 做出了回答：

    該輸出結果表明/usr/local/var 是對/var/mysql的一個s y m l i n k。換句話說，資料目錄已經被重定位到/var 檔案系統中，並且用指向/var 檔案系統的symlink 所取代。有關通過移動資料目錄到/var 中來釋放大量的/usr 空間的工作就到此為止了！
    教訓：花幾分鐘的時間估計重定位的效果是一個有價值的投資。不用花很長的時間就會發現您可能不能達到自己的預期目標，這樣可以使您避免浪費大量的移動資料目錄的時間。

重定位元據目錄

    為了重定位元據目錄，應關閉伺服器，將資料目錄移動到新的位置。然後應該或者刪除原來的資料目錄並用指向新位置的symlink 來代替它，或者使用直接指明新位置的一個選項來重新啟動伺服器。表10 - 5列出了指定該位置的命令列和選項檔案的文法。


重定位元據庫

    資料庫只能通過symlink 方法來移動。為了重定位元據庫，應關閉伺服器，移動資料庫目錄。刪除原來的資料庫目錄，用指向新位置的symlink 來代替它，然後啟動伺服器。
    下面的例子說明怎樣將資料庫bigdb 移動到另一個位置：

    重定位的預防措施
    在執行任何重定位操作之前應該關閉伺服器，然後再重新啟動它。對有些類型的重定位（如移動資料庫目錄），保持伺服器的運行狀態是可能的（儘管不建議這樣做）。如果要這樣做，您必須確保伺服器沒有訪問將要移動的資料庫。還應該確保在移動資料庫之前發布了FLUSH TABLE 語句，以便確保伺服器關閉所有開啟的表檔案。不履行這些預防措施可能導致表的毀壞。
    應該以資料目錄所有者的身份來執行這些命令。為了安全起見，將原來的資料庫目錄重新命名為b i g db . o r i g。在驗證了伺服器與重定位服務器正常工作之後，可以刪除原來的目錄：
    % rm -rf bigdb.orig

重定位元據庫表

    對單個的表進行重定位不是好主意。可以通過將表的檔案移動到另一個位置並在該資料庫目錄中建立指向這些檔案的symlink 來進行。但是，如果曾經發布過ALTER TABLE 或OPTIMIZE TABLE 語句，則所做的這些修改將被取消。
    每個語句通過在資料庫目錄中建立一個實現變更和最佳化的暫存資料表進行操作，然後刪除原來的表，將該暫存資料表重新命名為原來的名稱。其結果是： symlink 被刪除，新的表回到資料庫目錄中，該目錄是您移動表之前的原始表所在位置。因此，移出該資料庫目錄的舊的表檔案仍然在原位置上─您甚至已經不記得它們的存在，但它們仍然佔用著空間。同樣，symlink 已經消失，因此，當您意識到所發生的一切時，如果已經不記得是在哪裡移動的，將沒有任何好辦法去捕捉這些檔案。
    要想確保訪問該表的任何人都不更改或最佳化該表是困難的（因而撤消任何企圖的重定位），因此最好保留該資料庫目錄中的這些表。

重定位狀態檔案

    可以用啟動選項重定位PID 檔案、常規日誌和更新日誌。錯誤記錄檔由safe_mysqld 建立且不能夠重定位（除非編輯s a f e _ mysqld）
    為了在另一個位置寫狀態檔案，應關閉伺服器，然後用指定新狀態檔案位置的恰當選項重新啟動它。表10 - 6列出了每個檔案的命令列和選項的文法。
    刪除一個重定位的資料庫
    您可以用DROP DATABASE 語句刪除一個資料庫，但是舊版本的MySQL在刪除已經重定位的資料庫時是有難度的。該資料庫中的表被正確地刪除了，但在伺服器試圖刪除該資料庫目錄時會出現錯誤，這是由於該目錄是一個symlink 而不是真正的目錄。MySQL管理員必須手工刪除該資料庫目錄和指向它的s y m l i n k。自MySQL3.23 以來，這個問題已經得到解決。

    如果以絕對路徑名指定一個狀態檔案的名稱，則用該路徑名建立該檔案。否則，該檔案在該資料目錄下建立。例如，如果您指定- -
pid - file = /var/run/mysqld.pid，則該PID 檔案為/ v a r / r un / mysqld . p i d。如果您指定-- pid - file = mysqld.pid ，則該PID 檔案為DATA D I R/ mysqld . p i d。
    如果指定一個沒有帶副檔名的更新日誌，則MySQL在開啟該更新日誌時將產生順序的名字。這些名字用. n n n 副檔名建立，這裡的.n n n是未被已有的更新記錄檔使用過的第一個號碼（如， up date . 0 0 1、up date . 0 0 2等等）。可以通過指定包含明確的副檔名來忽略順序名字的產生，然後伺服器將僅使用您指定的這個名字。