Replication problems 1.5.4 - always copying


  • Senior Developer

    @ablohowiak Not sure I understand what you mean here.

    Are the files not replicating, or not deleting? The node’s status, itself, should be fine.



  • @jgallo the working branch didn’t appear to fix the issue. I’m observing the exact same thing that you described. It makes adding a storage node to group, or a new image unreliable.



  • @george1421 Dear god I hope you’re right. I haven’t had a chance to upgrade to working branch 1.5.5 yet… been busy with other summer work. Oddly enough, I found my snapins update just fine when it comes to replication… it is just the images that never deleted the old files that didn’t match. I will try this soon as I get a chance.



  • @ablohowiak did the working branch end up helping with the replication? I’m currently having the same issue where image replication loop is occurring on the first storage node. My observation is that it only occurs after the initial upload meaning if you decide to update an existing image that has only been uploaded once “Original upload” and then upload the updated image, replication loops only on that image on the first storage node. Updating to working branch seemed like it worked but then eventually loops again. So i’m not sure if it’s completely resolved. I also have storage nodes and not a NAS system.



  • I’ve installed the trunk version on the Master storage node. Is there a way to confirm the version on a storage node?

    There’s still a replication issue. Seems that the d1p2.img is always the problematic file?

    [07-02-18 9:18:03 am] | Files do not match on server: FogKennedy
    [07-02-18 9:18:03 am] | Deleting remote file: /images/000-10-Golden/d1p2.img
    [07-02-18 9:18:03 am] * Starting Sync Actions
    [07-02-18 9:18:03 am] | CMD:
    lftp -e ‘set xfer:log 1; set xfer:log-file “/opt/fog/log/fogreplicator.000-10-Golden.transfer.FogKennedy.log”;set ftp:list-options -a;set net:max-retries 10;set net:timeout 30; mirror -c --parallel=20 -R --ignore-time -vvv --exclude “.srvprivate” “/images/000-10-Golden” “/images/000-10-Golden”; exit’ -u fog,[Protected] 10.97.0.17
    [07-02-18 9:18:03 am] * Started sync for Image 000-10-Golden
    [07-02-18 9:18:03 am] | Replication already running with PID: 7307

    The log file says that’s it’s deleting the file and starting a sync. There is no change in the timestamp on the destination node image file and no transfer log file is being created on the master storage node.


  • Moderator

    @ablohowiak I think I read the developers fixed this issue (or it was another replication issue) in the working branch (pre fog 1.5.5).

    If you could test this for us?

    These instructions assume that you downloaded the fog installer files via git.

    1. Change to the local git repo for fog. Depending on which instructions you followed they will be in /root/fogproject or /opt/fogproject.
    2. key in the following:
    sudo git pull
    sudo git checkout working
    sudo git pull
    cd bin
    

    Reinstall fog using the working branch

    sudo ./installfog.sh
    

    Then at the end so you don’t forget switch back.

    cd /root/fogproject
    sudo git checkout master
    

 

537
Online

41.9k
Users

12.4k
Topics

116.8k
Posts