This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/members-discuss@ripe.net/
[members-discuss] RIPE DB NRTM access.
- Previous message (by thread): [members-discuss] RIPE DB NRTM access.
- Next message (by thread): [members-discuss] RIPE DB NRTM access.
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Andrea Cocito
andrea.cocito at ifom-ieo-campus.it
Sat Jan 7 23:54:57 CET 2012
Hi, On Jan 7, 2012, at 11:18 PM, Pawel Tyll wrote: > Like I said, file size isn't a problem. Unnecessary processing > required due to irrd restart is a problem. That's a bit different from the initial point... I do not know enough about irrd to comment on this (I just never runned it here), the things we mirror here are MySQL backed and in some way our sysadms convinced MySQL to accept that at some moment some read-only tables get replaced on the fly with new snapshots and that happens magically and atomically. Maybe RIPE might put in some directory one file per day with the "daily updates" and that directory can be rsync'd ? My point was only about the data transfer, I understand that setting up a "push" update requires a significant administrative/management overhead, and it is reasonable to ask for a cost compensation; setting up a public rsync server requires no more effort than setting up a public ftp site (maybe less...): the big dfference is that (as long as data is uncompressed and unencrypted) only the "delta" gets actually transferred. Regards, A.
- Previous message (by thread): [members-discuss] RIPE DB NRTM access.
- Next message (by thread): [members-discuss] RIPE DB NRTM access.
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]