We are looking for reference customers who have successfully achieved, via using local-mail replication with new-mail polling, these two requirements:
Receive new mail in the in-box very shortly (i.e. within 1 minute) of it arriving at the mail server (either the primary or the backup if it goes down).
Fail-over seamlessly (no user intervention) in the event of a mail server outage.
If this applies to you please respond to this posting.
Seamless fail-over is only really possible if the user is working from a local replica, otherwise if the user is actively working on an e-mail message when the server goes down, they can not save it somewhere and they just loose it.
Having said that, most user’s do not like working from a local replica because they have been trained that e-mail should now be instantanious. In a lot of cases, users will be either on the phone ir chatting with someone and the person will say something like, I just sent you that e-mail, did you get it? They say no, and the next call they make is to the help desk to say, I am not getting my e-mail.
I really like replication and work in that mode exclusivley. However, in a lot of cases where I have setup replication for a user, I generaly have multiple location docs. One for in the Office, where the user is directly connected to their mail server and using the mail file on the server. One for total off-line use, that stores any changes but does not attempt any connection back to the office. And a third that is configured to use our pass-through servers and a local replica of the user’s mail file.
In short, using a local replica here, usually means that the user has requested it because they have a need for it. I wanted to make it the standard when we went to v8.x but with the investments we made in new hardware, the argument was why. Why have new kick arse servers and have the user using a local replica of their mail.
It’s apples and oranges, I know. But then that is management for ya.
I haven’t found any practical way for remote users to receive mail instantly. We’re at the “replicate mail when your Blackbery buzzes” stage. A one-minute replication interval for high-priority databases, and then making mail the only one marked, should work at LAN speeds.
Failover should be completely transparent when working on the local replica. In fact, I’ve seen problems where users outside the office fail over to a backup server, outside the cluster, due to Internet issues, and then keep hitting it because they have “use last successful” selected.
Why are you using a Local Mail Replica if you have a connection to the server that can pull an email every 1 minutes? Why wouldn’t you use the server mailfile to get the new mail prompts and view the new messages? (If you need to have an updated replica when you disconnect, set it to replicate every x minutes* and on shutdown.)
If you have clustered servers, when on the server or replication, failover is seamless with the exception of if you are in the process of editing a document on the one server when it goes down, then you hit save. This has been demonstrated time and again in our environment, as we deliberately test our backup data systems.
Replication every 1 minute can be problematic, as this might not be enough time to bring down all new data, and you end up with a continuous replication cycle…which, if you can handle continuous replication, then I ask again, why aren’t you just live on the server?
There is actually a very good reason for doing this; slow WAN links that don’t allow for a good user experience when running Mail directly off the server. We’ve have ~400 users configured in this manner (including Domino clustering).
Replication doesn’t need to be every 1 minute, make it hourly for other DBs. You just need a connection to the server such that when mail arrives, Domino tells your client to replicate the mail db.
Subject: Agree with Maria - it does not make sense
In addition to what Maria’s arguments are you need to consider the following:1. Will only mail be checked.
How many databases are on the Replicator Tab.
How much and how often do docs in those databases get changed.
Impact of nupdate on the mail file/box.
Unnecessary polling for new mail by the client to the server to check for new mail.
Take a look at this document for IBM’s recommendation/testing
Additional info on nupdate:
Nupdate.exe - what it does.
Nupdate.exe does not only update full text indexes, but views. In respect to views, it also will update any view that has been opened when changes are made to the database. In a case scenerio, I’m assuming that the changes would be due to replication. Each time you replicate the database, within a specified timeframe (say 15 minutes), the indexer (nupdate.exe) will kick in to update any of the views in the following databases that were open.
Nupdate.exe will only update views which have been opened in the copy of the database. Sometimes, a database’s unused views are unnecessarily indexed. If [CONTROL+SHIFT+F9] is pressed while in any view of a database, all views in that database will be indexed, regardless of whether or not they have ever been accessed. Making a new replica of the database in question will result in only necessary views being built when the database is subsequently indexed.
Update the Interval time:
Although Update checks the queue every 5 seconds, it does not refresh views at the same interval. Instead, it uses what is known as the Update Suppression Time. With Suppression Time, Update waits for multiple, similar requests to be deposited in the queue and then batches them. In this way, Update processes all changes to a database at the same time. Since the Indexer is the most CPU-intensive task, batching requests reduces the performance impact significantly. It is only after the Suppression Time has passed that Update forces the update of the view collection and the full text indexes as requested. By default, the Suppression Time is 5 minutes; however, this can be overridden with the following NOTES.INI parameter:
We have been moving our users (LAN and WAN) to a local replica configuration, utilizing a single location document so they no longer have to switch back and forth. Currently using Notes 8.5 clients.
We are testing the modification to the location document to utilize mail polling (Mailfile Local, mail addressing - Local then Server) and it has been sucessful so far. In test we we are workign with replication for all databases set to 60 minutes, replication is being triggered on LAN within 2 minutes when new mail arrives.
We have clusterd servers and failover has been working wonderfully.
Are you using this parameter?POLL_REMOTE_MAILFILE=1
This will tell the client to do a quick check with the user’s mail server to see if there is new mail for that user. If so it will then kick off replication immediately. The quick polling is very lightweight - does not cause much of burden on the server.