Slashdot Mirror
.org TLD Now Runs on PostgreSQL
johnnyb writes "The .org domain, which has long run on Oracle systems, is now being transferred to a PostgreSQL system. I guess we can now dispel the "untested in mission-critical applications" myth."
← Back to Stories (view on slashdot.org)
Verisign runs the shared registry with Oracle, but the registrar-specific data was and still is stored using Ingres.
org. is tld (top level domain).
. (dot) is the root.
the story on the wasted 98% was about the . (dot) root servers, not about a tld server. you (and sadly, too many others) should read rfc 1035.
Acts@core.mailboks.com Acrux@core.mailboks.com Adam@core.mailboks.com Adar@core.mailboks.com Ada@core.mailboks.com
Someone who worked for the State of California, perhaps? There were a bunch of people who lost their jobs over that debacle.... See here for more info.<wry grin>
Catherine
...that the entire O'Reilly Practical PostgreSQL book was put online?
;) Looks like it is time to revisit postgres, especially for some db-agnostic PEAR apps I'm building. For me, it's the subselects that really make it worth the effort.
I've spent so much time lately in the (relatively) flat-table world of MySQL that I had forgotten about inherited tables, subselects, constraints in table definitions, and oh yes, vacuuming.
http://tinyurl.com/4ny52
The database is a buffer between the requests comming in from the registrars and the DNS resolvers. So you get a bunch of requests comming in once a day saying stuff like 'change asm.org DNS to 10.2.3.243' and the registry has to decide what to do with them. To do that they need to have a bunch of info stating what registrar owns the account at the time and so on. And yes it is not unknown for registrars to attempt to do things they should not.
The DNS infrastructure that is queried by you DNS server is completely separate. Every hour or so the SQL database will do a dump which will then be checked and if it passes will be sent to the production DNS infrastructure which is essentially a read only affair.
So no, this does not mean that every DNS lookup in .org is going to result in a mySQL transaction. Nor can you say anything about whether this deployment proves mySQL is ready for primetime, at least not yet you can't. You probably want to wait to see how the zone holds up over the next few months before drawing any judgements.
BTW the technical name for Oracle features is 'complications'.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
The real problem with Postgresql, however, is that if you are doing lots of updates where the keys increase forever, the index files grow forever. You can, of course, drop and recreate them (which we do in a cron job), but in a real 24/7 environment you've got a real problem when your queries all turn into table-scans because the indexes aren't built yet.
Here is some more information (seeIndex Maintenance? )
The only option I know if is to have two sets of tables and swap between them.
-- ac at work
The transition details can be found on the Public Interest Registry's Homepage. In short, they'll close the registry at 14:00 UTC tomorrow, transfer to Afilias's systems, and reopen the registrations on Sunday at 23:00 UTC.
Yes, you are wrong, as of PostgreSQL 7.2 VACUUM can run without locking the table completely.
Garbage collection is a problem every database faces. Due to ACID requirements it is pretty much (absolutely?) impossible to run a database that updates rows without having multiple versions of the same row on disk at some time during the operation. So at some point in time you have to get rid of that duplicate. You can choose to do that after commit of a transaction (or the last transaction for which the row is still visible), but that would potentially make every transaction slower. So in PostgreSQL the choice was made to do this at an administrator determined moment (and I presume that choice also was the easy one).
In older versions of PostgreSQL VACUUM would lock the entire table and physically force all the valid rows to be rewritten consecutively and then reclaim the space at the end. This mode is still available as VACUUM FULL, but nowadays there is a new mode (sometimes called lazy vacuum) that only marks space safe to be overwritten. Subsequent updates/inserts will overwrite it eventually.
Regular running of this command will eventually lead to some steady state where there is some x% of bloat in the table, but there is no significant amount of locking required.
Because...
Unfortunately, I haven't found new data, but here is a list of January 2001. .com: 21,174,751 .net: 2,806,721 .uk: 2,078,474 .de: 1,732,994 .org: 1,614,740 .nl: 416,842 .kr: 325,203
...
The top ranks are:
1.
2.
3.
4.
5.
6.
7.
The numbers have certainly changed since then, but perhaps the ranks are still similar. Maybe someone has found new data?