discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnustep.org has been down for the past few days


From: Ivan Vučica
Subject: Re: gnustep.org has been down for the past few days
Date: Sun, 4 Sep 2022 19:39:46 +0100

I got all 4 .sql files to load on my local MariaDB.

Continuing tomorrow.

On Sun, Sep 4, 2022 at 7:17 PM Ivan Vučica <ivan@vucica.net> wrote:
>
> I'm doing the barest minimum of the changes. If the original machine
> had MyISAM, I'm using MyISAM. If the installed software was using
> MyISAM, I don't want to find out the hard way that the schemas were
> mis-defined (given that MyISAM has, particularly back in that era,
> been much more liberal with basic concepts such as foreign keys).
>
> I want to minimize the amount of fronts I have to fight MySQL on. I'm
> even thinking of dropping down to latin1 and figuring out what to do
> later.
>
> I would not choose to start with MyISAM (and where possible I'd also
> use Postgres rather than MySQL/MariaDB).
>
>
>
> On Sun, Sep 4, 2022 at 7:13 PM Andreas Fink <afink@list.fink.org> wrote:
> >
> > why you dont use innodb as engine? much less troubles in case of crashes 
> > and reboots
> >
> >
> >
> > On Sonntag, Sept. 04, 2022 at 8:02 PM, Ivan Vučica <ivan@vucica.net> wrote:
> > Update:
> > - I added wiki.gnustep.org to DNS as well -- it was an omission not to
> > add it. Please REFRAIN FROM EDITS until further notice as YOUR EDITS
> > WILL NOT BE MIGRATED.
> > - I am still fighting MySQL/MariaDB:
> > - the previous server has an unknown default character set/collation
> > (latin1 and not utf8, likely, as I managed to import _gsweb with it)
> > - aside from timezone precision of "14" not meaning what the authors
> > of schemas meant, it's also deprecated (this was the quickest of the
> > fixes, just replace timestamp(14) with new maximum timestamp(6)
> > - second fastest fix was TYPE=MyISAM changing into ENGINE=MyISAM
> > - the previous server has an unknown timezone configured, and even
> > worse, it is unclear what timezone the dates in the dump are in
> > - specifically, some of the dates are failing to be inserted as
> > they appear to be happening during nonexistent hours during March
> > timezone switches
> > - entertaining thing: varchar(255) is fine as primary key fitting
> > inside MyISAM's 1000 bytes maximum .... as long as utf8mb4 is not the
> > character set in use
> > - 4 * 255 = 1020
> > - even though I suspect the old default was latin1, I am using
> > utf8 which still fits inside 1000 bytes
> >
> > Now, after a few hours of fighting this, I've only completed the first
> > out of five databases (gnustep_gsweb.sql, which might not even be in
> > use).
> >
> > The next one, gnustep_mediawiki, is already being painful.
> >
> > I am unlikely to be done today.
> >
> > On Tue, Aug 30, 2022 at 10:59 PM Marco Cawthorne <marco@icculus.org> wrote:
> >
> >
> > On 2022-08-30 14:28:54 -0700 Ivan Vučica <ivan@vucica.net> wrote:
> >
> > I've spent some time today on playing with Ansible thinking it may be
> > better to do it sooner rather than later. I'll leave that aside for
> > now.
> >
> > By the time I got to look at restoring MySQL databases, it simply got
> > late. Turns out that the database dumps need to be manually fixed
> > before they can be imported: schemas have changed between the version
> > on the old server and MariaDB 10.x that I have on the new one. It
> > should be relatively easy, if possibly labor intensive.
> >
> > I'll leave it for tomorrow.
> >
> >
> > Thank you for all the work you do and for keeping us updated.
> > And thanks to Gregory for the quick redirects. At last we can browse most 
> > of the documentation again.
> >
> > Marco Cawthorne
> >
> >



reply via email to

[Prev in Thread] Current Thread [Next in Thread]