A maze of twisty symbolic links
Sep. 25th, 2007 09:10 pm/app/op -> /h1/op
or in the case of a fail over:
/app/op -> /h2/op
where /h1 and /h2 are different file systems on different discs in different locations. So far, so simple. But the application needs to be upgraded from time to time and this means that a shadow copy must be run in parallel to the operational version, tracking it in real time. That means that it too needs it's own set of links:
/app/par -> /h2/par
But, how to upgrade from shadow to operational without copying everything from one location to another? Why not use four file systems, two per physical location, and switch the links round on upgrade day? But what are we going to call the links and file systems? How about:
/app/op -> /h1/op /app/op2 -> /h2/op /app/par -> /h2/opA /app/par2 -> /h1/opA
So, the first link points the operational copy, the second to the operational backup, the third to the shadow copy and the fourth to the shadow backup. Easy. But what happens when the software is upgraded?
/app/op -> /h1/opA /app/op2 -> /h2/opA /app/par -> /h2/op /app/pars -> /h1/op
Well, I suppose that sort of makes sense, but what happens if a fail over event occurs? Well, the links go to:
/app/op -> /h2/op /app/op2 -> /h1/op /app/par -> /h2/opA /app/par2 -> /h1/opA
or:
/app/op -> /h2/opA /app/op2 -> /h1/opA /app/par -> /h2/op /app/par2 -> /h1/op
depending on the upgrade situation. Which means that in some situations, the op2 link is pointing to location 2, but sometimes it's pointing to location 1, whereas the par2 link is always pointing to location 1.
Confused? I was. Totally. So I dug my heels in and demanded that the names be of op2 and par2 be changed to op_backup and par_backup to preserve my sanity. And guess what? I won my case and the names were changed. Hurrah for me!