レプリケートされたmysql構造内のRENAME TABLEのリスクは何ですか？

Question

サイト検索のために最適化されたmysqlテーブルの更新版を作成するcronスクリプトがあります。

サイトの検索に使用されているテーブルはcronジョブがwrkSearch新しいテーブルを作成し、それがテーブルを移入するために完了したとき がtblSearchをドロップしwrkSearch （両方の名前を変更終了tblSearch
と呼ばれていますテーブルはMySamエンジン）

DROP TABLE IF EXISTS `tblSearch 
RENAME TABLE `wrkSearch` TO tblSearch 

これは正常に動作している必要がありますが、私はこの問題への良いアプローチであるかどうかを知りたいのです。
私は例えば...あなたの考慮事項が変更された場合、テーブルのサイズに基づいて知っていると思います：

を「非常に大きなテーブルが引き起こすために...解決策は危険かもしれない」私はあることに変化しているすべてのクエリを知っていますmysqlテーブル内の何かがファイルシステム上に物事を書いています...しかし、UPDATE/INSERTの代わりにRENAMEを実行することにはいくつかの違いがありますか？私は、ファイルシステムに対するRENAMEコマンドがaggresiveであるかどうかを理解しようとしています。

テーブルの上にもう一つの要素は、TEデータベースはMASTER-SLAVE構造と複製されているという事実である...ので、私もこれが最終的にRENAMEクエリ

別の背後にあるリスクをincraseことができれば知りたいです私にとって重要な側面は、使用されるシステムリソースの量です... RENAME操作はUPDATE/INSERTよりも貪欲である可能性がありますか？

Answer 1

リネーム自体は超高速です。テーブルからすべてを削除して、それを新しく作成する場合、このメソッドは問題ありません。 （実際に正しく複製されていることを確認してください）

しかし、複製に関しては、テーブルの全データを送信する必要があることを意味します。

可能であれば、テーブル内のデータを更新する方がいいです。つまり、データの一部だけが変更され、すべてではありません。

私は、このタイプの操作は正当な理由があると批判されます。しかし、すべてのルールのように、時々あなたはそれらを壊さなければなりません。

Answer 2

注文を変更する必要があります。最初のドロップよりも、名前を変更します。

RENAME TABLE tlbSearch TO tblSearchDropMe, wrkSearch TO tlbSearch; 
DROP TABLE tblSearchDropMe; 

をRENAMEがアトミックであるので、いくつかの他のプロセスが今までtblSearchへのアクセスに失敗する方法はありません。最初に削除するときに名前を変更することがあります。

これ以外に、これに関するレプリケーションに関連する問題はありません。