Ini pengalaman saat di kantor minggu lalu, mumpung inget, ditulis di blogs saja.
Kalau rekan2 kebetulan Exchange 2007nya menggunakan model Cluster Continuous Replication, perlu diperhatikan bahwa walaupun teorinya jika ingin melakukan maintenance di node yang pasif kita dapat langsung menshutdown dan melakukan maintenance, ternyata perlu diperhatikan bahwa downtime dari si passive node tidak boleh terlalu lama.
Hal ini karena CCR menggunakan metode log shipping dari aktif node ke passive node, dan perbedaan antara log yang ada di aktif dan passive node tidak boleh terlalu besar. Dalam kasus saya, saya tidak melakukan maintenance di passive node, tetapi memang sudah kurang lebih 2 hari backup di Exchange server tidak berjalan sempurna. Anehnya, tidak ada service yang mati, emailpun masih berjalan sempurna. Problem yang nampak adalah transaction log di beberapa storage group tidak terhapus setelah full backup.
Setelah saya mentransfer node ke node yang passive, baru ketahuan bahwa transaction log tidak tercopy dengan sempurna, dimana terdapat perbedaan yang sangat besar (kurang lebih 3000+ log) sehingga storage group tidak mau mounted. Setelah saya transfer kembali ke node yang lama, seluruh storage group mau mounted tetapi ada 3 storage group berada pada status initializing.
Nah disini ini jebakan batmannya, kalau rekan2 cari di search engine, kebanyakan akan menyarankan untuk menunggu ataupun mengirim email agar terjadi transaction log baru. Saya pikir okelah , kebetulan hari jumat sore, ditunggu dulu sambil weekend.
Keesokan harinya saya cek, ternyata masih tetap initializing, pasti ada yang ga beres nih…
Saya mencoba mensuspend log shipping dari passive node, dan meresumenya kembali, ternyata statusnya menjadi failed. Ok, selanjutnya saya suspend saja untuk seluruh storage group bermasalah
Apa donk langkah selanjutnya? Karena jumlah copyqueuelength sudah besar sekali, melakukan copy transaction log secara manual jelas tidak efektif. Satu satunya cara yang tersisa adalah MENGHAPUS copy di passive node dan melakukan RESEED ulang.
Di versi sebelum SP1, langkah diatas harus dilakukan secara manual, untungnya pada SP1 (dan SP2) langkah ini dapat dilakukan melalui Exchange Management Console dengan mengakses command Update Storage Group Copy dari Passive node.
Setelah melakukan proses Update Storage Group Copy, status cluster akan Healthy kembali, dan juga yang penting transaction log yang tidak terpakai akan terhapus. Perlu diperhatikan bahwa langkah ini harus dilakukan satu persatu terhadap storage group yang bermasalah, tidak bisa berbarengan. Pengalaman saya waktu itu, untuk mengupdate storage group dengan data sekitar 40GB perlu waktu satu jam.