Re: AcoustID

--===============2026772336==
Content-Type: multipart/alternative; boundary=047d7b10c94d2c317805167112b1

--047d7b10c94d2c317805167112b1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On May 18, 2015 4:14 PM, "Luk=C3=A1=C5=A1 Lalinsk=C3=BD" <[email protected]=
m> wrote:
>
>
> Definitely. I'd also welcome any patches/ideas on how to make the process
easier. My goal so far was only to run the data on acoustid.org. Running a
mirror was not my priority, because you need fairly expensive hardware to
do it right, so not many people would actually do that anyway.

I hope to be able to help here. I took a quick look at what it might take
to upgrade you to 9.4. I determined that it wasn't trivial, but it should
be rather straight forward. When I have the time, I'll see what I can do.

> I actually already have a replicated server just for the data export. I
currently do it while the replication is running, which is often causing
problems, due to PostgreSQL running out of transactions (the export is one
giant day-long serialized transaction). I have actually just moved the
server to a completely separate one with the intention to stop replication
during the process, but I need to figure out how to handle that with regard
to monitoring and things like that.
>

What kind of monitoring questions are you looking to answer?

If you copy the datadir, the cost would be cheaper. All you'll be doing is
a bit copy vs scheduling and dumping data all within the context of
postgres. You can transplant datadirs fairly easily as long as you do it
while the server is shutdown.
On May 18, 2015 4:14 PM, "Luk=C3=A1=C5=A1 Lalinsk=C3=BD" <[email protected]=
m> wrote:

> On Mon, May 18, 2015 at 3:39 PM, Joseph Curtin <[email protected]>
> wrote:
>
>> Having just sourced the database. As a user, it is possible to restore
>> the database using Ubuntu 14.04 and the postgresql-ppa.
>>
>> Would you like me to document the process?
>>
>
> Definitely. I'd also welcome any patches/ideas on how to make the process
> easier. My goal so far was only to run the data on acoustid.org. Running
> a mirror was not my priority, because you need fairly expensive hardware =
to
> do it right, so not many people would actually do that anyway.
>
>
>> Setup a replication server for backups. Every nth hour, halt the
>> replication server,  tar the datadir, and then restart the replication
>> server. This might cost a pretty penny when it comes to hosting.
>>
>
> I actually already have a replicated server just for the data export. I
> currently do it while the replication is running, which is often causing
> problems, due to PostgreSQL running out of transactions (the export is on=
e
> giant day-long serialized transaction). I have actually just moved the
> server to a completely separate one with the intention to stop replicatio=
n
> during the process, but I need to figure out how to handle that with rega=
rd
> to monitoring and things like that.
>
> Lukas
>
>
> _______________________________________________
> MusicBrainz-devel mailing list
> [email protected]
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel
>

--047d7b10c94d2c317805167112b1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
On May 18, 2015 4:14 PM, &quot;Luk=C3=A1=C5=A1 Lalinsk=C3=BD&quot; &lt;<a h=
ref=3D"mailto:[email protected]">[email protected]</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; Definitely. I&#39;d also welcome any patches/ideas on how to make the =
process easier. My goal so far was only to run the data on=C2=A0<a href=3D"=
http://acoustid.org/">acoustid.org</a>. Running a mirror was not my priorit=
y, because you need fairly expensive hardware to do it right, so not many p=
eople would actually do that anyway.</p>
<p dir=3D"ltr">I hope to be able to help here. I took a quick look at what =
it might take to upgrade you to 9.4. I determined that it wasn&#39;t trivia=
l, but it should be rather straight forward. When I have the time, I&#39;ll=
 see what I can do.=C2=A0</p>
<p dir=3D"ltr">&gt; I actually already have a replicated server just for th=
e data export. I currently do it while the replication is running, which is=
 often causing problems, due to PostgreSQL running out of transactions (the=
 export is one giant day-long serialized transaction). I have actually just=
 moved the server to a completely separate one with the intention to stop r=
eplication during the process, but I need to figure out how to handle that =
with regard to monitoring and things like that.<br>
&gt;</p>
<p dir=3D"ltr">What kind of monitoring questions are you looking to answer?=
</p>
<p dir=3D"ltr">If you copy the datadir, the cost would be cheaper. All you&=
#39;ll be doing is a bit copy vs scheduling and dumping data all within the=
 context of postgres. You can transplant datadirs fairly easily as long as =
you do it while the server is shutdown.</p>
<div class=3D"gmail_quote">On May 18, 2015 4:14 PM, &quot;Luk=C3=A1=C5=A1 L=
alinsk=C3=BD&quot; &lt;<a href=3D"mailto:[email protected]">lalinsky@gmail=
.com</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, May 18, 2015 at 3:39 PM, Joseph Curtin <span dir=3D"ltr">&lt;<a href=3D=
"mailto:[email protected]" target=3D"_blank">[email protected]</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">Having=
 just sourced the database. As a user, it is possible to restore the databa=
se using Ubuntu 14.04 and the postgresql-ppa.</p>
<p dir=3D"ltr">Would you like me to document the process?</p></blockquote><=
div><br></div><div>Definitely. I&#39;d also welcome any patches/ideas on ho=
w to make the process easier. My goal so far was only to run the data on <a=
 href=3D"http://acoustid.org" target=3D"_blank">acoustid.org</a>. Running a=
 mirror was not my priority, because you need fairly expensive hardware to =
do it right, so not many people would actually do that anyway.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
<p dir=3D"ltr">Setup a replication server for backups. Every nth hour, halt=
 the replication server,=C2=A0 tar the datadir, and then restart the replic=
ation server. This might cost a pretty penny when it comes to hosting.<br><=
/p></blockquote><div><br></div><div>I actually already have a replicated se=
rver just for the data export. I currently do it while the replication is r=
unning, which is often causing problems, due to PostgreSQL running out of t=
ransactions (the export is one giant day-long serialized transaction). I ha=
ve actually just moved the server to a completely separate one with the int=
ention to stop replication during the process, but I need to figure out how=
 to handle that with regard to monitoring and things like that.</div><div><=
br></div><div>Lukas</div><div><br></div></div></div></div>
<br>_______________________________________________<br>
MusicBrainz-devel mailing list<br>
<a href=3D"mailto:[email protected]">MusicBrainz-deve=
[email protected]</a><br>
<a href=3D"http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel"=
 target=3D"_blank">http://lists.musicbrainz.org/mailman/listinfo/musicbrain=
z-devel</a><br></blockquote></div>

--047d7b10c94d2c317805167112b1--


--===============2026772336==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
MusicBrainz-devel mailing list
[email protected]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel
--===============2026772336==--