[BUG?] initial.load.delete.first possibly not happening?

Help
2014-07-17
2014-07-18
  • Luca Santarelli

    Luca Santarelli - 2014-07-17

    I am wondering the semantic of the initial.load.delete.first option.

    Today I tried setting up a master-slave replication and, during the initial load, I experienced the following exception:

    Caused by: java.sql.SQLException: The CREATE UNIQUE INDEX statement terminated because a duplicate key was found for the object name 'dbo.TblRegolazioneSecondaria' and the index name 'TblRegolazioneSecondaria_PK'. The duplicate key value is (UP_AGRI_1, Jan  2 2014 12:00AM, 1).
    

    The slave node alredy has populated data (from previous backup + tests), in fact I enabled the folliwing options

    initial.load.create.first=true
    initial.load.delete.first=true
    

    believing that it would both send schema (it happens) and clear data (is it happening?)

    Executing a COUNT(*) over the PK fields on the master returns only unique rows. The same query on the slave returns duplicates.

    When is the "initial.load.delete.first" performed? If it's performed after the index creation attempt, it'll just fail.

    If this is the expected behaviour, what is the imagined use-case for the delete.first?

    Should I manually delete everything from the slave database before setting up the replication?

     
  • Josh Hicks

    Josh Hicks - 2014-07-17

    This appear to happen when the follow flow occurs:

    Initial load, Alter a table, Initial Load.

    Mainly due to the fact that the delete is not occurring until after the create currently which causes an issue on adding the PK column as part of the alter/create process.

    I will open a bug but in the mean time yes, delete everything manually prior to rerunning an initial load when a new key is added and you should be fine.

     
  • Luca Santarelli

    Luca Santarelli - 2014-07-18

    I am not sure if it can help you, but the flow I followed isn't strictly the one you mentioned. I made multiple experiments on the two databases, everytime performing a bin/symadmin -e (both nodes) uninstall.

    So, from SymmetricDS's point of view, there was ever only a single initial load request.

    It's true that, in the meanwhile, the keys changed. [In fact, but this might be material for a different bug/thread/request for help, Symmetric won't/cant't properly work on tables with no keys, as it will just duplicate everything.]

    Thanks for your reply.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks