同じバージョンのサーバー間でMyISAMテーブル
をファイル レベルでコピーするだけです:変更されますが、5.0.52 から 5.1.45 へのコピーは有効です)。
競合状態に注意してください... データベースがテーブルを読み取っている間に、FTP またはその他のツールを使用してファイルにアクセスしている可能性があります。.MYI 内で更新されるテーブル「カウンター」があり、テーブルの読み取りが最も無害です。
ファイルレベルの操作に対して MyISAM テーブルの整合性を確保するには、次のようにします。
LOCK TABLE x WRITE;
FLUSH TABLE x; -- closes all file handles into table by mysql.
< perform file-level manipulations >
FLUSH TABLE x; -- A 'stat' of the table occurs and info-schema is updated appropriately.
UNLOCK TABLES;
テーブルをロック書き込みしない場合、ファイルレベルのコピー/操作を行っている間に mysql がテーブルにアクセス (読み取りまたは書き込み) する可能性があります。
これは、破損の心配なしに、外部ロックが無効になっている HOT データベースのテーブルに対して「myisampack」、「myisamchk」を許可するために使用されるのと同じメカニズムでもあります。
-- J・ジョーゲンソン --
a) mysql を確実にシャットダウンしている限り、同じバージョンのサーバー間で myisam ファイルを移動しても問題なく動作します (ただし、これは他のエンジンには当てはまりません)。一般に、異なるマイナー バージョン間で切り替えることもできます (保証はされていませんが)。
b) Debian から CentOS へは問題なく動作するはずです。一般に、複数の OS を使用する場合に発生する可能性がある唯一の問題は、異なるフォルダー構造 (ほとんどの Linux ディストリビューションでは問題にならない) か、エンディアンが異なる OS (最近では非常にまれな問題) だけです。
多分。詳しく説明します。
それらが同じマイナー バージョンであり、同一の my.cnf バージョンを持っている場合は YES。
はい、5.0 以降から別の 5.0 以降に移行し、同一の my.cnf を持っている場合
全文索引を使用していて、そのパラメータのいずれかがストップ ワードを含む異なる設定になっている場合は NO です (ヒント: 全文索引は使用しないでください)。
しかし、一般的なケースでは、いいえ、元のマシンとまったく同じ mysql バイナリを実行している場合にのみ、別のマシンに移動できると思います。他のことを計画している場合は、広範囲にテストしてください。形式の変更は微妙で、機能しているように見える場合があります (例: インデックス範囲スキャンで i18n 問題を引き起こす照合の微妙さ)。
my.cnf の内容は動作に影響を与え、既存のテーブル、特にフルテキスト インデックス作成を無効にする可能性があります。
新しいバージョンに移行することさえ困難でした。なぜなら、それは動作していると主張し、動作しているように見えますが、古い MyISAM バージョンは長期的には予期しない動作とクラッシュを引き起こすからです (ここでは、ビッグ データ セットでの数日間の持続的なシミュレートされた負荷について話している)。つまり、4.1 から 5 では、REPAIR TABLE を使用してデータ セット全体を移行する必要がありました。
myisam 形式の違いによって非互換性が生じる場合、REPAIR TABLE は常にそれらを修正します (ただし、mysql がテーブルをまったく読み取ることができる場合、たとえば 5.0 から 4.1 ではありません!)。
アップグレードを計画するときは、常にソーク/ストレス テストを実行してください。これにより、MySQL が認識していなかった問題が明らかになる可能性があります。
バージョンが異なる場合は、mysqldump テーブルだけを作成し、mysql を使用してそれらをインポートすることをお勧めします。
同じバージョンのMySql Serverを使用している場合、ファイルを移動してmysqlツールで確認できます。OSに問題はないと思います。ただし、mysql サーバーのバージョンは同じである必要があります。