On a PERC, there is no primary or secondary in that sense.  The controller stores the configuration it uses, and the configuration is also stored on the disk.  When two disks (one current and one out of date) are present and the controller has to decide which one to use, it simply uses the disk whose configuration signature matches that on the controller.  It also would not rebuild a disk automatically in this scenario - it would leave the outdated disk in a "foreign" state until the user cleared the foreign flag and assigned it as a hot-spare to the RAID 1, allowing it to rebuild in the place of the missing disk in the array.
One of our workstations in the building had some very unusual file corruption with no chance of recovery (tried a few diff recovery apps) and I'm hoping to gain some insight into exactly what happened.  Our bookkeeper's workstation has a SiI RAID controller with 2 physical drives in RAID1.  It turns out that for the past few months, the power cable on one of the drives was loose and no one noticed until I went through and rebooted the system during an update.  After diagnosing the degraded array and plugging it back in, I let the system reboot, rebuild, and left it at that.  Now here's the real <ADMIN NOTE: Profanity removed as per TOU> part ... I found that our two most recent database files that we use on a day to day, are both cross-linked, and totally corrupted (the payroll MS Access database shows garbage from the daily sales database and the petty cash Excel document is just all garbage).  Is it possible that during the repair process, the RAID controller tried to update the NEW file with the OLD volume?  Is that why the thing went nuts?  RAID1 was great in terms of solving hardware failure issues - but it slipped my mind that RAID1 will still mirror file corruption.... blah blah blah blah  @.@
RAID1 Rebuild Order of Operations