 |
 |
Hi Marcus, Ah, yes. So, the qserv version that you were using wasn't the one that I posted fixes to which caused misleading messages in the log. So, never mind. As long as mono-node worked fine after your changes then all is well. Andy On Fri, 9 Dec 2016, Marcus Ebert wrote: > Hi Andy, > > Yes, it should be configured as a mono-node, at least I have not changed > anything on the default config which I understood is a mono-node config. > To install, I followed the quick-start guide and the integration tests at the > end worked too (and still work). > lsp.cf uses the "all.role server" directive only. > > What finally seems to have made the access working was to add entries for the > new databases to qservw_worker.Dbs > > > Cheers, > Marcus > > > On Thu, 8 Dec 2016, Andrew Hanushevsky wrote: > >> Hi Marcus, >> >> If you configured it as a mono-node then you are correct. However, my >> understanding (and what the log appears to show) qserv was configured as a >> clustered system. So, even with one worker you would still need a >> redirector and the associated cmsd processes. So, the big question is how >> was this really configured. That would be answered by what is in the >> qserv-run/etc/lsp.cf configuration file. >> >> Andy >> >> On Thu, 8 Dec 2016, Marcus Ebert wrote: >> >>> Hi Vaikunth, >>> >>> Thanks for looking at the logs! >>> I'm running 1 czar and 1 worker on 1 machine. To start up qserv, I used >>> the qserv-start.sh script. On a single machine there doesn't need to be a >>> running cmsd, does it? >>> >>> Cheers, >>> Marcus >>> >>> On Wed, 7 Dec 2016, Thukral, Vaikunth wrote: >>> >>> > Hi Marcus, >>> > > Fritz shared with us the logs you sent and we believe it may be >>> because > the cmsd service did not start up. To be certain, could you >>> also send us > the cmsd logs (usually called cmsd.log and cmsd_<date>.log >>> if rolled > over) from both the czar and the worker instances? Also, what >>> kind of > instance are you running - 1 czar and 1 worker on 2 separate >>> machines or > on 1 machine? >>> > > Thanks, >>> > -Vaikunth >>> > > > On Dec 2, 2016, at 11:09 AM, Fritz Mueller >>> <[log in to unmask]> > > wrote: >>> > > > > Hi Marcus, >>> > > > > I think the log files would would need to be examined for clues. >>> If > > you tgz them up shoot them to me in an email, wed happy to take a >>> > > look? >>> > > > > FritzM. >>> > > > > > On Dec 2, 2016, at 2:52 AM, Marcus Ebert >>> <[log in to unmask]> > > > wrote: >>> > > > > > > Hi, >>> > > > > > > We were trying out qserv installations since a while here in >>> > > > Edinburgh and have now an own database loaded into it (UKIDSS, > > >>> > ~4TB). >>> > > > That worked fine in the end(we tried so far just a single node > > >>> > installation to get familar with it and while the other machines for > >>> > > the test bed gets installed). On the machine where qserv runs, we > > >>> > can connect as qsmaster using mysql.sock and do queries on the > > > >>> database tables, including select queries. >>> > > > > > > However, connecting through port 4040 shows some problems. We >>> can > > > connect, list available databases, select the a database, show >>> the > > > tables and columns of a table, but "select" queries just hang. >>> It's > > > also the same on the local qserv machine if not going through >>> the > > > socket but specifiying local host name and port 4040, as well >>> as > > > remotely from another machine. >>> > > > > > > Does anyone kow what else needs to be changed in the qserv > >>> > > configuration to have this working? I already looked to the grant > > >>> > permissions for qsmaster, but these seem to be the same when > > > >>> connecting on localhost through socket and through port 4040. (also > > > >>> changing these for remote access doesn't change anything) >>> > > > > > > > > > > > > Cheers, >>> > > > Marcus >>> > > > > > > -- >>> > > > The University of Edinburgh is a charitable body, registered in >>> > > > Scotland, with registration number SC005336. >>> > > > > > > >>> ######################################################################## >>> > > > Use REPLY-ALL to reply to list >>> > > > > > > To unsubscribe from the QSERV-L list, click the following >>> link: >>> > > > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1 >>> > > > > >>> ######################################################################## >>> > > Use REPLY-ALL to reply to list >>> > > > > To unsubscribe from the QSERV-L list, click the following link: >>> > > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1 >>> > > >>> -- >>> The University of Edinburgh is a charitable body, registered in >>> Scotland, with registration number SC005336. >>> >>> ######################################################################## >>> Use REPLY-ALL to reply to list >>> >>> To unsubscribe from the QSERV-L list, click the following link: >>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1 >>> >> >> >> > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > ######################################################################## > Use REPLY-ALL to reply to list > > To unsubscribe from the QSERV-L list, click the following link: > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1 > ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the QSERV-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1