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
Data volume name mismatch error during modification of an RVG
If a volume is renamed on the Primary but not on the Secondary, a configuration error results and the RLINK will be disconnected. Use the vxprint -lP command to view the RLINK flags. If the secondary_config_err flag is set, use one of the following commands to determine if there is a data volume name mismatch error.
On the Primary:
# vxrlink -g hrdg verify rlk_london_hr_rvg RLINK REMOTE HOST LOCAL_HOST STATUS STATE rlk_london_hr_rvg london seattle ERROR PAUSE ERROR: hr_dv04 on secondary has wrong primary_datavol name (hr_dv04, should be hr_dv05)
On the Secondary:
# vxrlink -g hrdg verify rlk_seattle_hr_rvg RLINK REMOTE HOST LOCAL_HOST STATUS STATE rlk_seattle_hr_rvg seattle london ERROR PAUSE ERROR: hr_dv04 on secondary has wrong primary_datavol name (hr_dv04, should be hr_dv05)
To fix this error, do one of the following:
Rename either the Primary or Secondary data volume, and resume the RLINK using the vradmin resumerep rvg_name command.
OR
Set the primary_datavol field on the Secondary data volume to refer to the new name of the Primary data volume as follows, and resume the RLINK using the vradmin resumerep rvg_name command.
On the Secondary:
# vxedit -g hrdg set primary_datavol=hr_dv05 hr_dv04
where hr_dv05 is the new name on the Primary