On 21-11-2011 06:20:36 +1100, Hedge Hog wrote:
We would like to be able to update each table while not affecting the availability of any other table. The table_db's are not horizontally sharded, i.e. all the data for a query will always come from that one table. We cannot use udp multicast/broadcast so a monetdb cluster is not possible (unless a localhost cluster is possible/sensible?).
On a local machine, monetdbd "knows" all local databases, pattern matches might fail, if discovery broadcasts aren't seen by monetdbd itself.
The setup+workflow: - one table per database (this allows for independent table updates), let these be
. - update a master (writable) instance of the table on a 'special' monetdbd/machine. - copy the updated table to each machine. - To update the table on a machine: $> monetbd lock $> monetbd stop $> mclient -u monetdb updatefile
Does this work? monetdbd was designed to refuse to start
$> cat updatefile copy into MyTable from ('path_to_mytable_col_file_i', 'path_to_mytable_col_file_f', 'path_to_mytable_col_file_s'); $> monetbd release
$> monetbd start Is the above the best pattern/architecture of monetdb for such a use case?
Appreciate any insights people can offer
Do you, or don't you use a cluster in the end? If so, you probably can use rsync as well to sync the dbfarm/dbname directories of the ones you load new data into.