| Subject | Re: Re[2]: [Firebird-Architect] One way to scale Firebird put it on memory virtual disk or ramfs |
|---|---|
| Author | Dalton Calford |
| Post date | 2013-01-22T14:35:59Z |
Running in a RAM disk is the same as running on a hard disk in terms of
risk. I run multiple raid/san systems and they fail. Power fails, drives
fail, cpu's fail, drive controllers fail, cache controllers fail - you can
not rely upon any single aspect of the system and consider it acid
compliant. I even have regulated power from DC power plants with multiple
fail-over redundancy drive/network systems and they fail.
The only way to become fully ACID compliant is to house multiple servers,
in multiple nocs, with queries being run atomically upon multiple systems
in parallel so that if one system fails while processing work, the
secondary system can respond as it has already been doing the same work as
the primary. The clients and tiers need to be able to determine if the
answer they are getting is authoritative or non-authoritative. They need
to be able to deal with multiple responses to the same query and all work
is queue'd locally in case the entire local work process needs to be
re-applied (either immediately or delayed due to network latency/drops).
It is a very complex subject that involves the design of the pop, the power
for the pop, the full system redundancy for each cluster, with full drive
redundancy in the sans, with the client software and middle tier software
designed to handle a complete system failure and switch-over to a totally
different pop in a different city/province/country if needed.
Ram drives work, but I normally use them for the temp drive. The
benefits of ram drives depend upon the version of firebird, the version of
the OS and the hardware parameters.
If firebird is proposing going down that route, they would need to
implement some new structures in Firebird, mirroring some of the elements
that oracle and other database platforms have created.
risk. I run multiple raid/san systems and they fail. Power fails, drives
fail, cpu's fail, drive controllers fail, cache controllers fail - you can
not rely upon any single aspect of the system and consider it acid
compliant. I even have regulated power from DC power plants with multiple
fail-over redundancy drive/network systems and they fail.
The only way to become fully ACID compliant is to house multiple servers,
in multiple nocs, with queries being run atomically upon multiple systems
in parallel so that if one system fails while processing work, the
secondary system can respond as it has already been doing the same work as
the primary. The clients and tiers need to be able to determine if the
answer they are getting is authoritative or non-authoritative. They need
to be able to deal with multiple responses to the same query and all work
is queue'd locally in case the entire local work process needs to be
re-applied (either immediately or delayed due to network latency/drops).
It is a very complex subject that involves the design of the pop, the power
for the pop, the full system redundancy for each cluster, with full drive
redundancy in the sans, with the client software and middle tier software
designed to handle a complete system failure and switch-over to a totally
different pop in a different city/province/country if needed.
Ram drives work, but I normally use them for the temp drive. The
benefits of ram drives depend upon the version of firebird, the version of
the OS and the hardware parameters.
If firebird is proposing going down that route, they would need to
implement some new structures in Firebird, mirroring some of the elements
that oracle and other database platforms have created.
On 22 January 2013 08:51, Roman Simakov <roman.simakov@...> wrote:
> **
>
>
> 2013/1/22 Sergey Mereutsa serj@...>:
>
> > Hello Alex,
> >
> > and without shadow ACID rule has effect too - RAM-drive is the same
> block device as usual HDD - until power is not lost :)
>
> In this case you have ACI but have no D.
>
>
>
[Non-text portions of this message have been removed]