I'm looking into sync_binlog = 50 and innodb_flush_log_at_trx_commit = 2 to improve write performance. There is this question, but it doesn't address the specific problems with replication.
I have an application that processes incoming log data with dozens of commits per second, causing a lot of flushing to disk, and losing one second of data is not a problem for the increase in speed it gives. However, The docs state:
For durability and consistency in a replication setup that uses InnoDB with transactions [set both options to 1].
But it doesn't specify the issues with consistency and durability. I would like to know what exactly can go wrong. If you have a hardware crash and the slave becomes live, it may be one second behind the original master. Are there subsequent problems in getting that failed master back online (as slave)? Could there be mismatches in ID's, duplicate rows, etc?
As I said, loosing data is OK, but breaking replication is not.
Edit: BTW, by now, the problem is solved another way. Long story, but an comprehensive schema change made it possible run log processors in parallel. Still slow per process, but many at a time makes it fast.