今天要進行MySQL的數據遷移，所以把數據庫通過mydumper工具備份的文件解壓后。通過myloader進行導入

可是導入的時間出現這個報錯：

** (myloader:766): CRITICAL **: the specified directory is not a mydumper backup

很奇怪，明明以往導數據都是通過myloader命令能夠導入成功的，如今居然是報錯說這個文件夾不是mydumper的備份文件 查看myloader的源碼。例如以下 char *p= g_strdup_printf("%s/metadata", directory);if (!g_file_test(p, G_FILE_TEST_EXISTS)) {g_critical("the specified directory is not a mydumper backup\n");exit(EXIT_FAILURE);}
推斷文件夾下假設 metadata 文件不存在。則異常退出，而我發現備份文件夾下卻有一個 .metedata 文件，注意是有.前綴的。在linux系統下表示是隱藏文件
于是對照了一下mydumper的版本號： myloader -V myloader 0.6.2, built against MySQL 5.5.21
而原備份文件的機器是 myloader 0.2.3，表示兩個版本號不同樣， 所以我第一反應是把舊機器的 /usr/local/bin/文件夾下的 mydumper\myloader 文件直接cp到新機器
再用myloader的話，能夠導入成功。問題解決。

后面想了一下。再查看舊版本號的 myloader 源代碼，發現推斷文件是否存在是 .metadata ，即舊版本號導出的隱藏文件。在新版本號中已經不須要隱藏的。 可能是作者認為不是必需隱藏該文件，并且隱藏文件會有一個隱患是easy cp 不完整。cp默認不拷貝隱藏文件，必須通過 cp -a 才干完整拷貝。

所以。假設用myloader新版程序導入舊版本號的備份，能夠把備份文件夾下的 .metadata文件改名為?metadata。也能夠導入成功 mv .metadata metadata

總結

以上是生活随笔為你收集整理的关于mydumper的.metadata文件丢失的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。