For what it is worth, I second the recommendation by Jeff. We used mirrors from
the day they were released many years ago. For critical data (like medical
data), that just cannot be lost it is the way.
It takes time to get the configuration you need figured out. There are
different ways to handle this depending on how hot you want a recovery server.
We needed as hot as we could get so here is what we did.
1. Have a second server with a complete backup on it of the data file.
2. The main server was set up to write the log files for the mirror consumption.
3. We wrote the log files to the local servers RAID 10 configuration (or RAID 5
from way back when).
4. At set intervals the logs files where moved over to the backup server, where
it imported in the log files.
This brings that server up to the moment of the last transaction in
that log file.
5. The main server creates a new log file for the transactions.
There are many choices to be made in the configuration.
1. Where to write the log files for the mirror. As technology changed we
changed where we wrote them to.
Considerations are:
- if you write to them over the network, what if the network is
unavailable - your logs are no good.
- if you write them on a local volume of the main server, what if the
mother board dies so you cannot access that last log file on the mirror server.
- you could write to a USB etc, volume mounted on the main server so
that if b occurs, you can physically move to the mirror server
All three of the above options have potential failures. Maintaining
good equipment is therefore important.
Using RAID drives with hardware RAID provides good storage failsafe.
2. What intervals to have new log files be created and sent to the mirror server
This all depends on the volume of changes to the data file on your main
server. Way back when we started, the OS file size limit was our limiting
factor.
We had several sites with ~ 130 users with heavy data change patterns. We would
be importing hundreds of thousands of lab results a day, plus required in
datafile pre change versions of records, and
much more. At these sites we would have data files very large, and
terabytes of data stored externally that they accessed.
Once you get all the mirror configuration figured out and tested, it was rock
solid for us. Like everything testing the configurations, monitoring, and
adjusting as necessary. We had a way
that if a log file was not consumed by the mirror, or still sitting on the main
server when a second new log file was created an automated check would notify
our support department. We
learned to have a lot of automated notices sent to us. When your reputation is
on the line to have reliable systems, I think it is critical to have automated
tests and notifications. Then if
a problem does occur, you can know about it, and fix it before the client even
knows there was a problem.
NOTE: I got out of that business in 2013 when we were using 4D v12. I am not up
to date on the latest mirroring configuration and issues. I suspect that what I
have said above still holds true
to a large degree. Those that are using mirror in v16, v17 can correct where I
am out of date.
Jody Bevan
> On Oct 28, 2019, at 11:06 AM, Jeffrey Kain via 4D_Tech <[email protected]>
> wrote:
>
> Or use a mirror. Highly recommended if the database is important...
>
>> On Oct 28, 2019, at 12:59 PM, JPR via 4D_Tech <[email protected]> wrote:
>>
>> The only 100% accurate way is to restart from the Backup file (made by 4D)
>> and integrate the current log file(s). This is the only way to be sure of
>> the data integrity.
>
> **********************************************************************
> 4D Internet Users Group (4D iNUG)
> Archive: http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub: mailto:[email protected]
> **********************************************************************
**********************************************************************
4D Internet Users Group (4D iNUG)
Archive: http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:[email protected]
**********************************************************************
