mysqlでUnsafe statement written to the binary log using statement の警告が出た時の対処

この方法が最も用いられている対処方法だと思います。
単純に バイナリログフォーマットを statement → mixed へ変更する方法です。

1. 全てのスレーブ側サーバーでスレーブを停止する
   

   mysql> STOP SLAVE;

2. マスターサーバーにて、に対して、更新系クエリをロック（一時停止）するして更新系のクエリを止める
   

   mysql> FLUSH TABLES WITH READ LOCK;

3. マスターサーバーにて、ログファイルの再オープンを実施する
   

   mysql> FLUSH LOGS;

   全てのログ ファイルを閉じ、再オープンします。もしバイナリ ログが有効であれば、バイナリ ログ ファイルのシーケンス番号は前のファイルと比較して1つ増加されます。

4. マスターサーバーにて、ログフォーマットを mixed へ変更する
   

   mysql> SET GLOBAL binlog_format = 'mixed';

5. マスターサーバーにて、ログファイルの再オープンを実施する
   

   mysql> FLUSH LOGS;

   全てのログ ファイルを閉じ、再オープンします。もしバイナリ ログが有効であれば、バイナリ ログ ファイルのシーケンス番号は前のファイルと比較して1つ増加されます。

6. マスターサーバーにて、に対して、更新系クエリのロック（一時停止）を解除する
   

   mysql> UNLOCK TABLES;

7. 全てのスレーブ側サーバーでスレーブを開始する
   

   mysql> START SLAVE;

8. マスター側、スレーブ側の /etc/(mysql/)my.cnf のバイナリ ログフォーマットの設定を変更する
   

   [mysqld] ... binlog_format=mixed ...

先に示した警告メッセージについて簡単に解説してみましょう。

...
130529 12:22:26 [Warning] Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. INSERT... ON DUPLICATE KEY UPDATE  on a table with more than one UNIQUE KEY is unsafe Statement: 
  INSERT INTO `wp_options` (`option_name`, `option_value`, `autoload`) VALUES ('_transient_feed_mod_57bc725ad6568758915363af670fd8bc', '1369797746', 'no') ON DUPLICATE KEY UPDATE `option_name` = VALUES(`option_name`), `option_value` = VALUES(`option_value`), `autoload` = VALUES(`autoload`)
...

警告メッセージの最後に問題となったSQL文が付いています。
そのSQL文では、wp_options へ行を挿入する際に警告メッセージが出力されたことがわかります。
wp_options のテーブルは、以下のとおりです。

CREATE TABLE `wp_options` (
  `option_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `option_name` varchar(64) NOT NULL DEFAULT '',
  `option_value` longtext NOT NULL,
  `autoload` varchar(20) NOT NULL DEFAULT 'yes',
  PRIMARY KEY (`option_id`),
  UNIQUE KEY `option_name` (`option_name`)
);

option_id : プライマリキー
option_name : ユニークキー
となっています。
ここで問題なのが、ON DUPLICATE KEY UPDATE の対応です。
先の問題となったSQLにも INSERT INTO ... ON DUPLICATE KEY UPDATE ... のようにON DUPLICATE KEY UPDATE が設定されています。
ON DUPLICATE KEY UPDATE は、プライマリキーあるいはユニークキーで二重キーとならないように、もし、同じキーが存在したら、行挿入せずに、既存の行のON DUPLICATE KEY UPDATE 以降に指定するカラム名毎のデータを設定するように指示するものです。

例えば、以下のようにwp_optionsにデータが設定されてあったとします。

mysql> select * from wp_options;
+-----------+-------------+--------------+----------+
| option_id | option_name | option_value | autoload |
+-----------+-------------+--------------+----------+
|         1 | 'abc'       | 'option1'    | 'yes'    |
+-----------+-------------+--------------+----------+
|         2 | 'efg'       | 'option2'    | 'no'     |
+-----------+-------------+--------------+----------+

この状態に以下のようなSQL文を発行します。

mysql> INSERT INTO `wp_options` (`option_id`,`option_name`,`option_value`,`autoload`) 
              VALUES (2,'abc', 'option3', 'autoload') 
              ON DUPLICATE KEY UPDATE `autoload` = 'off';

これだと、option_id は、既存の2行目と一致、option_name は、既存の1行目と一致します。
つまり、ON DUPLICATE KEY UPDATE 以降の `autoload` = ‘off’ は、1行目に対して実行すべきか、2行目に対して実行すべきかわからないのです。

これは、ちょっと極端な例ではありますが、理屈は同じです。 先の警告メッセージが出力された例では、`option_id` を指定していないだけです。 `option_id` は、AUTO_INCREMENTになっているので、省略しているのですが、レプリケーションでは、マスター、スレーブで実行して同じ `option_id` になる保障はないことから、警告メッセージが出力されます。

つまり、もし、これらの警告メッセージを回避するためには、これらのSQL文を見直す必要があるということになります。

もし、今から、これらのテーブルを設計するのなら、検討の価値はあります。
しかし、Wordpressのテーブルのように 既に利用している場合、これは、非常に、非現実的ですね。だから、上記のバイナリログフォーマットを変更することが現実的なんですね。