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 <table_db>.
- 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 <mytable_db> $> monetbd stop <mytable_db> $> mclient -u monetdb <mytable_db> updatefile
Does this work? monetdbd was designed to refuse to start <mytable_db> here.
$> 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 <mytable_db> $> monetbd start <mytable_db>
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.