Highlighted

Veritas Data Insight 6.0. Freezed status "IN PROGRESS" when i changed indexer of filers

Hello everyone, i have to change indexer server, and when i did it, one of my filers is freezed.

Now, when i go to setting-filers-View migration status, the status is Migration Status: IN PROGRESS
I tried to wait, but after 3 days nothing changed

Also i have na error: V-378-1312-762: Indexer backlog age 4 hours exceeds IndexWriter jon interval

what have i to do?

1 Solution

Accepted Solutions
Accepted Solution!

Re: Veritas Data Insight 6.0. Freezed status "IN PROGRESS" when i changed indexer of filer

Hello, I defeated the problem

My solution: i went to indexer servers' config folder C:\datainsight\data\migration and deleted file idx_migration.db

After that it works

View solution in original post

3 Replies

Re: Veritas Data Insight 6.0. Freezed status "IN PROGRESS" when i changed indexer of filer

Dear AA11,

Migration is done when you choose to change indexers for the entire device. What I mean is you cannot do it for the largest share to balance the load, you do it for the filer device and all of its' shares. Depending on the device it could be a very large transfer.

The process is to mark the device and all of the associated shares as migrating and keep the in progress status until all of the indexes, pending data base transactions and backlog are transferred. We actually stop updating the indices maintaining the current status until all are transferred and there is a duplicate copy in the target of the source's data, including new and incoming data.  You need a period of no I/O with high network bandwidth availability to complete the transfer as each new stream in would also have to be a stream to target and this makes the bandwidth 50% as effective for the duration on a very busy box.

Logically starting a transfer during a downtime window or entering a weekend is best but you are in the situation you are in already. I would not recommend cancelling only to start over as the cancel resets the status, opens the databases for updates and starts indexing on the next job cycle making the data on target redundant and irrelevant so it is deleted and you are starting over with any subsequent migration request.

As each share location is successfully moved the data is sent to both the target and source until 100% of all shares are completed. In the migration databases the share is marked as successful and the freed thread is move to the next consecutive share for migration. The status of the migration job will remain in progress with some shares completed successfully, others in progress and the remainder in waiting pending status until completion.

Once 100% of shares are migrated, all pending transactions associated to those shares are in the target inbox and all new data is being sent to the target the status will move to the completed phase and the configuration database will be updated for the device's association, all shares and their path and file objects to reflect the location on the new indexer making the source data outdated and redundant. On the next job cycle for indexing the device's shares will be marked for index and the block to indexing removed. This will cause the old location which is no longer valid to delete all the databases, and pending files freeing space on the old indexer. The new indexer will start processing the shares associated to the device and play all the transactions into their appropriate database clearing the backlog on the new indexer. These actions should remove the excess files in the inbox and remove the notification on the processing times for the backlog or at least put it back into an expected range. One reason for suggesting and initiating a migration is to lower the amount of backlog processing times, another is to improve response times for reporting and rendering the GUI data.

Going forward you have a few choices and perhaps I can put them into a suggested list to guide you in your decision making.
1) let it run over the weekend when you have less I/O from the share's client computers and it may complete for you

2) call into Veritas support who will direct you to send the appropriate files and databases for a 'check' of your current status

3) Cancel and  NEVER MIND I would not suggest this; do number 2 and they can direct you since they will have valid information.

We can continue the conversation if this does not resolve your query and further explanation is required just let me know.


Rod

Accepted Solution!

Re: Veritas Data Insight 6.0. Freezed status "IN PROGRESS" when i changed indexer of filer

Hello, I defeated the problem

My solution: i went to indexer servers' config folder C:\datainsight\data\migration and deleted file idx_migration.db

After that it works

View solution in original post

Re: Veritas Data Insight 6.0. Freezed status "IN PROGRESS" when i changed indexer of filer

THat would be similar to a cancel, however there are three databases required to be in sync and you removed one of them or since plural two of them. That would be source and target and not the master coordination database. If you have satisfied yourself that it 'worked' and all is well then it shall end there.

If you experience strange behavior, lack of indexing, missing indexes or other anomalies I would suggest you mention this when opening a support case.

 

You can also learn more of the current version's behaviors with the indexed online guide under:
https://www.veritas.com/content/support/en_US/doc-viewer.127846131-127846134-0.DI_6_1_v98745979-1278...

There you can find caveats such as:

"Files and folders do not inherit the Custodian assignment

Custodian is assigned at device level. When a device is migrated to another Indexer, then the assignment may not apply to the subfiles and subfolders within that device."

and other  issues or changes.