Hi we are planning to upgrade Fisheye from 2.9.2 to 3.5.0. Our Fisheye scans our perforce repository. The problem we have is that we cannot make a full reindex of one of our Perforce depots which is very big (1100Gb) with the fisheye 3.4.4 version or later. Under 2.9.2 it takes 7 days. the problem is under investigation by atlassian see (FSH-14599). An advice from atlassian we got is to copy our fisheye data from our current production server and restore it under the new production server running fisheye 3.5.0. This operation shall not require a full reindex of our big 1100Gb depot, but only cause scanning of the latest perforce changelists in this and other depots.
I enclose a plan for this see below
Will I get any problems with this operation you can see directly by reeading it ?
1. Production fisheye data is a round 500 Gb. It resides under FISHEYE_SERVER_A::/opt/fisheye/fisheye_inst_2
2. You shall copy the everthing from FISHEYE_SERVER_A:/opt/fisheye/fisheye_inst_2 (fisheye production) to a destination server running fisheye
3. Make sure you have around 1000 Gb on the destination server ( You need room for 2 production instances
§ a backup of what you have copied
§ and the new instance that you copy from the backup
4. VERY IMPORTANT: You must shut down fisheye production when you copy (Fisheye continously updates it's files).
This the order to work to copy a fisheye perforce system.
Beacuse fisheye collects all it's data from perforce. A perforce system must be newer than the fisheye after creating replicas.
When perforce are updated with new data (committed files) Fisheye collects them after wards.
So following is valid
§ Schedule for 1 hour stop of fisheye and perforce production
§ Shut down fisheye FISHEYE_SERVER_A production (The perforce server is till avaialable and may be updated)
§ Shut down perforce SERVER_PERFORCE_A production (Now we have secured that fisheye do not have all changelists)
When the production downtime hour beginns:
§ Take Linux snapshot of the fisheye production data filesystem (FISHEYE_SERVER_A:/opt/fisheye/fisheye_inst_2) Around 450 Gb
§ Take Linux snapshot of the perforce production data filesystem (SERVER_PERFORCE_A:/
§ Start the production Perforce server SERVER_PERFORCE_A ( Now the perforce may contain newer changelists to be scanned by fisheye)
§ Start the production Fisheye server FISHEYE_SERVER_A ( Important that fisheye prod i started AFTER perforce production.
(The fisheye server must NOT start without any connection to the perforce server)
production downtime hour is ended:
Updating the Preprod servers starts with latest production data
§ Start copying fishsye data from snapshot to FISHEYE_SERVER_B new fisheye preprod instance. FISHEYE_SERVER_B:/opt/fisheye/fisheye_inst_data1 (takes around 6 hours to copy this using rsync) (the snapshot garanties that updated files after snapshot isn't copied) FISHEYE_SERVER_B:/opt/fisheye/fisheye_inst_data1
§ At the same time Start copying perforce production data from snapshot to PERFORCE_SERVER_B new perforce preprod instance (takes around 12 hours to copy this using rsync)
(the snapshot garanties that updated files after snapshot isn't copied)
Perforce files to be copied:
DB files will be removed from the root folder on the new server.
Checkpoint file will be copied to the new server.
A restore form checkpoint will be made on the new server.
PERFORCE_SERVER_B can now be started.
Both PREprod servers are now updated with production data:
Update and change files in fisheye preprod to adapt to from production to preprod:
§ FISHEYE_INST points to the correct partion
1. Path to FISHEYE_INST correct
2. Diff the files config.xml fisheye 3.5.0 and config.xml 3.4.4 for incompabilities and problems
3. Do a restore from backup to the MSSQL database configuration (Check this)
4. Make sure that the perforce server info is changed from PERFORCE_SERVER_A to PERFORCE_SERVER_B concerning the path in config.xml
5. Check the java environment concerning Heap and RAM (FISHEYE_OPTS setting)
When everything prepared start new fisheye preprod
I have strong feeling that it is impossible. As I remember Atlassian made big set of changes in perfomance of fisheye from major version 2 to 3 (at least with svn repositories), and old indexes are just unworkable with the new version. So you should prepare for long migration.
I would advice to you to create a new host for fisheye, block the code review possibility for 1 week using permission sets, then migrate instantly after reindex.
Thanks for signing up for Jira Ops! I’m Matt Ryall, leader for the Jira Ops product team at Atlassian. Since this is a brand new product, we’ll be delivering improvements quickly and sharing updates...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs