Date: Fri, 1 Dec 2000 06:47:35 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: wes@softweyr.com (Wes Peters) Cc: tlambert@primenet.com (Terry Lambert), brett@lariat.org (Brett Glass), freebsd-chat@freebsd.org, freebsd-advocacy@freebsd.org Subject: Re: Here is what IBM thinks about using FreeBSD on their newer Message-ID: <200012010647.XAA09204@usr08.primenet.com> In-Reply-To: <3A273BC9.871DDF66@softweyr.com> from "Wes Peters" at Nov 30, 2000 10:48:57 PM
next in thread | previous in thread | raw e-mail | index | archive | help
[ ... postgres doesn't support replication ... ] Too bad; it's a requirement for my application. 8-(. > > I don't have triggers in the code, but I actuall have MySQL > > set up for mutual replication via log replay, so that the > > database and its replica stay more or less synchornized. > > What sort of replay interval do you use -- more or less continuously? Yes. It will effectively check every few minutes, and replicate data not involved in an active session. An active session will, by definition, have data private from all other sessions, and it is this data that I'm interested in replicating (and only this data). If I had a trigger, I could delay the response to the client until after the trigger had notified the replicas to replicate, and they had done so (still have the problem of a downed server, though). > I find MySQL to be unstable and rather toy-like compared to PG, > which I've not had a single problem with yet. The enumeration > types in MySQL are missed, though. Other than having to become the defacto AIX port maintainer to use it on AIX and have any real chance of being able to upgrade and have the next version work, I don't really have a problem with MySQL (at least technically; I dislike its new license as much as its old, but it's tactical, not strategic, so I don't care that much). The biggest problem is new data creates, and that's handled by assigning record numbers partially based on a common space, and partially on a reserved per server space. This lets me create records without an inter-server interlock, since I know all records created in one server will be prefixed with one 8-bit value, and all records in the second server will have a different 8-bit value. Obviously, these values are externally configured, rather than being in the database. 8-) 8-). The delete replication problem is more ugly; if I get a server that is not the same as my previous server, and I deleted on a previous server, then when I iterate "my" records, I will see deleted records "reappear" until the delete is replicated. This problem also exists to a lesser extent in other data change operations. Creates are really not a problem, since connecting to server B, after a create on server A, before replication to B, means that the unreplicated data object is still "on its way" to server B. Since I have a data object propagation delay from external store and forward processing to get into A in the first place, I can treat the data as "on its way" with no ill effects. The round-trip from a client back to the same client also has a latency, so even if a client sends a data object to itself, a delay in propagation to the "slave" (all servers not getting the data first are effectively "slaves") just looks like normal latency. I can maintain "synchronized/unsynchronized" state in an external directory (I have an LDAP directory specifically for this type of state information), but I have to modify LDAP replication to have an "active listener list" off the master for this to be efficient (the interval is like the TTL on an SOA update on a DNS sever with notifications turned on, when using a stealth primary, and doing DNSUPDAT against the primary, but reading from the secondary; I basically have to implement "notifications" for LDAP). With this information in hand, I could support an "unsynchronized" DN that I would use, if present, to bind to the up to date server, instead of attempting to load-balance. I'm at a loss as to what to do about the case of a delete-unsynchronized-crash, since it means that I can't use the replica until its synchronized. I have the same problem with new data on the way in, since I want to write it to the "most current" server (obviously), so I would have to seperately queue that data until it could be delivered (ugh). I would also be introducing a single point of failure, since like DNS, the relationship between LDAP replicas is also "master/slaves", so if the master goes down, an attempt to change data in a slave would result in a referral to the master, and the master is down. I _could_ define all unprocessable updates as "in progress", but then the "most recent" state tracking becomes queued, as well, so I couldn't permit deletes/changes until after propagation. Getting sick yet? 8-) 8-| 8-( 8-P 8-O... Anyway, it's an interesting problem. Not storing volatile state in the directory, I'm currently sitting at a single point of failure only on the servers which serve the data, since I have to marry the client to a particular server, and keep a hot spare standing by on the otherside of a dual ported RAID array (ugly, but it works; I supose I could use AFS, as well, but CODA doesn't cut it, and neither does NFS). Hope you're having as much fun in your project. }B-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012010647.XAA09204>