provided by Star2Billing S.L.

Hello!

Inbound calls are blocked, when we backup the database.

But what happens - if some calls are finished at that time while we backup the database, are those calls information inserted into the database or not?

Anybody noticed about it?

I believe blocking is only a problem when using MySQL, as it doesn't implement ACID at all. Using Postgres, with its MVCC, you shouldn't experience this problem.
The issue of cards being in use during the backup can be worked around by using replication of the database, rather than simply taking a snapshot.

Hello!

Thank you very much for your mail.

Running mysql.

It is ok , if incoimg calls are blocked for few seconds.

but it would be a realy big issue - if information of finished calls are not inserted into database while we backup. then it will be a big money crisis as users account will not get deducted.

Perhaps you could craft a new backup script which rather than dumping the entire database in a single query, iterates customer-by-customer. This way you should only be locking one row at a time.
Personally I wouldn't bother; I'd switch to using a database server that guarantees the integrity of my data.

thanks again.

It means - finished calls are not inserted into database, at the same time, when we backup the mysql database via A2B "Database Backup" interface? is it?

I am not so very good programmer and having no idea about postgre.

I don't (and wouldn't, since their recent community/commercial fork) use MySQL so I can't confirm this. I can certainly see how establishing a full table lock would interact badly with a live system, if that is indeed what MySQL is doing. After a little research it seems MySQL 5 does support row (rather than table) level locks, but only if you're using the InnoDB storage backend.
You don't need to be a programmer to use a different SQL server; A2B includes supports for both MySQL v5 and Postgres out-of-the-box. Here is a comparison of them. I have to say I don't agree with their suggestion that Postgres is unstable or lacking in performance, although I never used Postgres v6 which seems to be the target of most of the negative comments.

thanks again!

running fedora, updated mysql server version: 4.0.26-standard. Lets see before to upgrade or to switch postgre - not sure which will be good idea!

not sure, will it be painful to upgrade from mysql 4 to 5.

Added after 6 minutes:

this is not good idea but before backup the databse, can shutdown the asterisk first then to backup the database.

I've no idea. For questions such as these you should consult your distribution's documentation and support forums.
If you can live with the downtime, then this seems to a feasible workaround.
I'd give the upgrade some serious consideration though. MySQL stopped supporting version 4 over a year ago, and A2B v1.4 will require MySQL v5.

I've never seriously worked on MySQL systems, but I'm pretty convinced that MySQL 4.x should be upgraded from any system that still has it.

If, however, you are concerned about a true, realtime backup, you could take a look at what Postgres supports (although I admit, it looks rather confusing for a less-experienced user):

http://www.postgresql.org/docs/8.2/stat ... iving.html