I am researching the possibility of using Firebird for a project.
However, one potential problem is replication and failover, or rather, lack of a (subjective) "good" solution. There are several potential solutions listed in the Firebird FAQ but they are either 1) Windows-centric; 2) horribly outdated; 3) commerical; or 4) not full-featured.
The only potential option I see is FIBRE and that looks 1) immature; 2) potentially dead; and 3) not full-featured.
I've learned about DRBD and Heartbeat and these solutions look promising. I am looking for your feedback should you already have 1) setup a replicated Firebird configuration; and/or 2) used DRBD with Firebird.
Any "gotchas", recommendations, tips, etc.?
Thanks!
There is one session about replication in Firebird Conference 2009
Holger Klemt
* Firebird Replicated Part 1
* Firebird Replicated Part 2
o In this two sessions you will see how easy it is to implement
your own replication system in a
Firebird database. Based on triggers
and simple scripts, your can create a
live backup system. The architecture
allows master-master, master-slave,
multi-master, online and offline
replication. The replicated Firebird
cluster can be used by any client
without interuption, also in the case
of partial hardware failures, planned
hardware and software maintenance
operations, for example the switch to
a new Firebird version.
We have been using DRBD/Heartbeat/Pacemaker Solution for the last 2 years for exactly the same problem. To keep Firebird databases up and running and failover. The setup is actually quite easy and I have a few suggestions that I will give you to get a head start. So these are just suggestions ...
create a drbd partition, format it and mount it to /data (with pacemaker of course)
put your aliases.conf to the drbd partion, so you won't have to change the aliases.conf twice everytime you make a change to it. Copy the aliases.conf file to /data and link it to /etc/firebird/2.1/aliases.conf on both nodes
The downside of using Drbd/Pacemaker in a Primary/Secondary setup is that the clients will loose the connection as soon as the primary node dies and until the secondary node is up. The will have to reconnect. I haven't really found another way arround that, although the firebird client should allow a connection timeout it never really worked with our applications (maybe the applications or the libraries we use don't really use the firebird connection timeout).
As for database replication, I am afraid you have to go the way as Hugues Van Landeghem decribed or quoted it. We developed such an application, that works with triggers. So a new line is added to a table, a trigger copies the key of the entry to another table which is constantly read by an application which grabs that entry and inserts it to another database. Quite ugly but it works just fine! I personally think Firebird should invest some time in having their own datbase replications system...they are really far behind...
Hope my information helped you a little bit. I have further questions feel free to contact me or visit my site # gefoo.org
Related
I am looking for a (SQL/RDB) database setup that works something like this:
I will have 3+ databases in an active/active/active configuration
prior to doing any insert, the database will communicate with atleast a majority of the others, such that they all either insert at the same time or rollback (transaction)
this way I can write and read from any of the databases, and always get the same results (as long as the field wasn't updated very recently)
note: this is for a use case that will be very read-heavy and have few writes (and delay on the writes is an OK situation)
does anything like this exist? I see all sorts of solutions with database HA configurations, but most of them suggest writing to a primary node or having a passive backup
alternatively I could setup a custom application, and have each application talk to exactly 1 database, and achieve a similar result, but I was hoping something similar would already exist
So my questions is: does something like this exist? if not, are there any technical/architectural reasons why not?
P.S. - I will NOT be using a SAN where all databases can store/access the same data
edit: more clarifications as far as what I am looking for:
1. I have no database picked out yet, but I am more familiar with MySQL / SQL Server / Oracle, so I would have a minor inclination towards on of those
2. If a majority of the nodes are down (or a single node can't communicate with the collective), then I expect all writes from that node to fail, and accept that it may provide old/outdated information
failure / recover scenario expectations:
1. A node goes down: it will query and get updates from the other nodes when it comes back up
2. A node loses connection with the collective: it will provide potentially old data to read request, and refuse any writes
3. A node is in disagreement with the data stores in others: majority rule
4. 4. majority rule does not work: go with whomever has the latest data (although this really shouldn't happen)
5. The entries are insert/update/read only, i.e. there will be no deletes (except manually ofc), so I shouldn't need to worry about an update after a delete, however in that case I would choose to delete the record and ignore the update
6. Any other scenarios I missed?
update: I the closest I see to what I am looking for seems to be using a quorum + 2 DBs, however I would prefer if I could have 3 DBs instead, such that I can query any of them at any time (to further distribute the reads, and also to keep another copy of the data)
You need to define "very recently". In most environments with replication for inserts, all the databases will have the same data within a few seconds of an insert (and a few seconds seems pessimistic).
An alternative approach is a "read-from-one/write-to-all" approach. In this case, reads are spread through the system. Writes are then sent to all nodes by the application (or a common layer that the application uses).
Remember, though, that the issue with database replication is not how it works when it works. The issue is how it recovers when it fails and even how failures are identified. You need to decide what happens when nodes go down, how they recover lost transactions, how you decide that nodes are really synchronized. I would suggest that you peruse the documentation of the database that you are actually using and understand the replication mechanisms provided by that platform.
I am interesting is there any solution to have two physical machine, with Microsoft SQL servers 2012 that work on the same database. somthing like Cluster just with bothe node to be active... Any idea?
Microsoft SQL Server does not support a 'real' load balancing scheme out of the box. AFAIK, this is still true with SQL Server 2012. (Someone will enlighten me if I'm wrong.) It doesn't matter if we are talking about database mirroring or AlwaysOn or clusters.
(In order to hammer that point home, MS seems to call SQL Server clusters "SQL Server failover clusters" lately. Pedantics.)
If you want to load balance your databases, you have to do the hard work yourself with some sort of sharding, federation or replication. (Note that federation (by views) has been in the product since SQL Server 2000, it just wasn't very popular.) And, of course, that would mean modifying either your databases or the apps themselves, which is almost always either too much work or violates your vendor agreements. With 150 databases, it's just that much more insurmountable.
You can have an active-active cluster, but the thing is that you would have to carefully distribute your databases on your nodes to divvy up the load. With 150 databases, this might be more granular than if you just had five databases, but if you have one database that is a ton of load and 149 that are light-weight or rarely used, you might still find one machine bogged down and the other isn't. And, some databases are busy sometimes and hardly busy at other times. Which means that everything might come down to when a user decides to run some heavy process.
Of course, you have to be able to support all of that load on a single node when you fail over, for whatever reason, even if it is something mundane like patching Windows. If you only patch during known slow traffic periods, that's great. If you don't have slow periods, or if the failover occurs because the hardware actually has a fault, the other node might not take the load and your users will be out of luck. If you think about it like that, having the second machine "doing nothing" isn't quite so irritating. At least you know that it will take all of the traffic that the primary usually does.
Yes, you can can two databases active sharing the same information and replicating it back and forth. This is referred to as "Merge Replication". In this configuration, both nodes can accept read and write transactions.
How Merge Replication Works
The company I work for would like to use Always on availability groups architecture in our SQL Server supported application. we have 3 databases straight off of installation and one of those is partitioned by configuration, we currently use MSDTC to coordinate transaction between the three, i.e. if committing to databases A and B, and A commit succeeds, a failure on B means a rollback on A and B as opposed to just B.
We ran into an issue when we saw this article
from my understanding this basically means MSDTC is not supported in an Always on availability group mode.
I could not find a replacement for this in SQL server 2012
So my questions are:
What options do we have (Shelve or open source Product/Code change)?
What is specifically the impact of running MSDTC in this setting (complete crash/missing transactions)?
Thanks in advance, your help is greatly appreciated.
Dor
I recently asked a similar question at: https://dba.stackexchange.com/questions/47108/alwayson-ag-dtc-with-failover
> What options do we have (Shelve or open source Product/Code change)?
I think you have two options:
Change your app so that it does not need DTC.
Change your database setup so that it does not use Availability Groups.
In my circumstance, we're using a commercial app so option 1 is not viable. We are currently using database mirroring and based on recent research I now understand that that is also not supported.
My take away is that it is possible to make it work. But it's not simple to do and it puts you in an unsupported situation - which is not acceptable for us. Therefore, I plan to look at utilizing log shipping and change from having a hot standby (with mirroring) or a warm standby (with log shipping).
What is specifically the impact of running MSDTC in this setting (complete crash/missing transactions)?
If you do decide to make use of DTC with Availability Groups or mirroring you run the risk of having corrupted/inconsistent data in a failover scenario. The article you cited gives a good example of how that can happen.
Admittedly, with Log Shipping the same issue can occur. The argument I plan to make is that with log shipping we'll have the ability to roll to a specific point in time and we can make sure we only move to a point in time where we know everything is consistent.
The commercial app we are using does not support high availability. This is our attempt at making it highly available.
I need SQL to be running on 2 data centers(DC) active/active.
There are tonnes of challanges to be done here and below are my requirements.
Data synchronization must be async. (For higher performance)
I need to be able to read/write on both DC
When Site1 goes down, all the traffic will be routed to Site2 and when Site1 comes back live, traffic will be shared again. In this case, data must sync back within 1-2 hours (based on down time obviously)
SQL Transactional replication or other SQL replications seems not a good option because of the following.
a. If replication breaks, building back the replication will require 500GB to be transferred to the other Site.
b. We need to break the repl sometimes to make changes such as adding new tables or changing primary keys.
c. Sometimes for what ever the reason, that replication breaks by itself and even MS cannot find solution to that.
d. I am not sure if peer to peer replication will resolve this.
e. Merge replication seems scary and we don't know its implications that much and we don't want to carry extra GUIDs.
Today it will be 2 DCs but tomorrow we will add some more DCs and with possibility having one in Europe and one in Asia.
Desirable latency in replication is MAX 15 mins.
Most of all, I need a solution without a headache or with minimal.
We are getting EMC recovery point but that does not help me in ACTIVE/ACTIVE scenario as it is only DR.
I've evaluated the following productions and none provide me workable DB on the other end.
I will appreciate your help on this issue.
Thanks in advance
The only active/active option for SQL Server is replication. There is no other active/active option for SQL Server as of this writing.
We are using Replication and seem to be having endless problems with it. It seems to shut down for unknown reasons. It needs to be shut down to remove a column and only starts back up half the time. Does anyone have any advice on how to properly use replication or some alternatives to it.
Edit:
We are using Sql Server 2005, We cannot use database mirroring as we used the other database for reporting. As far as I am aware you cannot query from a mirrored database.
If you need just couple of tables from your DB for reports, replication is more useful, but you also can set up log shipping with secondary server in STAND BY mode (especially if you need significant part of your data for reports), then you can run reports on secondary server. You just have to remember that log shipping will interfere with transaction log backups, so you have to use the same folder with log backup files for both processes.
I would think the combination of database mirroring and database snapshots will solve your issues.
First, database mirroring is very easy to setup and I have never had any problems with it (using it for the past 4+ years).
Second, creating a database snapshot on your failover server will allow you to run reports. You can setup a sql agent job to drop and re-create the snapshot on whatever acceptable interval you like.
Of course this is all dependent on if you need your reports to run on real-time data or if they can be delayed somewhat.
Here are a list of the problems that I have had to resolve to get replication working:
1) The replication sometimes lies to me and tells me this, even when its working fine.
"The server 'Bob' is not a Subscriber. (.Net SqlClient Data Provider)" I have tried to re-initialise it thinking that it was broken and it never was...
2) It can take a little while to restart itself, especially if your remote DB is on the other side of the planet, which it is in my case. If you are on a slow network connection, or it is not 100% reliable, then you can have problems. Also, the jobs which restart the process can sometimes take a while to run, which also delays things further.
3) Some changes require full re-initalisation which involves sending a new snapshot out. If you don't have your permissions quite right, and you can re-initialise manually, but it doesn't happen automatically, then this can be a another reason for problems.
We have a SQL transactional replication which runs perfectly happily. You seem to say that it is when you are making schema changes to the publisher that you get problems. Each time we do a schema change we drop the publication, subscription and the subscription database. Do the change, then re-build it all. We can do this becuase we can tolerate the time it takes to re-apply the snapshot. There are ways to apply schema changes to the publication and have them propogate to the subscriber. Take a look at sp_register_custom_scripting. We have made this work once, so I can give some more information about it if you need.
As #Jason says, you can report from a mirrored database by using a snapshot. Beware that the snapshot will take up space, and cause more work for the mirror server. Although how much space will depend on how much data is changing and how big your original database is. We do use a snapshot on a mirrored database for occasional reports because our entire database is not replicated.
log shipping http://msdn.microsoft.com/en-us/library/ms187103.aspx
What version of SQL Server are you using?
We're using replication now for a particular solution, and it seems to just work, day in, day out.
I would examine your event log's, and SQL Server logs to see if you can determine why it is shutting down, and why it doesn't start up.
Are you possibly patching the servers, or are you having network errors?
The alternatives to replication are log shipping, or database mirroring.
I personally prefer Database Mirroring, but it really depends what you're trying to do, as some of these aren't appropriate for certain situations.
We also have used SQL transactional replication. We had the same pains with updating schema, which requires dropping the publication on all servers, performing the updates, and then reinitializing replication, and hoping for the best. Sometimes it would not initialize, or a node would fall behind and we'd get little warning for it. A few times we even lost all the stored procedure execute permissions causing pretty much total failure on the websites.
We have a rather large database so reinitialization could take quite some time, meaning all updates had to be done at 2am on Sunday - not exactly when we're awake and alert and able to use all our faculties to deal with a problem that might arise.
We are ditching replication in favor of failover clustering on SQL 2008, but it can still be done all the way back to SQL 2000.
http://technet.microsoft.com/en-us/library/cc917693.aspx