So yeah, the correct way to do this is with clustering/replication. Here's some incorrect (but probably functional in special cases) ways to do it:
If you're using MyISAM on ZFS or some other filesystem that can support snapshots, you can lock the table for write, issue flush tables, snapshot the filesystem, then unlock tables. Then, go into the snapshot, copy all the files out, and load them up on the slave server. Of course, getting them into the slave server is kind of a reverse of the above procedure, except there's a delete&move instead of a reverse snapshot. Note: I would not seriously recommend this to anyone on a production system.
You can write a script that creates temporary tables on the slave system using the definition of the tables you're going to be replicating to, then connects to the master system, does a select * and copies the results into the target memory tables, then when they're all done, lock (or transaction) the tables and copy the data from the memory to the real tables (ie, delete then replace, or replace and then delete); then, unlock and wee.
Both these require effectively no downtime (depending on your table sizes etc it may lock the DBs for a brief time, probably at most a few seconds, which is probably fine if you don't do it too often.)
Both these solutions however are not great in that they create load spikes, and result in periods between syncs where the slave data is not up to date. You didn't specify you needed that in your question, hence the suggestions, but just pointing out that if this is in fact required, then yes, you need replication.
I use something like the first idea to do backups on a very specific DB server we have (and they work fine) and the second to sync data from an upstream source I do not control down to a server I have control over so that I can work with the data. Like I said, no great general solutions there, but in those specific cases they work a treat.