私は現在、mysql/php を実行している Web サイトを持つ会社で働いています (すべてのテーブルも MYISAM テーブル タイプを使用しています)。
レプリケーションを実装したいのですが、バイナリログへの書き込みを行うときにテーブルがロックされることをmysqlのドキュメントやインターネット上の他の場所で読みました（スレーブデータベースは最終的にそこから読み取ります）。
これらのロックは、かなり書き込みが多いライブ サイトで問題を引き起こしますか? また、テーブルをロックせずにレプリケーションを有効にする方法はありますか?
テーブル タイプを innodb に変更すると、行レベルのロックが使用されます。また、更新がトランザクションになるため、レプリケーションがより安定します。MyISAM のレプリケーションは長期的な苦痛です。
サーバーのバージョンが一致していることを確認し、スレーブをシャットダウンする前に必ずマスターをシャットダウンしてください。スレーブをシャットダウンした直後にマスターを再起動できますが、マスターを停止する必要があります。
また、InnoDB に適切な autoextend オプションを使用していることを確認してください。そして、それに取り組んでいる間に、float と double から 'decimal' (これは mysql 5.1 を意味します) に移行したいと思うでしょう。
それはおそらくあなたが求めたよりも少し多いです. 楽しみ。
追伸、はい、myisam ロックは問題を引き起こす可能性があります。また、myisam が大量の選択をブロックしていない限り、innodb は myisam よりも低速です。
私の経験では、書き込みの多いサイトでDBAを実行すると、バイナリログを書き込むことで、マスターのロックやパフォーマンスに関する認識できる問題は発生しません。ベンチマークを行う場合は、バイナリロギングをオンにするだけです。バイナリログにクエリを書き込むためにテーブルがロックされているとは本当に思いません。
ただし、スレーブでのテーブルロックはまったく別のものです。レプリケーションはシリアルです。各クエリは、スレーブが次のクエリを実行する前に完了するまで実行されます。更新が長すぎると、レプリケーションが一時的に遅れます。アプリケーションがスケールアウトにレプリケーションを使用する場合は、これに対応する方法を知っている必要があります。
myisam テーブル タイプを使用したソリューションは「優れた」ものではありません。しかし、あなたはそれでやり遂げることができます。
できる最善の方法は、スレーブとマスターが同じハードウェアで実行されていることを確認し (FPU の違いによりレプリケーション エラーが発生する可能性があります)、MySQL サーバーで同じバージョン番号を実行していることを確認することです。
次のリンクはあなたの質問に答えます。具体的には、MyISAM テーブルのロックは、削除が行われていない場合、書き込みをブロックする可能性が低くなります。そのため、削除ホールのないテーブルは、レプリケートされたセットアップでより高速に実行されます。
http://dev.mysql.com/doc/refman/5.1/en/internal-locking.html
スケジュールされたダウンタイム中 (特に大量削除後) に定期的に DBA エクスポート/インポートを行うことで、「ホール」の影響を軽減できます。また、マスターがまだ実行されている状態でスレーブ データベースがダウンしないようにしてください。これにより、多くの問題を解決できます。