Hi RT folks, I am trying to migrate RT 3.0.6 up to 5.0.7 and so far I have had a lot of success with the tools provided. One of the main reasons for the migration is we need to externalise all our attachments out of mysql and this support is introduced since 4.xx (I think). What I am trying to do however is look for an easy way to run the externalise-attachments script on an older version such as 3.0.6, is this possible? I am thinking that perhaps it is not as the api in ver 3.0.6 doesn’t support retrieving of attachements etc but wanted to verify.
Additionally I have a few questions also;
When attachments are stored on disk is there a folder structure that is used?
Are attachments readable on the disk? i.e. would a text based attachment be stored as test on the disk?
What is the recommended cron schedule for running the rt-externalise-attachments script?
Thank you very much for your help.
-Steve
tpgtelecom.com.au
Hi. Additional answers 
- Cron at a daily base (night) but it depends on the amount of tickets per day. If there are just a dozen per day… it’s ok per week or per month.
- Attachments are readable at disk.
- They are stored in a hash structure of directories and file name.
I don’t know anything about migrating yet, I’ve started with 5.0.4
As you’re trying to do something a bit “out there” you definitely want to back up the machine before you do anything. I’d be tempted to get another machine, restore the image on that and then play with it in safety in parallel to your production system to work out the process you might need. I’d also maybe “encode” it as an Ansible script so that it is reproducible when you do want to do the migration for real. We do that for our services (just in the midst of the 5.0.1 → 5.0.7 migration now) using Ansible to manage porting all of our many local modifications.
As for using external attachments with rt 3.0.6, I think you might find that is going to be a bit of a struggle as its more than just a couple of missing scripts: the library code to support external attachments isn’t going to be there and much can change between major versions. Is there a reason why you can’t migrate first, and the externalise the attachments? Or even migrate to 4.4.0, externalise there and then continue the migration to 5.0.7?
Hi Sollericos, this is great, thank you. I am slowly getting my head around this. I did notice with rt 5.0.7 there is some webconfig for externalising attachments so I figured rt externalised automatically without the need for the cron. I have to do more research but I would like to get to the bottom of that one.
Cheers
Steve
You need cron too for externalize attachments. Web config for this is a step further to migrate all config to web UI.
@GreenJimll gives you two possible paths to do that:
- Migrate first, then externalize. (My favourite)
- Migrate to an intermediate version, externalize attachments and migrate later to the last version (too much work, isn’t it? only if the firs one fails)
One reason why you might want to externalise on the intermediate version is that in the move from 4.x → 5.x the RT database has to have its tables converted to Unicode. If you’ve got a very large attachments table this might take a while and also add to the extra disc space you’ll need to handle the table copies. If you’ve already got the contents of the attachments in files, that might help with the process (I don’t know for sure - our attachments are still in the database!).
Yeah the primary reason for the migration and externalisation of the attachments is our mysql table was over 1.5Tb and was becoming difficult to manage. Why do I need to go to 4.x first? Is that for ease of migration and compatibility between the older schemas ?
I’d test a migration to 5.x first. If everything is OK, good. If too many problems arise, it’s better smaller steps to deal with less problems in every step. It’s up to you but @GreenJimll knows a lot more than me about problems you can find and resolve in some versions (I’ve started in 5.x), his advises must be taken in account.
1 Like
When you do an upgrade in RT, the database schema is updated for every version between the one you’re on and the one you’re going to, so if you go from 3.0.6 to 5.0.7 you’ll go through the changes required for every intermediate release as well.
In your case I’m suggesting you do an upgrade to 4.4.0 first because that’s the point RT supported externalised attachments. Which if you have 1.5TB attachments table you might well need before you do the schema change for 4.x → 5.0.0. Otherwise you’ll need >3TB of disc space (temporarily) for the copy of the Attachments table that is made when the Unicode changes is made to the schema (which will also take quite a while on that size of table).