How to migrate Artifactory from one instance to another in low-downtime? [Video]

Saleh Samara
2021-02-02 19:49

 

Video Transcription

Hi, my name is Aaron Rhodes. Today we’re going to cover the procedure for doing a migration from one Artifactory instance to another, with very low to no downtime between the migration. Now normally what you would do is export the system, cut off your users, and then import the system on the target instance before enabling your users on the new instance. But that can be a long time if you have a lot of data to transfer between the one instance and the other and the import time. It can take literally days for that to happen. So this procedure is meant to reduce the amount of time by using some tricks. So right here, we have one instance of Artifactory. This is a 6.X instance with these repositories, and our target instance, which is a clean instance installed of a version 7. And this is what we’re going to import to.

The first step that we’re going to do is not the export. We’re going to let the users do their thing here, and we’re going to go to the shell of this instance and we’re going to do… And we’re going to rsync between the two. And this should copy all the data over. All right, so now we’re rsyncing all the data. Now what this is doing is syncing all of the files that exist in the file store of our source instance and rsyncing them to the file store of the target instance. And this is going to save us time if there… Imagine there are many, many terabytes of data to transfer over, we’re going to be doing all of that to reduce the amount of time we need to transfer that later. So now we have that all rsynced.

Now, in this instance, let’s you were in this live, maybe you’re doing this on a weekend or something, what you would do is this maybe would have taken many, many hours or even days to transfer all the data over. What you would do then is at some point where you decide you’re going to do the cut-over, you would then rsync again, and this is to catch up any activity that happened on your source instance while the rsync was happening. So you have that delta that you need to catch up. So you would rsync again. Let’s do it again. Of course, there’s going to be no changes, but boop, it’s going to be very quick. Now we’re going to now immediately do the export. Now our users can still go ahead and do their thing. We don’t need to cut them off yet, but we do need to do our export.

So in our export, we’re going to do… We’re going to first… Let’s put it somewhere nice. Let’s just put it in root’s home folder here. And there are a couple of options I’m going to use. One is exclude content. This is going to make sure that the export is not exporting all of our binaries into flat files, flat binaries in the backup. Because we’re rsyncing those, we’re not going to use those in the context of the export. We’re also going to do it in a ZIP, because I want to transfer one file over using SCP to the target instance. And that file is going to be the ZIP. This is going to be the database export. So we’ll create this. It has created this file called something timestamp here dot ZIP. And we’ll go back to our shell and we can see that right there.

Now we’re going to do the SCP command to get it over to the target instance. And we want to use the file. So there’s our file, and on the target I’m going to call it export.zip for simplicity. There we go. All right, so now transfer the file. We have it on our target instance. At this point, we need to do some work on the source instance. So right now we’re going to set up replication. We’re going to replicate to the target instance in order to catch it up, rather than trying to rsync again. We can’t really do that. We can’t rsync the database. So we’re going to use the replication of the source instance to do that for us. So let’s go… And we only need to do locals. Virtuals you can’t just replicate, and remotes, we don’t really need remote cache because it can be caught up again on the target instance. That might cause us some bandwidth, but it’s usually not very consequential. So we’re only going to replicate the locals.

Now the way we’re going to do that is just sets us up here. I’m going to go ahead and set these up, and I’ll cut this in the video because replication is another topic, and I’m sure that you already know how to do that. Now I have all three replications set up here. I’ll give you an example of what that looks like, as well… We have a cron expression in here, which is once a year, just because I needed a cron expression, and the credentials are going to be the future credentials of the target instance. And the repository here is going to be the same name. Because we’re going to import on the target instance, I’ve used the same name for the target and the same credentials as the target. And I haven’t even imported on the target instance yet. So if I test this, it’s going to fail because there’s nothing over on the target instance yet. There’s no repository of that name. So I had to rely on making sure the name is spelled correctly and everything. That’s how we set it up.

Now we’re going to go ahead and do the import on the target instance, and that should be easy now. We’ve copied over our file. System, import on the import system, browse for that file. Here it is. And you’ll notice there’s an exclude content option for the import. This is different than the exclude content on the export, and we don’t want to use it. This would make it so it doesn’t even import repositories. So we don’t need to select any options here. We can just go ahead and do the import. Now it’s going to want me to sign in here because credentials have changed. So I’m going to use the new credentials. And our repositories now, we now have all this, including some of our files here in the import. And it accepted the import, it didn’t have any errors because we had already rsynced the files from the file source to the target file store.

So now we’re all caught up here with the import. Now the last thing we do, at this point, this is where we’re going to do the cut-over of the users with minimal downtime. So at this point, cut off your users. They’re going to have whatever downtime it takes you to do this procedure. You’re going to cut them off. You’re going to prepare for them to switch over to using the target instance instead of the source. You’re going to go into your local repositories here and fire off replication. Boom, boom, boom. It looks like I did something wrong here. Aha, so let’s be sure to account for mistakes like this. I believe I know what I did. I did not fill in the repository name.

Okay, so that should fix it. If we test now it’s successful. Save. Go back to local repositories. All right, save. And now we’ll fire this one off. Great, it’s successful, and now everything will be caught up on the target instance, and now we can turn on our users to use the target and that effectively narrows the amount of downtime to the minimum we can possibly do and gets our users back into business. Thank you very much.