3CX Data Connector Migrating from PostgreSQL to MySQL 8.4 (Historical Data Migration)

surenr

Customer
Joined
Apr 1, 2019
Messages
50
Reaction score
10
Hi everyone,

I currently have an AWS RDS PostgreSQL database configured under 3CX Admin Console → Integrations → Data Connector, and it has been successfully transferring data for approximately one year.

Since Delete Transferred Data has always been disabled, I understand that the historical data should still be retained in the 3CX PBX's internal database.

I'm now planning to migrate from PostgreSQL to a new AWS RDS MySQL 8.4 database.

I would like to clarify the following:

  1. If I simply update the Data Connector configuration with the new MySQL RDS connection details, will 3CX automatically export all historical data again, including records from when the Data Connector feature was first introduced?
  2. Or will the Data Connector only export new records from the point when the MySQL database is configured, leaving the previously exported historical data in PostgreSQL?
  3. If historical data is not automatically re-exported, do I need to manually migrate the existing PostgreSQL data to MySQL first, and then update the 3CX Data Connector configuration to point to the new MySQL database?
  4. Is there any officially supported method to force a complete historical data re-export from 3CX to a newly configured database?
My preference is to let 3CX regenerate the entire dataset directly into the new MySQL database, if this is supported, rather than manually converting and migrating the existing PostgreSQL database.

Could someone from the 3CX team confirm the expected behaviour and recommended migration procedure?

I would appreciate clarification from the 3CX team or anyone who has performed a similar migration.

Thanks in advance!
 
Last edited:
Solution
Hello,

The "locking" mechanism is there to prevent dublications, but it will actually allow through a complete re-transfer to a new clean target.

So, as long as the Delete transferred was never activated then all data should make it to the new connection without any further action (time series tables with system stats may not go back to the very beginning, but I would assume this is not a strict requirement).

As a final note, I would not clear out the old server until I knew the new one had all the data, and would compare counts up to the switchover time, just in case anything needs a manual intervention (or make sure I had robust data dumps that could be used to recover anything not carried over). You can also always get a...
you will need to make your own script to copy the data I believe, as a tag is marked in the db to not re-export duplicates (IIRC)
 
Hello,

The "locking" mechanism is there to prevent dublications, but it will actually allow through a complete re-transfer to a new clean target.

So, as long as the Delete transferred was never activated then all data should make it to the new connection without any further action (time series tables with system stats may not go back to the very beginning, but I would assume this is not a strict requirement).

As a final note, I would not clear out the old server until I knew the new one had all the data, and would compare counts up to the switchover time, just in case anything needs a manual intervention (or make sure I had robust data dumps that could be used to recover anything not carried over). You can also always get a trial system and perform a test to confirm behaviour.
 
  • Like
Reactions: surenr
Solution

Forum statistics

Threads
112,242
Messages
591,451
Members
165,331
Latest member
Rene2309