Difference between revisions of "Update Replica Databases"
(→What is a replica database?) |
|||
Line 32: | Line 32: | ||
Your test system is intended to be used as an environment where you can try out new things without running the risk of accidentally breaking or removing important settings or data from your live system. | Your test system is intended to be used as an environment where you can try out new things without running the risk of accidentally breaking or removing important settings or data from your live system. | ||
For example, if you want to make changes to user access, or make major changes to a project, but want to test the changes first to make sure they work in the way you want. You can do this here first to see the results without interrupting any work being done by other users on the live system. | For example, if you want to make changes to user access, or make major changes to a project, but want to test the changes first to make sure they work in the way you want. You can do this here first to see the results without interrupting any work being done by other users on the live system. | ||
− | Test systems are updated on the first day of each release cycle, in order to let users become accustomed to any changes that may have been made in the new version. For more information, see | + | Test systems are updated on the first day of each release cycle, in order to let users become accustomed to any changes that may have been made in the new version. For more information, see [Updates] |
[[File:Test login.png|border]] | [[File:Test login.png|border]] |
Revision as of 08:46, 25 September 2023
What is a replica database?
Replica databases are direct copies of your live database. They are useful if you want an environment to train new users or test different features and settings without having it affect your actual data. Anything done within a replica database will not affect your live system in any way, and will not interfere with any work being performed by users in the live system.
It is important to note that any data inside a replica database will be wiped after 6 months of inactivity. Activity is defined as either a user logging into the replica, or the replica being updated from the live system.
There are different types of replica databases that are available to you. If you do not have one of these replica databases, you can contact the support team to request that one be created for you. The different types of replica databases are functionally identical, though are differentiated by different names so you can keep track of what each is used for. The different types of system available to you are as follows:
Live:
Your live system is the one users usually log into. This is where your "real" data is stored and used.
You log into this system by using the basic organisation login details you have been given.
Test:
Your test system is intended to be used as an environment where you can try out new things without running the risk of accidentally breaking or removing important settings or data from your live system. For example, if you want to make changes to user access, or make major changes to a project, but want to test the changes first to make sure they work in the way you want. You can do this here first to see the results without interrupting any work being done by other users on the live system. Test systems are updated on the first day of each release cycle, in order to let users become accustomed to any changes that may have been made in the new version. For more information, see [Updates]
You can log into this system by adding "test" on the end of your organisation login name and password.
Training
The training system is intended to be used as an environment in which you can practice or train users on how to use the Charitylog/Crossdata system. A common use for this is to teach new staff members how to enter and manipulate data, as it allows them to practice without the risk of altering real data.
You can log into this system by adding "training" to the end of your organisation login name and password.
Temp
The temp system is just a general purpose replica, for whatever other uses you may have.
You can log into this system by adding "temp" to the end of your organisation login name and password.
First-time setup
Before you log in to your new replica database for the first time, you will need to go through some setup steps. Replica databases use a variation of your live system's password, so in order to assign this password to a new replica, you will need to go through the password reset procedure to update the replica's login details.
This is done by going through a first-level password reset on your live system. You can reset the password the same one you are currently using if you do not wish to change this, but you will still need to go through this reset procedure in order to update the replica.
You can do this by going to: Admin menu -> General settings -> Organisation details -> Organisation password
Once the password has been reset here, you can move onto the next step to populate the replica with your data.
Updating a replica system
Updating a replica system will erase any data currently stored on the chosen replica, and then replace it with a direct copy of the live database. Updating a replica database is required before users can log into it for the first time. As mentioned above, the replica databases will have their data erased after 6 months of inactivity. If this happens, users will be unable to login, and the replica will need to be updated again.
Your replica systems can only be updated from your live database. You can do this by going to:
Admin menu -> Database operations -> Update replica databases.
Alternatively, you can use the search bar in the top right of the page to find this.
Once on this page, you will be presented with a list of the replica databases which have been created for your system. If you wish to add an additional type of replica database, you can contact the support team to request this. Select the replica(s) that you wish to update, and and additional update options shown below. Once you have selected these options, you must type in the security word displayed. This is to ensure this process is not initiated by mistake.
After entering the security word, click the "Update" button to begin the update process. This can take up to 5 minutes depending on the size of your database.
Once the update has finished, you will be taken to a page which will show the status of the update and if it was performed successfully. If the update was successful, you may now log in to your replica database (see above for logins).