Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

SOLVED

TarMKcoldStanby space issue

kaushik-Datta
Level 2
Level 2

Hi All ,

We have a problem with our cold standby setup , every time we can see that primary author is consuming less space than the standby one. Is it normal ?
We are using AEM Version : 6.3.3.1 and also let us know what are the standard procedures to maintain standby repository.

NOTE : We run offline TarOptimization once in every week.

Thanks in advance ,
Kaushik

1 Accepted Solution
aemmarc
Correct answer by
Employee
Employee

Since you don't perform maintenance on a Standby instance it will just keep accruing data and appending changes from the Primary.

After you bring the Primary back up, a ton of stuff is going to synchronize and the Standby is going to grow significantly. What you need to do is run the cleanup() command from the JMX console to reduce the size of the Standby.

See :

Cold Standby Repository Maintenance

How to Run AEM with TarMK Cold Standby

View solution in original post

0 Replies
aemmarc
Correct answer by
Employee
Employee

Since you don't perform maintenance on a Standby instance it will just keep accruing data and appending changes from the Primary.

After you bring the Primary back up, a ton of stuff is going to synchronize and the Standby is going to grow significantly. What you need to do is run the cleanup() command from the JMX console to reduce the size of the Standby.

See :

Cold Standby Repository Maintenance

How to Run AEM with TarMK Cold Standby

View solution in original post

kaushik-Datta
Level 2
Level 2

Hi aem_marc ,

Thanks for the input. I did the same as you mentioned but there is no difference happened , the standby size remain same as it was earlier.
Steps performed :
1. Stopped the standby process from JMX (org.apache.jackrabbit.oak: Status ("Standby")).

2. Invoked the cleanup ()

Log O/P :

es/reclaim set 0/0

05.04.2019 13:40:04.159 *INFO* [qtp669874817-258] org.apache.jackrabbit.oak.segment.file.FileStore TarMK GC #0: cleanup marking files for deletion: none

05.04.2019 13:40:04.160 *INFO* [qtp669874817-258] org.apache.jackrabbit.oak.segment.file.FileStore TarMK GC #0: cleanup completed in 676.0 ms (675 ms). Post cleanup size is 17.1 GB (17132649472 bytes) and space reclaimed 0 B (0 bytes).

Regards,
Kaushik