Facing issue while taking data store backup in distribution-karaf-0.5.2-Boron-SR2.
{"Failed to back up datastore to file ..../distribution-karaf-0.5.2-Boron-SR2/backupFolder/datastorebackup: Timed out after 30000 ms while waiting for CaptureSnapshotReply","error-info":"error"}]}}
Rest API to get data store backup.
https://localhost:8443/restconf/operations/cluster-admin:backup-datastore
Made cluster set up using distribution-karaf-0.5.2-Boron-SR2 and took called the rest api from leader.
created the datastorebackup folder structure like below
.../distribution-karaf-0.5.2-Boron-SR2/backupFolder/datastorebackup
Note: In Follower node ODL platform Adapter and ODL Resource manager bundles are failure. After solving the bundle Failure issue and restarting the cluster able to take datastorebackup successfully.
MDSAL-BACKUP should be successful
Related
I'm new to managing MS Dynamics CRM. It's Online, not on-prem. I got a notice this morning that a Tenant had gone over our storage capacity of 30GB. Looking into the Dataverse for that tenant I can see 20GB of the file storage is AsyncOperations. Looking into how to bulk delete this I can see we have jobs set up to bulk delete completed system jobs, so that's sorted. Looking further I've found guides that say it's a system job type of Workflow. However, when I go to create the bulk delete job and preview records I get 0 for a system job type workflow. Any ideas on how to clear out some of this AsyncOperation storage?
I've tried various Microsoft documents on how to clear out file storage but can't seem to find anything that's giving me results other than completed system jobs which we're already deleting regularly and it doesn't appear to be clearing the AsyncOperations storage.
This article should give you idea/more info about how to proceed with async operations
Our application is a Spring batch running in openshift. The application calls another service via REST to fetch records from database. Both use nginx side car for handling the traffic. Both side cars restarted for some reason and the Spring batch job terminated suddenly .I already implemented retry mechanism using #Retryable but the logic has not even reached the retry part. The only log I found in the application is given below
"Encountered an error executing step myPartitionStep in job myJob","level":"ERROR","thread":"main","logClass":"o.s.batch.core.step.AbstractStep","logMethod":"execute","stack_trace":"o.s.b.core.JobExecutionException: Partition handler returned an unsuccessful step
o.s.b.c.p.support.PartitionStep.doExecute(PartitionStep.java:112)
o.s.batch.core.step.AbstractStep.execute(AbstractStep.java:208)
o.s.b.core.job.SimpleStepHandler.handleStep(SimpleStepHandler.java:152)
o.s.b.c.job.flow.JobFlowExecutor.executeStep(JobFlowExecutor.java:68)
o.s.b.c.j.f.s.state.StepState.handle(StepState.java:68)
o.s.b.c.j.f.support.SimpleFlow.resume(SimpleFlow.java:169)
o.s.b.c.j.f.support.SimpleFlow.start(SimpleFlow.java:144)
o.s.batch.core.job.flow.FlowJob.doExecute(FlowJob.java:137)
o.s.batch.core.job.AbstractJob.execute(AbstractJob.java:320)
o.s.b.c.l.s.SimpleJobLauncher$1.run(SimpleJobLauncher.java:149)
o.s.core.task.SyncTaskExecutor.execute(SyncTaskExecutor.java:50)
o.s.b.c.l.s.SimpleJobLauncher.run(SimpleJobLauncher.java:140)
j.i.r.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java)
j.i.r.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
j.i.r.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(Method.java:566)
o.s.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:344)
o.s.a.f.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:198)
o.s.a.f.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
o.s.b.c.c.a.SimpleBatchConfiguration$PassthruAdvice.invoke(SimpleBatchConfiguration.java:128)
... 13 frames truncated\n"
I am not able to point what exactly is the reason for this error. It stopped at partition step which uses itemReader to call another service and fetche the records,FlatFileItemWriter which writes the records. We cannot afford to have duplicates in our file. Is it possible to restart the app exactly where it stopped without having duplicates?
The stacktrace you shared is truncated, so it is not possible to see the root cause from what you shared.
Spring Batch supports restarting a failed paritioned step, as long as you use a persistent job repository. You need to restart the same job instance, ie use the same job parameter that you used in your first run (that failed). Only failed partitions will be rerun. Any failed partition will resume from where it left off.
I jave a JAVA application in which I am using GCP to create VM instances from images.
In this application, I would like to allow the user to view the vm creation logs in order to be updated on the status of the creation, and to be able to see failure points in detail.
I am sure such logs exist in GCP, but have been unable to find specific APIOs which let me see a specific action, for example creation of instance "X".
Thanks for the help
When you create a VM, the answer that you have is a JobID (because the creation take time and the Compute Engine API answer immediately). To know the status of the VM start (and creation) you have to poll regularly this JobID.
In the logs, you can also filter with this JobID to select and view only the logs that you want on the Compute API side (create/start errors).
If you want to see the logs of the VM, filter the logs not with the JobID but with the name of the VM, and its zone.
In Java, you have client libraries that help you to achieve this
I am trying to create 30 databases (oci_database_database resource) under 5 existing db_homes. All of these resources are under a single DB System :
When applying my code, a first database is successfully created then when terraform attempts to create the second one I get the following error message : "Error: Service error:IncorrectState. The existing Db System with ID has a conflicting state of UPDATING", which causes the execution to stop.
If I re-apply my code, the second database is created then I get the same previous error when terraform attempts to create the third one.
I am assuming I get this message because terraform starts creating the following database as soon as the first one is created, but the DB System status is not up to date yet (still 'UPDATING' instead of 'AVAILABLE').
A good way for the OCI provider to avoid this issue would be to consider a database creation as completed when the creation is indeed completed AND the associated db home and db system's status are back to 'AVAILABLE'.
Any suggestion on how to adress the issue I am encountering ?
Feel free to ask if you need any additional information.
Thank you.
As mentioned above, it looks like you have opened a ticket regarding this via github. What you are experiencing should not happen, as terraform should retry after seeing the error. As per your github post, the person helping you is in need of your log with timestamp so they can better troubleshoot. At this stage I would recommend following up there and sharing the requested info.
I have a network version where I fixed a small bug in the .js file and added a function. I would like to redeploy the network (on the same version).
I stop/teardown Fabric and restart it. Delete the card and .bna file, then re-create the card and .bna file. After that I install and start the network. Last step is to start the REST server.
Even after all these steps, the REST server does not list my new function, indicating it has not been updated?
Do I have to change the version number if I modify the script.js and model.cto files?
As david_k points out in 'comments' above - you should use composer network upgrade to upgrade the business network (no need to 'teardown' your Fabric environment) as well as stop the REST server as you've done. See https://hyperledger.github.io/composer/latest/reference/composer.network.upgrade.html and example of it in use in the tutorials https://hyperledger.github.io/composer/latest/tutorials/queries . Once you've upgraded your business network successfully, and pinged it successfully, you can stop/remove the old dev-* business network containers as indicated. You would then start the REST server again, use the same business network card (eg. an admin card) when prompted / as a parameter to the start command. Then in a new browser session, you can test your REST APIs (or as suits). If you're not seeing the new function (or it errors), you should check your decorators/naming in your logic.js file to see the right transaction function is being called for a named transaction.