From my standpoint, you may have potentially introduced data drift into replication.

[**Baron Schwartz presented this as a puzzle in his blog**][1].

You may have to reload `oldS` and `newS1` with fresh data.

At the very least, you should use [**pt-table-checksum**][2] to see if

- the data on Master differs from oldS
- the data on Master differs from newS1

If the differences are not identical, you can either 

- reload  `oldS` and `newS1` fresh
- run [**pt-table-sync**][3]

Before you touch anything, please fix the [**server-id**][4] situation

The spawning of relay logs is to be expected because sibling slaves take turns getting SQL entries from the Master. They simply cannot share the same server-id. The Master will somehow alert subsequent slaves that I gave server-id an SQL statement already. Thus, the I/O thread on subsequent slaves will disconnect and retry. Consequently, empty relay logs increase. (*Trust me, I have shot myself in the foot with this years ago*).

This methodology of the Master talking to Slaves for this info allowed MySQL (eh, Oracle) to  come up with semisync replication. This would break semisync replication as well. Even though MySQL 5.6 will soon introduce a Global Transaction ID into the mix, [**server-id**][5] will still be used in its method of checks-and-balances on the Master. After all, if an eagle had 
 two eaglets, no eagle would spit into two mouths at the same time in order to feed them.


  [1]: http://www.xaprb.com/blog/2009/03/14/pop-quiz-how-can-one-slave-break-another-slave/
  [2]: http://www.percona.com/doc/percona-toolkit/2.0/pt-table-checksum.html
  [3]: http://www.percona.com/doc/percona-toolkit/2.0/pt-table-sync.html
  [4]: http://dev.mysql.com/doc/refman/5.5/en/replication-options.html#option_mysqld_server-id
  [5]: http://dev.mysql.com/doc/refman/5.5/en/replication-options.html#option_mysqld_server-id