I'm reading the documentation on Scylla's upgrade procedures (
reading the dochttp://docs.scylladb.com/upgrade/upgrade-guide-from-2.0-to-2.1-ubuntu/ for example), and I'm seeing the standard "Stair-Step" path is required from 1.6->2.0->2.1, etc.
As a general question, if I have a backup from an older version of scylla 1.6 (or 1.4 or 1.5), is can I load that into a newer release and the data be migrated automatically? Is there a manual process or a tool that I can use?
Or is the only way to get data from 1.6 to 2.1 to load data into a 1.6 database, do a 1.6->1.7 upgrade, a 1.7->2.0 upgrade, then a 2.0->2.1 upgrade.
You can restore older backups into newer versions just fine. The stair-step procedure that is listed is intended for online migrations (without downtime). If you are doing offline migrations, you can skip versions just fine.
Note that there is a caveat with that: if the tables you are moving come from a different cluster (if you completely wiped out this cluster, for instance) then you have to be mindful of the token ranges of each node when copying the files: just because you had 5 nodes before and have 5 nodes now, it doesn't mean that those nodes own the same token ranges.
Aside from that small caveat, you are good to go!
Related
I want to migrate a shopware with shopware 3.5.4 version to shopware 5 version, but I cannot update it. I'm also trying to transfer its contents and theme to shopware 5, which I just installed. Is there a short way I can do this
There isn't any short way.
You must update to some intermediate version.
If you made it to version 4.2 you can update in these steps:
4.2
5.1.6
5.6.10
5.7.6
See also the shopware 5 changelog
In the shopware github repository, you can find all versions since 4.0.1 as tags.
As most old versions of shopware (at least the ones I got to know) are pretty "tinkered", the easy way moving to recent shopware is:
Copy database and local files to a supporting host (keep in mind that you will need older versions of PHP)
Disable (better uninstall) every plugin and theme, switch to default theme
Upgrade to SW4, then upgrade to recent version of shopware 5 by following this guide strictly https://docs.shopware.com/de/shopware-5-de/update-guides
Use import/export tool to export all product and order data
You might as well succeed by skipping step 3, applying all db-migrations, and using the db with your fresh installation, but I guess you will run into trouble with your media files (images etc. might not be usable anymore).
Another way might be writing a small script to export all data to csv and import it with the native tool.
There is no way (that I know of) to make your old theme working in recent versions of SW5. Before creating a new one, keep in mind SW5 will quite soon be EOL, and SW6 is much faster and way ahead in usability. You could use SW6's import functions to move from SW5 to the recent release.
We have a nexus 2 to nexus 3 migration being done and we have A LOT of objects in our nexus 2 so the migration is somewhat slow even with the hardlink process.
The nexus documentation:
https://books.sonatype.com/nexus-book/reference3/upgrading.html#upgrade-process-expectations
Has this blurb:
Using an existing installation of Nexus Repository Manager 3 populated with data and configuration as the target repository manager incurs restrictions that make the upgrade more complex and potentially requires re-configuring the version 2 instance prior to the upgrade as well as re-configuring Nexus Repository Manager 3 after the upgrade.
I'm hoping to minimize downtime so was thinking we'd do the initial migration once on a backup snapshot, then lock down access to the existing Nexus 2 server, re-sync the snapshot to the latest data and then do the migration a second time (with the hopes that the second migration should be faster since)
Is this possible?
If so, will this actually decrease the downtime or will it attempt to reprocess the same files again?
The blurb is not entirely clear what makes this more complex and why it requires re-configuring the version 2 instance.
It might be possible but it is not really supported. The upgrade is incremental and can be done while the app is still running and serving users and continues to sync content. As such you can minimize downtime already.
I want to know what is the difference between installing HortonWorks HDP vs installing the components directly from Apache projects? One thing I can think of is that Horton works probably has the packages aligned so that the version of each component is compatible with that of the others within the suite, while getting them directly from Apache projects, I may have to handle version compatibility myself. Is that correct? Is there any other difference involved ignoring the support subscription aspect of it.
Thanks.
There are a lot of differences between "roll your own" and using a distribution. Some of the most obvious include:
All of the various components and versions have been tested and built to work together - incompatibility between versions (e.g. Hive, Hadoop, Spark, etc.) can be a painful problem to sort through on your own
Most distribution providers, including Hortonworks, will bring patches in from unstable releases into stable releases, so even for the "same" version (e.g. Hive 1.2.1) you're getting a better release than vanilla - these can include both bug fixes and "safe" feature changes
Most distribution providers, including Hortonworks, provide some flavor of centralized platform management. I'm a big fan of Ambari (the one that comes with HDP), for example - it makes configuration and monitoring significantly easier than coordinating a vanilla install
I would strongly recommend against trying to deploy vanilla, unless it's just for learning and playing. HDP community edition is free (both definitions) and a major improvement over doing it yourself. My last deployment of HDP was entirely based on the community edition.
Tools such as liquibase and flyway certainly make it easy to upgrade your database. What I haven't gotten straight in my mind is how to best handle changes that occur both on a release branch and trunk.
An example:
My code that is in product is version 2.5 and lives on a release branch. In the meantime, developers have started working on version 3.0 which lives on trunk.
A bug is found in production. A database change script is made (2.5.1) and committed to the release branch. The same change script must be merged back to trunk (3.0.1?).
Version 3.x is released into the wild production db's will already have the change from 2.5.1. The upgrade could potentially fail.
Conversely, if I'm creating a db from scratch if i was using a forward only strategy I would have the same change occurring twice (2.5.1 and 3.0.1).
How are others handling this scenario?
You are right to recognize that production DB changes will always be linear.
To solve this you should place DB migration 2.5.1 both on the branch and on trunk. And not create a 3.0.1 with the same changes!
This way it will be deployed with the branch, but also with trunk.
Upgrading production to trunk will then
find migration 2.5.1 and skip it, as it has already been applied
find migration 3.0 and apply it on the 2.5.1 db
There is, of course, an ever better solution. And that is to get rid of branches altogether and always release from trunk using to feature toggles instead.
I have a backup of a firebird database. I would know which version of gbak has made it and which version of firebird comes from.
Is it possible know this information?
PS: I googled a lot but I don't found a solution; the only workaround I found is try to restore with different version of firebird and gbak
The gbak utility of a Firebird version will be able to read all backup formats of earlier versions (in theory since InterBase 4.0, although that isn't tested anymore). So if you want to restore a backup just use the latest version of Firebird to restore the file.
Also if you need to restore to an earlier Firebird version, you can use the gbak of the latest Firebird. When restoring to an older Firebird version it is capable of restoring a new backup format to an older server (although if the backup contains features of newer Firebird versions those parts will not be restored or the backup might fail, and you will also need to recompile all stored procedures).
The only potential snag is if the backup was from a different endian system, and the backup was not made transportable (the default is transportable though).
Usually Firebird backups are stored in External Data Representation (XDR) format.
That means file contain only XDR backup version, not Firebird version or even Gbak version. Backup version is not directly related to Firebird version.
Also, XDR backup is back FB version compatible. If your DB doesn't have any new specific FB features, you may downgrade it freely by restoring it using old version gbak.