We have Couchbase 4.0.x cluster running on Windows with multiple buckets. I have set up full backups (via Task Scheduler) via Powershell script, it worked ok for about about 2 weeks and then I noticed something strange - cbbackup would just freeze in a middle of a task and won't move forward. I have a log that says it stops at different point every time. The bucket in question isn't even big - less than 10Gb on disk.
About my script - all it does is call cbbackup and pack resulting directory via 7Zip, but the execution won't reach the second step. I can provide script source if it helps.
Any suggestions on how to investigate this? Which log files on Couchbase servers should I look into?
It seems my problem is related to this issue, but this one was fixed prior to 4.0 release.
I only now learned about -v flag on cbbackup and enabled it, will see what info it'll produce.
Related
In my development environment, I have my IDE, a database, web-server... installed
A script exist: 80 different commands are ran for it.
Then, at delivery time (integration, acceptance), I have a big mess to execute a script that create many Docker containers, each having its goal: database, web-server, etc.
Their scripts are some subsets of the big one I'm using for my own local developer computer. But adapted.
It's very difficult to ensure the transition between my standalone - "flat" if I can say so - dev computer and the containerized version fitted for delivery.
I wonder if a way exists to develop directly an application being containerized at its early beginning :
With all the tree of its containers ready (and not a single one containing everything: it would be cheating...)
As soon as I compile my sources in my IDE : simple compilation would have for result binaries and files going in their due container
and it's in these containers that my application would be executed, even in development mode.
Is it possible? Is it already done by some of you?
Or does it have too much drawbacks to be attempted?
I ran a hive query on a decently large dataset and it was taking too much time for the query so I decided to kill the application with :
yarn kill -application-id
Now when I check from the CLI with:
yarn application -list
then the above mentioned application does not show up in the list.
However, when I log into the Tez view from ambari the application is showing up to be still in the running state(almost been 24 hours since I created it).
I tried killing it again from the command line but it says that the application has already finished.
I also checked in the resource manager UI and the status for that job shows that it was killed.
Because of this, whenever I am trying to run any new hive job, it is just getting queued up and I am unable to run any other jobs.
Please help!
The TEZ VIEW is an export of the application timeline server info. If you use yarn kill, hive does not properly inform the YARN Application Timeline Server that the query has been terminated. Therefore, you still see these as running in the tez view because ATS never received any update that this entered a stopped/failed state. If you are unable to run new hive jobs, it will not be related to the fact that killed applications still show as running in the tez view and you should troubleshoot that separately. The bug you described is purely cosmetic and is documented in the following places:
https://issues.apache.org/jira/browse/HIVE-16429
https://community.hortonworks.com/content/supportkb/196542/tez-ui-displays-query-as-running-even-after-a-succ.html
So the way around I found to clear the queue so that I could run other queries was to go to /hadoop/yarn/timeline, backup the files and restart YARN. The TEZ queue was cleared up and I could start running my queries from the hive view again.
I should mention, however, that this will clear all queries(for all the users).
We have a task where we need to automatically convert an excel file to a csv to prep it for loading into a SQL database. The developers built this process into a SSIS package. For the conversion, they initially tried to have a task in the SSIS package execute a VBscript to convert the file. When they were running this on there local machines, this worked correctly. When they ran the package manually through VS on the server, it ran correctly. When they ran the package manually via the Integration Catalog it ran correctly. We did this both as our accounts and as the service account and got the same results. However, when we scheduled it as a job it would hang on the part of the process that executed the VBScript. No errors, it would just hang until you killed the job.
The job was executing as the service account which has full admin access on the server, explicit full access to the share where the files are stored and converted (which is on the same server) and full admin access to SQL. The job owner is set to sa which uses the service account. And all the job does is execute the package from the integration catalog which works if you run it independently of a job. When we compared the ssisdb execution report for the manual run in the integration catalog using the service account to the job run they looked the same except the job hung on the conversion task and the other did not.
After spending some time trying to figure this out, the developers tried a different solution. They changed the conversion script from using VBScript to using C#. They ran the package from there local machine and once again the package worked. This time when they ran it manually on the server it failed. When we ran it from the integration catalog it failed and when we ran it from a job it failed.
The error we keep getting is "Create CSV file: Error: Exception has been thrown by the target of an invocation" After spending several hours looking into this error nothing suggested seems to be working.
We also tried these same solutions on a newly built server to make sure we weren't dealing with an odd configuration setting that could have been changed (It is a Dev server) and it still failed there.
At this point, we are pretty lost at what is happening. The first solution worked, but for some reason would never work as a job. The 2nd solution works everywhere except when ran on the server.
We are looking at some other solutions to try to get around this. The next thing may be trying to using powershell to convert the file, but not sure if that will bring us back to the same issue. Any suggestion you guys have will be greatly appreciated
Also, we are using SQL Server 2012 dev edition, VS 2012 pro, Windows Server 2012 R2
This might be because of a bug that Excel has when trying to run jobs (that use Excel) and no user is logged on a specific machine. This might affect also the excel library. The solution is to create the following 2 folders:
C:\Windows\SysWOW64\config\systemprofile\Desktop
C:\Windows\System32\config\systemprofile\Desktop
and then restart the machine. :)
(Edited to show that a restart is needed. thanks for Dustin for checking this)
Im currently running JIRA 6.3.8 on a Windows Server 2008 virtual machine ,which periodically restarts outside of business hours to apply updates.
The result of this is that after every restart, JIRA breaks, stating that the home directory is locked, and a number of plugins fail to load. This has been a recurring problem that I have attempted a number of solutions for, including increasing JVM memory, deleting bundled plugins, creating exceptions in the firewall and ultimately, reinstalling JIRA(Which doesn't always solve the problem).
Are there any more permenant solutions to this?
EDIT: after some investigation It seems that this is a common problem with seemingly no concrete solution. According to some users, Virtual machines shut down faster and this is causing issues as JIRA doesn't shut down properly, causing these errors
Based off of some comments made, I am unable to install JIRA onto a Linux/Unix VM as It is an enterprise environment and I am only allocated a Windows VM, and disabling automatic updates is not an option due to securty policies regarding the VMs
I had the same problem several years ago. as I remember, the reason was in JIRA lock file. To solve the problem delete it before start service JIRA again.
The file should be named similar to
.jira-home.lock
EDIT
forgot to notice, this file is normally hidden
If using ec2 Linux AMI Do the following
SSH to machine
cd /data/jira - this is where the lock file is generated when Jira is started
ls -la -- Shows all files even hidden ones you can also use ls -al
remove .(*).lock file - Delete the lock file
Restart jira (/opt/jiraXXX/bin/shutdown.sh followed by startup.sh)
Verify the link - JIRA server link
If fails with felix cache issue -
cd to /data/jira/plugins/.osgi-plugins/felix
Delete/remove all the folders in the above folder (sudo rm -rf *)
Repeat 5 and 6
For me, this error was caused by a bad symbolic link in jira-shared-data/data
Currently I'm tasked with doing the daily build. We have an ASP.NET 2005 website with a SQL Server 2005 backend. Our current source control is Visual Source Safe 2005.
At this point, I use the brute-force method of daily builds.
Get Latest version of source code
Get Latest version of Database release script
Backup old website files to a directory
Publish new code to my local machine
Run on my server to keep the test/stage site working
Push newly created files to the website
Run SQL Script on test database (assuming updates, otherwise I don't bother)
Test website on the Test Server.
Looking at the idea of automated builds intrigues me since it means that I do less each morning. How would you recommend I proceed? I want to have a fully fleshed out idea before I present it to my boss.
Ditch VSS, move to Subversion, and check out CruiseControl.NET. Alternatively, if you have a MSDN developer license, you can run TFS workgroup edition and set up a build server on any old XP box. Its what we do at our shop.
As Assaf noted, you can use CC.NET with VSS directly. Nice.
TeamCity has worked well for me. It has a very simple setup. Combine it with an MsBuild script for your operations and you're auto-matic.
For build management I wholeheartedly recommend TeamCity. It doesn't require IIS6 (like CC.net does) since it runs on it's own copy of Tomcat and the setup is all done thru various forms. This is a big deal to me since the build server is just an XPPro box. It integrates well with SVN and there is no crazy XML file manipulation like I had to do with CruiseControl.Net. Big win for me.
For a build runner we use NAnt to send emails to various people, copy the packaged builds where they're supposed to go, run NUnit and NCover, and deploy the software to our web farm.
For automated testing we use Watin.
http://www.nunit.org/index.php
http://www.jetbrains.com/teamcity
http://ncover.sourceforge.net/
http://subversion.tigris.org/
http://nant.sourceforge.net/
http://watin.sourceforge.net/
Try CruiseControl.Net. It's free, and whatever customized daily/continuous routine you want it to perform you can always add with scripts.
Remember, it's not just about daily (nightly) builds, but also about letting you catch build errors in time (since it continuously builds after every source commit/check-in). You don't necessarily test every code chance on every possible platform and build configuration, but CC can do exactly that for you (in the background).
http://confluence.public.thoughtworks.org/display/CCNET/Visual+Source+Safe+Source+Control+Block
All of what you are doing can be performed by a set of batch files, depending on how automated your test environment is. The main batch file can be started as a 'scheduled task' at midnight or whatever. That's how we 'do it cheap' here and at other places I've worked. If you need help with a particular batch, I can provide a sample.
I second (or third) the reccomendation for Subversion/CruiseControl.net. Also, if it is appropriate, check out hosted services for SVN like CVSDude. You'll probably become well versed with MSBuild in the process too. Once you get it setup it is great.
The cost doesn't come from licensing of the tools or even hardware necessarily, but from your time building and maintaining the system - and depending on what you are doing, that could become significant.
Start with the basics and incrementally improve it over time. Like anything else, if you try to come out of the gate with lots of automation and functionality you could find yourself mired in it fulltime for weeks.
Whatever tools you use, house them in a virtual machine (ie., vmware).
When the equipment inevitably goes south, you can copy the image onto any machine and not miss a beat because your build server decided to take the day off, assuming of course, you back up.