TLDR; you probably just want to save some money by replacing/adding a single SSD to your array instead of running it in RAID 10.
With a high enough mirroring level and a large enough disk cache, you could probably sync the Ethereum blockchain on a HDD, but one SSD will do due to the low latency of random seeks; there's no need to put SSDs into RAID.
You haven't mentioned whether you're doing software or hardware RAID, but in any case, I'm guessing your system is more than capable of handling RAID 10 without any negative effects on syncing if it just boils down to the use of RAID itself.
Will see more wear? Yes: you are writing twice as much data due to the mirrored portion of your RAID 10 (the RAID 1 part). So it's an increase by at least (and close to) a factor of two. But the wear is spread out over four disks, so I think you'd see a per-disk life expectancy of roughly double what you'd see in a RAID 1 or JBOD setup (i.e., you'll be doing less swapping out of disks due to wear); OTOH, at present rates, it'll probably take a very long time to wear out the disks (on the order of years/decades, if not more, to attain the number of write cycles even the lowliest of SSDs are rated for).
Thus, the answer to whether your described setup would work is yes. But I have a different question: why are you thinking of RAID10? (I'll assume a 2x2 array) Is it because you need/want RAID 10 for some other purpose? The only reason I can think of needing RAID 10 is because perhaps you plan on resilvering an existing pool to switch to SSDs with zero downtime (if you're on ZFS, there are probably better ways around this). Here's why I think RAID 1 is more suitable than RAID 10 for this upgrade: If you've got a RAID stripe (RAID 0), then I'm guessing this is to increase your read throughput and/or latency and/or total addressable capacity and it's already meeting your needs. But a not-particularly-speedy SSD can give you more than 2x throughput than an HDD -- and thus provides at least as much throughput as a striped HDD volume. It also gives you far more IOPs than a 2-disk striped HDD volume (two or more orders of magnitude). Because Ethereum is essentially a giant database in which there are many reads/writes, the low disk access latency of SSDs provides a HUGE advantage in terms of blockchain sync speed. Unless you need to RAID your SSDs to achieve the single-volume capacity you need, you can save your money and skip striping your SSDs.
I also think you should skip mirroring this disk as well, unless you plan on keeping things other than the blockchain on it or you want to achieve higher uptime due to online redundancy (e.g., in a production server environment). I would assume you'd actually want node-level redundancy in a high-availability setup anyway, so disk mirroring wouldn't entirely address high availability, anyway. You can always resync the blockchain if/when your disk goes kaput -- no real data loss (I'm assuming you back up your keys separately -- redundancy is not backup and untested copies are not backups!). To reduce sync time, if your volumes/disks support snapshotting you can always snapshot and dump your data to a lower-cost medium like your existing HDDs. Then a restore is as simple as
restoring from the snapshots and you only need to do a partial resync. In this case, the IOPs advantage of SSDs is moot -- you just need throughput to restore your backup which your HDDs provide more than enough of. The full Ethereum blockchain (instead of pruned syncs) is about 350GB at the moment. You could restore that amount of data to an SSD from a single HDD in less than an hour (assuming 120MB/s HDD transfer rate). So... no need for mirroring, either!
That being said, one of my Ethereum nodes is running on a 2x512GiB RAID1 ZFS volume made up of SSDs. This is because I plan on putting other data that needs low latency on those disks at some later point in time (right now, the disks are mostly empty). Instead of dedicating a non-redundant disk to the task, I used the mirrored volume because I ran out of hot-swap disk bays and didn't want to "waste" a bay. Thus, I can see several use cases for RAID10 or other RAID levels being used for the blockchain -- I just don't think there are that many. Hopefully I saved you some $$$ :)
More performance data with Parity/v1.7.7-stable-eb7c648-20171015/x86_64-macos/rustc1.20.0:
I just did a brand new sync in pruned mode (which should do at least as much I/O as archive mode) on an NVMe drive; it's only 256 GiB, so I couldn't do an archive test if I wanted. My network connection is ~200Mbps up and down. Parity seems to be much more read-IOPS-intensive than write-IOPS, but does about 2x as much writing in terms of volume of data, so RAID1 seems to provide more performance benefits than RAID0. Also, I'm only seeing 5-10k IOPS (<5% utilization) and 200MB/s throughput. and thus seem to be CPU constrained: ~2 cores maxed out on an i7 6700HQ (2016 15" MBP). The process took 2h29m.
