Using
replication you can keep your standby database few minutes or even
seconds behind the main one and when it crash, everything you need is
somehow redirect new connections to a new server.At first, a little
Just in case if anybody here doesn't know
Replication is a process of keeping two or more database in sync. It may include metadata as well as data. IBReplicator can replicate only data. Limited software. It can't even replicate generators!
But nevertheless there is a couple of things what
When your server burns with a flame, how long it will take of you to recover and how many data will be lost? If you have standby server and regular backup, it'll take as long as you restore the latest backup on new server. For gigabytes, probably, this time should be measured in hours and you will loose all work since last backup.
You can, of course try to make backup every hour, but I doubt that it can work. The situation become better with new nbackup in FB2, but still far from perfect.
Using
replication you can keep your standby database few minutes or even
seconds behind the main one and when it crash, everything you need is
somehow redirect new connections to a new server.
Scalability.If your Firebird server doesn't cope with all requests you are hammering it, you can hire two Firebirds... three Firebirds... best of all, of course, five Firebirds.
Firebird Superserver on one server can handle your OLTP tasks and Firebird Classic on another – heavy reports. Replicator in its' turn will keep the data on the second server fresh.
Now, we can go on right to
First step will be, of course,
Replicator's
installation process is quite ordinal. You run executable installer
and answer some typical questions. Here, if your OS supports
services, you can say installer to install replication server as
service and choose how it will be run: automatically or manually. If
you choose not to install service right now, you can do it any time
using command-line switches of ReplServer.
After the installation is finished you can run Replication manager and
IBReplicator is quite versatile and, unfortunately, can't read you mind. So, you have to inform it explicitly what and how you are going to replicate.
Configuration is kept in database. It may be dedicated database or an ordinary one. The latter is useful if you need synchronous replication.
I
create an dedicated one. Choose 'New Configuration', enter name of
server (in this case it is localhost and name of database, including
path. Field 'Comment' may be filled if you want to see some beautiful
name or kept empty. In this case you'll see connection string as it
is.
Now
configuration is created and we can fill it. As a first step you must
let him know something about
which will be involved into replication.
On the page 'Databases' I click 'New' and fill some data:
Name which is used everywhere to identify the database
Server is an usual connection string
Administrative user name will be used during management
Administrative password is also required
After filling all these fields but before saving, it is good to
check whether the data is right using 'Test connection' button.
In my case everything is right. And I can proceed to the next database. Everything is the same except priority. I'm setting it to lower value. You'll see results later...
After all databases are registered, we can
that define what, when, where from and where to must be replicated.
At this step you can
or
To
accomplish it just open schema generator, select tables and press
'generate' button. List of primary key fields and data fields will be
filled automatically for each selected table.
When schemata are defined, we should
that includes couple of tables and a lot of triggers – one trigger per replicated operation. Select first schema, source database and double-click 'Create system object' icon. System objects are created. Now select second schema. In some cases you may want create system objects not for a whole schema, but for single part of it: one target database or table. I select one table and click the icon again. Let's check: go to IBExpert and look at the database. Right, we see three triggers on our table. These triggers will log all operations performed in database, so when you run replicator it will know what has happened and what should be done in target database to keep it up-to-date.
One of features of Replicator 2.5 is a customizable replication order. One mouse click and schema 'Back' will be replicated before schema 'Forward'.
Now
let's insert some records. IBExpert has a useful tool for it –
test data generator. I'm opening it and choose table and fields. How
many records? A hundred? A thousand? Ten thousand? Who more? One
hundred thousand?! No, It'll take too much time. A few minutes, I
suppose. Let's insert ten thousand records. I press button 'Generate'
and it's started working. I can measure speed as about a hundred
records a second. Is it quick? I can't say. One the one hand the
table is very small and I would expect it working a ten times faster.
On the other hand, my laptop has just poor C3 processor inside.
In a meantime I can do another important step:
For this demonstration evaluation license is quite enough. I open license manager with “Tools->License Manager” menu and enter 'EVAL' as a license ID. License key is generated automatically. OK. Here it is: license has been successfully added. Now I can use this configuration for two weeks to replicate between up to four databases.
Because I'm too lazy to enter name of configuration database and credentials to access every time when replication server is run, I must set this configuration as a default one.
is opened by replication server every time it is run. It is especially useful when you run the server as a service.
Now
everything is ready to
I run it from Start Menu as an application for better demonstration. Running it as a service is a bit... hidden from eyes. As you can see, all details about my default configuration is already filled. I hit 'Replicate' button and it is running... And running... And running... And eventually, finish.
Now
I hit the button again and it is running again. But this time not all
is so smooth. Because I broke the rules and used incorrect user name
all the data is trying to go back. But appropriate records are
already exist in source database. Replication server cannot insert
them so, it try to update, but update is prohibited: I set conflict
resolution strategy to priority-based if you remember, and set
priority of source database to a higher value. So, all unsuccessful
replication is moved to a special depot, named 'Conflict log'. I can
inspect this depot using
As it is obvious from it's name, it's purpose is to let user solve conflicts by hand. I open this tool by choosing schema and clicking 'Replication->View Conflicts' menu. And here they are: all ten thousand records in one schema, one target database and one table. I can rule them together here or switch tab and see some details as I do now. A little pause – ten thousand records require quite a few time to be downloaded, but... here they are. Let's make the window a little bigger to see all provided information. And we see endless list of 'Priority is too low errors'. Here I have a few options which are quite obvious in my opinion. I can see actual data from source and target databases and this information can help me to make a decision. Forced replications will be executed unconditionally on the next run. If I delete these records like this, databases may be in inconsistent state which is not the case of course.
I doubt that anybody here is eager to press 'Replicate' button every time by hand. Much better would be
Switch to Replication Manager, open 'schedule' window and add one record: 'replicate periodically every 15 seconds'. Check 'Scheduler enabled' box. Now everything is ready. No, not so. Though we changed configuration, Replication Server has no idea about it. As I already said, it can't read minds. This time let's try remote control. Open menu “Tools -> Notify Server” and click 'Reload parameters'. Switch to server again – right, it says that configuration has been reloaded and button 'Replication Timer' is down.
I've finished demonstration and don't need this configuration anymore. I choose File->Drop Configuration menu. This is my last chance to change my mind because not only configuration will be dropped, but configuration DB as whole. No, wait, I don't want to do it right now: I forgot one thing. Before I can drop configuration I must
Because system objects are not a part of configuration, I have to drop them explicitly. Otherwise all DB operations will be still logged pointlessly.
I select first schema, source database, right... Now “Remove system objects”... Good! System objects in source DB are dropped. Let's check... Go to IBExpert, refresh... OK, no more system objects here.
Now the same for second schema, but this time I'll use menu instead of right pane. Good. Target DB is also cleaned.
Now I can drop the configuration. Am I sure? Yes, I am. Oops... Something is wrong... Oh, yeah: configuration is opened by ReplServer. Close it... Try again... Great! Now the configuration disappeared for ever.
And, finally, I'm
Control panel, Install/Uninstall Programs, choose IBReplicator. Remove now! That's all, folks!