Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restore broken if running primary/replica on same host #41

Open
umeshdangat opened this issue Feb 5, 2020 · 0 comments
Open

Restore broken if running primary/replica on same host #41

umeshdangat opened this issue Feb 5, 2020 · 0 comments
Labels
backup/restore bug Something isn't working

Comments

@umeshdangat
Copy link
Member

umeshdangat commented Feb 5, 2020

When we run both primary and replica on the same node, back them up and try to restore them on same node, the restored indexDir (index data) path ends ups pointing to same directory on disk.

Steps to repo

  1. Backup primary (and replica state)
  2. Down primary
  3. Down secondary
  4. Bring up new primary and restore it using resourceName in 1
  5. Bring up new secondary on same host as 4 and restore it using resourceName in 2

Root cause
We back up index data from primary via the BackupIndex command.
StateDir itself is also backed up and has to be restored before actual data.
Upon restoring actual we reuse the indexDirectory specified in the stateDir.
Then we download data to a new location.
Finally, we simply create a symlink to point to the downloaded location of index data from the indexDir specified in stateDir.

The indexDir path looks like below:
serverPrimary@ -> /var/folders/xl/8yyfg7s93k95g3vtr04b8z9jpd3vss/T/junit15797558079443604738/archiver/testresource_data/current/serverPrimary

Issue is when we run a replica/secondary on the same host we create another symlink to the same location of data:
serverSecondary@ -> /var/folders/xl/8yyfg7s93k95g3vtr04b8z9jpd3vss/T/junit15797558079443604738/archiver/testresource_data/current/serverPrimary

Thus both primary and secondary/replica now use same underlying files. This is not an issue typically since we generally spin up different containers for restoring and running primary and replica.

@umeshdangat umeshdangat added bug Something isn't working backup/restore labels Feb 5, 2020
@umeshdangat umeshdangat changed the title Backup/Restore broken if running primary/replica on same host Restore broken if running primary/replica on same host Feb 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backup/restore bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant