Simply restarting
the application wouldn??™t work; the only way to clear it out of memory was to reboot
the server.
If you have manual tasks that should occur after every failover, document them.
Store them on a separate server??”not in the clustered environment??”and even write
them down on paper. Make sure everyone knows where those failover instructions are
located. Don??™t be surprised if you discover during your first production failover that you
need to take manual steps. Remember, disaster recovery planning is iterative, and you
learn every time something goes wrong.
Server Resource Planning
When clustering goes wrong, it??™s often when you have an active/active configuration
without enough system resources to handle a failover. Each node can handle its own
application or the other node??™s application, but not both at the same time.
While resources such as CPU and I/O may just result in extreme performance degradation,
a memory constraint can result in a failed failover. In this case, there isn??™t enough
memory to fail one SQL node over to the secondary node, so the entire process fails.
Pages:
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368