マスターサーバーでtx_isolationとbinlog形式を変更する-スレーブも調整する必要がありますか？
DrupalコマースサイトでMariaDB10.0とマスター/スレーブレプリケーションを実行しています。アプリケーションの動作方法が原因で、高負荷で大量のデッドロックが発生することになります。どうやらこれは大規模なDrupalコマースサイトでかなり一般的な問題。
テストサーバー（マスター/スレーブではなくスタンドアロン）で2つの設定を変更することをテストしました。これにより、デッドロックの問題が解消されました。
transaction-isolation = READ-COMMITTED
binlog_format = ROW
私の質問は次のとおりです。
1）この変更を本番マスター/スレーブのセットアップに適用する場合、これをマスターとスレーブの両方に適用する必要がありますか、それともマスターのみに適用する必要がありますか？
2）何かをするために必要な特別なシーケンスはありますか？または、my.cnfを調整してmariadbを再起動できますか？
3）この変更を適用している間、「スレーブを停止」する必要がありますか？
ホスティングプロバイダーのシニアDBAの1人から返ってきた回答は次のとおりです。他の誰かがこれに遭遇した場合に備えて、私は共有しています。
一般に、スレーブでマスターと同じ設定を行うことが非常に重要です。簡単な理由は、これを推奨するのは、いつかそのスレーブをマスターするように昇格させ、驚きを望まないからです。これには他にも技術的な理由があるので、スレーブは同じ設定を使用することをお勧めします（server-idとおそらくログファイルの名前を除いて）
技術的には再起動せずに動的に設定を変更できますが、既存の接続は古い設定を使用し、再起動はすべてのセッションを更新して新しいバイナリログ形式を使用するように強制的に切断するよりも高速であるため、正しく行うのはかなり難しいです。次に、tx分離を使用してプロセスを繰り返します（これは、ご使用の環境に存在しない可能性のある長期間の接続では重要です）
スレーブとマスターのmy.cnfに設定を追加してから、任意の順序で再起動することをお勧めします。 「スレーブの停止」または「スレーブの開始」を手動で実行する必要はありません。
スレーブにはバイナリログオンもlog-slave-updatesもないため、管理する操作の順序については特に何もありません。
要点をまとめると：
1）この変更を本番マスター/スレーブのセットアップに適用する場合、これをマスターとスレーブの両方に適用する必要がありますか、それともマスターのみに適用する必要がありますか？
両方とも、主にスレーブを驚かずにマスターに昇格させることができます。
2）何かをするために必要な特別なシーケンスはありますか？または、my.cnfを調整してmariadbを再起動できますか？
実際にはそうではありません。設定を調整して任意の順序で再起動するだけです。
3）この変更を適用している間、「スレーブを停止」する必要がありますか？
番号