On 6/8/07, <b class="gmail_sendername">Justin Moore</b> <<a href="mailto:wantmoore@gmail.com">wantmoore@gmail.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 6/8/07, Chris Mason (Lists) <<a href="mailto:lists@masonc.com">lists@masonc.com</a>> wrote:<br>> It would be better to let MySQL handle that - use the built-in<br>> replication facilities. It's easy to setup.
<br><br>That's a great idea for backup purposes, but if the OP is wanting true<br>redundancy, that won't help much. What happens then when the primary<br>box fails? CDR not written to the primary can't be replicated...
</blockquote><div><br>If it's only for the unlikely event that a DB server is unavailable, why not have it log the CDR in text and in MySQL? If the DB server is unavailable, the records could be parsed from the text file and the database updated.
<br><br>Of course, if you had to do this more than once or twice, it would get a bit annoying, I'm sure. But then again, write the script to do it, and use it to populate the other databases? Dunno, just thinking out loud here.
<br><br>I've written a few parsers, and the format appears to be easy to parse. It really wouldn't be too big of a deal. The hardest part will be kicking it off (I'd use cron), parsing the file (my personal preference would be perl or PHP), updating the database, and making sure you don't insert duplicates.
<br><br>I think I would use the UniqueID as they key, and then just use INSERT statements. You may need an IGNORE in it to allow it to keep going, even when there are duplicates. It's been a while since I wrote something to update a DB where I was unsure of the data hygiene.
<br></div><br></div><br>