Veritas InfoScale™ 7.3.1 Troubleshooting Guide - Solaris
- Introduction
- Section I. Troubleshooting Veritas File System
- Section II. Troubleshooting Veritas Volume Manager
- Recovering from hardware failure
- Failures on RAID-5 volumes
- Recovery from failure of a DCO volume
- Recovering from instant snapshot failure
- Recovering from failed vxresize operation
- Recovering from boot disk failure
- Hot-relocation and boot disk failure
- Recovery from boot failure
- Repair of root or /usr file systems on mirrored volumes
- Replacement of boot disks
- Recovery by reinstallation
- Managing commands, tasks, and transactions
- Backing up and restoring disk group configurations
- Troubleshooting issues with importing disk groups
- Recovering from CDS errors
- Logging and error messages
- Troubleshooting Veritas Volume Replicator
- Recovery from configuration errors
- Errors during an RLINK attach
- Errors during modification of an RVG
- Recovery on the Primary or Secondary
- Recovering from Primary data volume error
- Primary SRL volume error cleanup and restart
- Primary SRL header error cleanup and recovery
- Secondary data volume error cleanup and recovery
- Troubleshooting issues in cloud deployments
- Recovering from hardware failure
- Section III. Troubleshooting Dynamic Multi-Pathing
- Section IV. Troubleshooting Storage Foundation Cluster File System High Availability
- Troubleshooting Storage Foundation Cluster File System High Availability
- Troubleshooting CFS
- Troubleshooting fenced configurations
- Troubleshooting Cluster Volume Manager in Veritas InfoScale products clusters
- Troubleshooting Storage Foundation Cluster File System High Availability
- Section V. Troubleshooting Cluster Server
- Troubleshooting and recovery for VCS
- VCS message logging
- Gathering VCS information for support analysis
- Troubleshooting the VCS engine
- Troubleshooting Low Latency Transport (LLT)
- Troubleshooting Group Membership Services/Atomic Broadcast (GAB)
- Troubleshooting VCS startup
- Troubleshooting service groups
- Troubleshooting resources
- Troubleshooting I/O fencing
- System panics to prevent potential data corruption
- Fencing startup reports preexisting split-brain
- Troubleshooting CP server
- Troubleshooting server-based fencing on the Veritas InfoScale products cluster nodes
- Issues during online migration of coordination points
- Troubleshooting notification
- Troubleshooting and recovery for global clusters
- Troubleshooting licensing
- Licensing error messages
- VCS message logging
- Troubleshooting and recovery for VCS
- Section VI. Troubleshooting SFDB
Recovering from a failed plex attach or synchronization operation
A plex attach operation requires that the plex be synchronized with the existing plexes in the volume. Other operations such as creating a mirror for a volume also require plex synchronization. The synchronization of the plex can be a long-running operation, depending on the size of the volume and the amount of data that needs to be synchronized.
When the disk group version is 170 or 180 and the plex resynchronization is triggered by the vxplex att, vxassist mirror, vxsnap addmir, or vxsnap reattach commands, the plex remains associated with the volume during volume recovery. VxVM detects that the synchronization was interrupted, and resumes the synchronization. If the volume has an associated DCO (version 20 or later), VxVM tracks the changes while the plex is synchronizing, If the synchronization fails due to a system crash or vxconfigd failure, VxVM resumes the synchronization from the point where it failed. The synchronization occurs in the background, so the volume is available without delay. If the volume does not have an associated DCO, but has a version 170 or later disk group, the synchronization restarts from the beginning.
When you create a volume and add a mirror in one operation (vxassist make nmirror=2), the synchronization of the mirror is not tracked for automatic recovery. To ensure that the synchronization resumes from the point where it failed, create the volume first and then add the mirror with the vxassist mirror command.
VxVM automatically recovers volumes in some cases. If you need to recover the volumes manually, the vxrecover command triggers the synchronization for any plexes that have a failed synchronization process. These plexes have a state of TEMP, TEMPRM, or TEMPRMSD.
In the CVM environment, if a master node crashes while a plex synchronization is in progress, the new master restarts the synchronization from the point where the master node failed, after the master recovers. The disk group must be version 170 or later. If the disk group is version 170 but no DCO is attached, the synchronization restarts from the beginning.
You can abort a plex attach operation or synchronization operation with Ctrl-C or the vxtask abort command. In this case, VxVM dissociates the plex from the volume.