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
|