Planned Downtime @ 2018-04-21 00:00:00 GMT.

[gnif]

I will be moving the forums and website over to the new cluster at 2018-04-21 00:00:00 GMT.
Unfortunately due to the huge jump software versions this can not be done without causing some downtime.

The forums should not be down for any longer then an hour provided everything goes OK.
If it does take longer please be patient as we will be working to restore operations as fast as possible.

Part of this migration includes upgrading fully to InnoDB tables on the Barracuda engine, as well as moving to utf8mb4 collation.

Leading up to the move I will not be able to answer questions as I will be preparing so that everything goes smoothly.

[gnif]

Forums are now working again, other areas of the site are still to be completed.

Please hold off reporting any issues until then.

[Monkeh]

Glorious Ω, how I have missed thee.

Three cheers for gnif!

[trevatxtal]

Sadly I am still in Friday 20 April While you are in Sat 21 already.
Is it possible for the time adjustment box to be used .
Thank you
Trevor.
M0XOL

[Monkeh]

I wasn't going to mention the minor 24-hour mistake.

[EEVblog]

Part of this migration includes upgrading fully to InnoDB tables on the Barracuda engine, as well as moving to utf8mb4 collation.

Does this mean that the UTF8 support people have been complaining about for a long time is now solved?

[EEVblog]

Thanks gnif, this has been a huge amount of effort on your end 
I encourage everyone who uses the forum to support gnif's efforts on Patreon if able.
https://www.patreon.com/gnif

[hendorog]

Not sure if I'm suffering from bias but the site seems quite a bit faster to me.

[Ampera]

Уелл, даве, иф тхис мессаге ис аппеаринг он тхе форумс, тхен И ам гуессинг тхат уи хаве Уникоде суппорт.

🕴️🕴️🕴️🕴️🕴️🕴️

[gnif]

Not sure if I'm suffering from bias but the site seems quite a bit faster to me.

It should be quite a bit faster again now, the reverse proxy via the old server was just removed.

[gnif]

Thanks gnif, this has been a huge amount of effort on your end 
I encourage everyone who uses the forum to support gnif's efforts on Patreon if able.
https://www.patreon.com/gnif

Not done yet, but you're most welcome.

Part of this migration includes upgrading fully to InnoDB tables on the Barracuda engine, as well as moving to utf8mb4 collation.

Does this mean that the UTF8 support people have been complaining about for a long time is now solved?

It should be, the following seems to indicate so

Уелл, даве, иф тхис мессаге ис аппеаринг он тхе форумс, тхен И ам гуессинг тхат уи хаве Уникоде суппорт.

🕴️🕴️🕴️🕴️🕴️🕴️

[frozenfrogz]

Gøød news everyΩne!

Thanks a million!

[gnif]

Seems database fail over isn't working yet... there may be several short outages while I correct this.

[EEVblog]

Not sure if I'm suffering from bias but the site seems quite a bit faster to me.

It should be quite a bit faster again now, the reverse proxy via the old server was just removed.

The initial page load is MUCH faster than before 
And I wasn't complaining about the speed of the old server

[tautech]

Not sure if I'm suffering from bias but the site seems quite a bit faster to me.

It should be quite a bit faster again now, the reverse proxy via the old server was just removed.

The initial page load is MUCH faster than before 
And I wasn't complaining about the speed of the old server

Had to shoot and run just when gnif pulled the server down and not long been back.
First impressions it is a wee bit faster now.
Thanks Dave and gnif for bravely taking this step forward. 

[gnif]

Seems database fail over isn't working yet... there may be several short outages while I correct this.

Database failover now working, but something wrong with recovery, investigating.

[gnif]

Seems database fail over isn't working yet... there may be several short outages while I correct this.

Database failover now working, but something wrong with recovery, investigating.

failover and recovery of the database between servers is now perfect

[nctnico]

Are the PDF attachements also fixed?

[gnif]

Are the PDF attachements also fixed?

First I have heard of it... whats the problem?

[Brumby]

I don't know that it's a "problem" as such - just a size limitation.

[BravoV]

At random, still getting "500 Internal Server Error nginx/1.10.3" message, and a refresh cleared it out. Still fast though.

[BravoV]

It happened again just few seconds ago, just trace back this post's time and my IP, hope this helps.

[Monkeh]

Part of this migration includes upgrading fully to InnoDB tables on the Barracuda engine, as well as moving to utf8mb4 collation.

Does this mean that the UTF8 support people have been complaining about for a long time is now solved?

It is indeed, we can now use such advanced symbols as Ω rather than trying to use something ugly like  ,

[gamalot]

Chinese? 中文 

[gnif]

At random, still getting "500 Internal Server Error nginx/1.10.3" message, and a refresh cleared it out. Still fast though.

Expected, I am still performing server tuning. Unfortunately all the prep work int the world doesn't prepare you for real world workloads.

[EEVblog]

I don't know that it's a "problem" as such - just a size limitation.

The new server does have more drive space than before IIRC, but it's not cloudy infinite.
So I don't expect we could raise the limits much.

[EEVblog]

New server bandwidth

[IanB]

Just testing that MathJax is still available:

$$ ax^2+bx+c=0 $$

Yes, cool 

[nctnico]

Are the PDF attachements also fixed?

First I have heard of it... whats the problem?

PDF attachements never open in Acrobat. Every other website works but not EEVblog. AFAIK this is a well known problem for EEVblog users so most refrain from attaching PDFs.

For example the PDFs attached to this message:
https://www.eevblog.com/forum/testgear/siglent-sds1104x-e-in-depth-review/msg1371771/#msg1371771
Firefox (the latest version) says the file type is unkown and wants to open it with a text editor.

[tautech]

Are the PDF attachements also fixed?

First I have heard of it... whats the problem?

PDF attachements never open in Acrobat. Every other website works but not EEVblog. AFAIK this is a well known problem for EEVblog users so most refrain from attaching PDFs.

For example the PDFs attached to this message:
https://www.eevblog.com/forum/testgear/siglent-sds1104x-e-in-depth-review/msg1371771/#msg1371771
Firefox (the latest version) says the file type is unkown and wants to open it with a text editor.

OK just checked on this thread ^.
File downloads fine and it opens in a tab in your browser fine too. In Chrome with a right click on the downloaded pdf you can set "Always open in Acrobat" and when set it does just that.

[nctnico]

I guess Chrome is doing something non-standard then and tries to guess based on the extension. According to the specs the webserver is supposed to let the browser know what kind of file (mime-type in the HTTP header) it is receiving regardless of the extension. If that is broken a browser gets a binary blob with unknown content. BTW the same goes wrong when people attach pictures. Firefox can't deal with those either probably due to the missing mime-type. As I wrote before: EEVblog is the only website I visit where this doesn't work properly.

[gnif]

Chrome works fine for me too, I get a prompt to download the file.

SMF is actually serving the file, not Nginx directly.

Code: [Select]

wget "https://www.eevblog.com/forum/testgear/siglent-sds1104x-e-in-depth-review/?action=dlattach;attach=397073" -O/dev/null --debug
DEBUG output created by Wget 1.19.4 on linux-gnu.

Reading HSTS entries from /home/geoff/.wget-hsts
URI encoding = ‘UTF-8’
--2018-04-21 07:44:02--  https://www.eevblog.com/forum/testgear/siglent-sds1104x-e-in-depth-review/?action=dlattach;attach=397073
Resolving [url=http://www.eevblog.com]www.eevblog.com[/url] ([url=http://www.eevblog.com]www.eevblog.com[/url])... 104.31.75.133, 104.31.74.133, 2400:cb00:2048:1::681f:4b85, ...
Caching [url=http://www.eevblog.com]www.eevblog.com[/url] => 104.31.75.133 104.31.74.133 2400:cb00:2048:1::681f:4b85 2400:cb00:2048:1::681f:4a85
Connecting to [url=http://www.eevblog.com]www.eevblog.com[/url] ([url=http://www.eevblog.com]www.eevblog.com[/url])|104.31.75.133|:80... connected.
Created socket 4.
Releasing 0x0000555c8cee0910 (new refcount 1).

---request begin---
GET /forum/testgear/siglent-sds1104x-e-in-depth-review/?action=dlattach;attach=397073 HTTP/1.1
User-Agent: Wget/1.19.4 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: [url=http://www.eevblog.com]www.eevblog.com[/url]
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 200 OK
Date: Fri, 20 Apr 2018 21:44:03 GMT
Content-Type: application/octet-stream
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: __cfduid=d9d87d66c77bd7b75de4ed75d84068bec1524260642; expires=Sat, 20-Apr-19 21:44:02 GMT; path=/; domain=.eevblog.com; HttpOnly
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Set-Cookie: PHPSESSID=hpi2vnv19st40mu1c569nlhi77; path=/
Pragma:
Content-Transfer-Encoding: binary
Expires: Sat, 20 Apr 2019 21:44:03 GMT
Last-Modified: Wed, 21 Feb 2018 16:27:38 GMT
ETag: W/"397073SDS1104X-E Review 1-25.pdf1519230458"
Content-Disposition: attachment; filename="SDS1104X-E Review 1-25.pdf"
Cache-Control: max-age=31536000, private
Vary: Accept-Encoding
X-Backend: web2.eevblog.com
Server: cloudflare
CF-RAY: 40eaca36203b19bc-SYD

---response end---
200 OK
cdm: 1

Stored cookie eevblog.com -1 (ANY) / <permanent> <insecure> [expiry 2019-04-21 07:44:02] __cfduid d9d87d66c77bd7b75de4ed75d84068bec1524260642

Stored cookie [url=http://www.eevblog.com]www.eevblog.com[/url] -1 (ANY) / <session> <insecure> [expiry none] PHPSESSID hpi2vnv19st40mu1c569nlhi77
Registered socket 4 for persistent reuse.
Length: unspecified [application/octet-stream]
Saving to: ‘/dev/null’
Failed to set xattr ‘user.xdg.origin.url’.

/dev/null                                                                           [    <=>                                                                                                                                                                                              ] 756.99K   840KB/s    in 0.9s   

2018-04-21 07:44:04 (840 KB/s) - ‘/dev/null’ saved [775161]

Content-Disposition: attachment; filename="SDS1104X-E Review 1-25.pdf"

Content-type is not a required header according to the specs, if your browser is misbehaving either it's a bug or you have a plugin installed that is messing things up:

https://tools.ietf.org/html/rfc7231#section-3.1.1.5

   A sender that generates a message containing a payload body SHOULD
   generate a Content-Type header field in that message unless the
   intended media type of the enclosed representation is unknown to the
   sender.  If a Content-Type header field is not present, the recipient
   MAY either assume a media type of "application/octet-stream"
   ([RFC2046], Section 4.5.1) or examine the data to determine its type.

[nctnico]

I have plain & simple Firefox (the most recent version but previous versions had the same problem) with ABP as the only extension and no tweaking of anything. Firefox says it can't determine the type of the file. And I think you are mis-interpreting the specs. It says the sender (server) should indicate the content type unless it really really really can't do it. It also says that the recipient (browser) may choose what to do when the content type is unknown: treat it as a blob or try to guess. So if you want the transfer of files to always work over HTTP then there is no other option than having the webserver supply the correct content type.

[gnif]

I have plain & simple Firefox (the most recent version but previous versions had the same problem) with ABP as the only extension and no tweaking of anything. Firefox says it can't determine the type of the file. And I think you are mis-interpreting the specs. It says the sender (server) should indicate the content type unless it really really really can't do it. It also says that the recipient (browser) may choose what to do when the content type is unknown: treat it as a blob or try to guess. So if you want the transfer of files to always work over HTTP then there is no other option than having the webserver supply the correct content type.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

I am not saying that this should not be fixed, I am however saying that it is not a critical problem nor high priority.

File type is not detected using the extension under Linux, it is a bad practice to do so on any operating system. The mime type is detected by scanning the file headers for known signatures, this imposes additional server load. Assuming a file is what it is based on extension is a dangerous practice and can lead to downloading a "PDF" that is really a malicious file, simply because the file extension was trusted.

[IanB]

So if you want the transfer of files to always work over HTTP then there is no other option than having the webserver supply the correct content type.

But the web server doesn't know the correct content type. The file was uploaded by the user as an attachment to a post, and the only information provided by the user was the file name and extension. When you view the post, you get back the information originally provided; no more, no less.

The only way the server could indicate that the attachment is a PDF file is to look inside the file and interpret the contents, or to look at the extension and associate .pdf with a PDF file. Both of which the browser can do just as well.

In this case the server has no business deducing or guessing, it should just hand back the data as it received it with the same file name. So I think the server is behaving as it should.

[nctnico]

So if you want the transfer of files to always work over HTTP then there is no other option than having the webserver supply the correct content type.

But the web server doesn't know the correct content type. The file was uploaded by the user as an attachment to a post, and the only information provided by the user was the file name and extension. When you view the post, you get back the information originally provided; no more, no less.

The only way the server could indicate that the attachment is a PDF file is to look inside the file and interpret the contents, or to look at the extension and associate .pdf with a PDF file. Both of which the browser can do just as well.

In this case the server has no business deducing or guessing, it should just hand back the data as it received it with the same file name. So I think the server is behaving as it should.

The makers of Firefox (not exactly a niche browser) seem to have a different opinion so don't shoot the messenger. Life sucks and sometimes you have to fix things which are not really your problem to start with.

[gnif]

So if you want the transfer of files to always work over HTTP then there is no other option than having the webserver supply the correct content type.

But the web server doesn't know the correct content type. The file was uploaded by the user as an attachment to a post, and the only information provided by the user was the file name and extension. When you view the post, you get back the information originally provided; no more, no less.

The only way the server could indicate that the attachment is a PDF file is to look inside the file and interpret the contents, or to look at the extension and associate .pdf with a PDF file. Both of which the browser can do just as well.

In this case the server has no business deducing or guessing, it should just hand back the data as it received it with the same file name. So I think the server is behaving as it should.

The makers of Firefox (not exactly a niche browser) seem to have a different opinion so don't shoot the messenger. Life sucks and sometimes you have to fix things which are not really your problem to start with.

If you really want this fixed, contact the SMF developers, this is not a bug with our forum or the servers.

[Cerebus]

I think someone's missed the point. The writers of SMF obviously took the decision that, when an end-user uploads content, they would not make any assumptions about what the MIME type of that content was. To take an uploaded file and assume the MIME type could completely misrepresent the content type. Relying on the fact that someone puts 'pdf' or 'jpg' on the end of a file could allow all sorts of malfeasance - see below (a benign example):

[nctnico]

IMHO the application receiving the file should do the check AFTER it has been scanned automatically by the virus scanner. There really isn't any need to be more secure than necessary because that just causes extra nuisance with zero added security.

[xrunner]

I have to say that the forum is really responding faster now. Really good work! 

[ez24]

I will be moving the forums and website over to the new cluster at 2018-04-21 00:00:00 GMT.
Unfortunately due to the huge jump software versions this can not be done without causing some downtime.

Thank you for your hard work helping us 

[aqarwaen]

can some say me why i get database error,if try acces from wifi?mobile data works fine without.i get error on my tablet,smarttv,phone and pc also

[gnif]

can some say me why i get database error,if try acces from wifi?mobile data works fine without.i get error on my tablet,smarttv,phone and pc also

Likely an overlooked setting to be updated, I will try to reproduce and correct it. Thanks for reporting it.

Edit: I can not reproduce it, it sounds like you have it cached somewhere, perhaps your ISP has cached the error from during the update.

[Cerebus]

Is there an issue with the 'ignore topic' feature? I haven't changed my forum settings but the ignore topic button seems to be gone from my updated topics page.

[tautech]

Is there an issue with the 'ignore topic' feature? I haven't changed my forum settings but the ignore topic button seems to be gone from my updated topics page.

Interesting, mine's unchanged too like Wilfred's.

I retain mine after the upgrade. But I also never got the ability to move topics that was introduced before the move. So my experience may not be the most reliable guide.

There are a couple of ways to have Move Topics visible and everyone has it by default at the bottom left in the first page of a topic they have started. In 'normal' forum view it's just above 'Quick Reply'.

[BU508A]

can some say me why i get database error,if try acces from wifi?mobile data works fine without.i get error on my tablet,smarttv,phone and pc also

Likely an overlooked setting to be updated, I will try to reproduce and correct it. Thanks for reporting it.

Edit: I can not reproduce it, it sounds like you have it cached somewhere, perhaps your ISP has cached the error from during the update.

No, it is not a cache issue imho. I have the same behaviour here: Linux/Windows + Firefox works perfectly well but with my iPad 4 and Safari I get this "Database error". It needs reloadings from 1 up to 20 or 30 attempts until I get what I'm looking for. It seems also, that it is some kind of load dependend. I thought first, it could be a cache thing (DNS, browser etc.), therefore I was waiting for the TTL to become obsolete. But it seems, it is still coming up with this database error.

[hwj-d]

can some say me why i get database error,if try acces from wifi?mobile data works fine without.i get error on my tablet,smarttv,phone and pc also

Likely an overlooked setting to be updated, I will try to reproduce and correct it. Thanks for reporting it.

Edit: I can not reproduce it, it sounds like you have it cached somewhere, perhaps your ISP has cached the error from during the update.

No, it is not a cache issue imho. I have the same behaviour here: Linux/Windows + Firefox works perfectly well but with my iPad 4 and Safari I get this "Database error". It needs reloadings from 1 up to 20 or 30 attempts until I get what I'm looking for. It seems also, that it is some kind of load dependend. I thought first, it could be a cache thing (DNS, browser etc.), therefore I was waiting for the TTL to become obsolete. But it seems, it is still coming up with this database error.

Me too!! Meanwhile it is online possible to login from my S7! IPad, Linux, Win10, different browsers have all passed one after another with this database error!
And I think, this is the last time, i'm able to login now....
€: Cache, cookies cleaned already

[hwj-d]

Ok, i'm in with my desktop again. But it tooks more than ten attempts in a row.
Maybe a server overload, storage misconfiguration?

[gnif]

Ok, I will have another dig though, it does seem very odd that it intermittent as everything is in sync.

Certainly not overloaded, perhaps there is a plugin still trying to use the old database configuration.

[Cerebus]

I saw the database error a few times shortly after the server move, but, unlike others, I haven't seen it for a few days,

On the subject of 'ignore topics': I turned it off, and turned it on again in my profile and the option reappeared. So if anybody has the same problem "turn it off and on again".

[Monkeh]

gnif, no DNS records for web1. and web2.eevblog.com - makes my mail server a tad unhappy.

[gnif]

gnif, no DNS records for web1. and web2.eevblog.com - makes my mail server a tad unhappy.

Your mail server should not be seeing web1.eevblog.com & web2.eevblog.com, they are relaying through cpanel1.eevblog.com which is what you should be seeing. I will double check the logs to confirm however.

[gnif]

gnif, no DNS records for web1. and web2.eevblog.com - makes my mail server a tad unhappy.

Your mail server should not be seeing web1.eevblog.com & web2.eevblog.com, they are relaying through cpanel1.eevblog.com which is what you should be seeing. I will double check the logs to confirm however.

Checked, I see, you are rejecting based on existence of the sending domain. Rather then add records for these hosts (i'd ranter limit their IP exposure) I will adjust the mail server to use plain 'eevblog.com' as the sending domain.

[Monkeh]

gnif, no DNS records for web1. and web2.eevblog.com - makes my mail server a tad unhappy.

Your mail server should not be seeing web1.eevblog.com & web2.eevblog.com, they are relaying through cpanel1.eevblog.com which is what you should be seeing. I will double check the logs to confirm however.

Checked, I see, you are rejecting based on existence of the sending domain. Rather then add records for these hosts (i'd ranter limit their IP exposure) I will adjust the mail server to use plain 'eevblog.com' as the sending domain.

Correct. Every little helps. RDNS also appears to need setting up, having looked at full logs.

[gnif]

gnif, no DNS records for web1. and web2.eevblog.com - makes my mail server a tad unhappy.

Your mail server should not be seeing web1.eevblog.com & web2.eevblog.com, they are relaying through cpanel1.eevblog.com which is what you should be seeing. I will double check the logs to confirm however.

Checked, I see, you are rejecting based on existence of the sending domain. Rather then add records for these hosts (i'd ranter limit their IP exposure) I will adjust the mail server to use plain 'eevblog.com' as the sending domain.

Correct. Every little helps. RDNS also appears to need setting up, having looked at full logs.

This has been requested already, I need to chase the DC to find out why this has not happened yet.

[gnif]

rDNS records are now in place, please allow up to 24 hours for caches to clear

[Cerebus]

You might get problems as the forward and reverse DNS don't agree for your named MX host:


nuit$ dig +short eevblog.com mx
0 mail.eevblog.com.
nuit$ dig +short mail.eevblog.com
192.200.109.226
nuit$ dig +short -x 192.200.109.226
cpanel1.eevblog.com.
nuit$


Some people will reject mail on that basis, some won't.

[gnif]

You might get problems as the forward and reverse DNS don't agree for your named MX host:


nuit$ dig +short eevblog.com mx
0 mail.eevblog.com.
nuit$ dig +short mail.eevblog.com
192.200.109.226
nuit$ dig +short -x 192.200.109.226
cpanel1.eevblog.com.
nuit$


Some people will reject mail on that basis, some won't.

That's not how rDNS filtering works, it looks for the forward and reverse DNS to match, it doesn't care about MX records, otherwise services like gmail and office365 would be plagued with the same problem.

Code: [Select]

# host 192.200.109.226
226.109.200.192.in-addr.arpa domain name pointer cpanel1.eevblog.com.
# host cpanel1.eevblog.com.
cpanel1.eevblog.com has address 192.200.109.226

Here is gmail.

Code: [Select]

# nslookup
> set type=mx
> gmail.com
Server: redacted
Address: redacted#53

Non-authoritative answer:
gmail.com mail exchanger = 10 alt1.gmail-smtp-in.l.google.com.
gmail.com mail exchanger = 30 alt3.gmail-smtp-in.l.google.com.
gmail.com mail exchanger = 40 alt4.gmail-smtp-in.l.google.com.
gmail.com mail exchanger = 5 gmail-smtp-in.l.google.com.
gmail.com mail exchanger = 20 alt2.gmail-smtp-in.l.google.com.


Code: [Select]

> set type=a
> alt1.gmail-smtp-in.l.google.com
Server: redacted
Address: redacted#53

Non-authoritative answer:
Name: alt1.gmail-smtp-in.l.google.com
Address: 64.233.179.27


Code: [Select]

# host 64.233.179.27
27.179.233.64.in-addr.arpa domain name pointer om-in-f27.1e100.net.
# host om-in-f27.1e100.net.
om-in-f27.1e100.net has address 64.233.179.27
om-in-f27.1e100.net has address 66.102.12.27
om-in-f27.1e100.net has address 216.239.32.27

All that matters is the SMTP server has the rDNS resolve to the forward DNS.

[geekGee]

It could impact an SPF record check but you've already mitigated that.

eevblog.com.    299     IN      TXT     "v=spf1 +a +mx ~all"

[gnif]

It could impact an SPF record check but you've already mitigated that.

eevblog.com.    299     IN      TXT     "v=spf1 +a +mx ~all"

That doesn't apply here either, the web servers relay via the mx server. Technically "a" should not be in the SPF record since the website is proxied via CloudFlare, and the "a" is giving CloudFlare permission to send email from the domain.

[geekGee]

It could impact an SPF record check but you've already mitigated that.

eevblog.com.    299     IN      TXT     "v=spf1 +a +mx ~all"

That doesn't apply here either, the web servers relay via the mx server. Technically "a" should not be in the SPF record since the website is proxied via CloudFlare, and the "a" is giving CloudFlare permission to send email from the domain.

Ah... now I see.  Entries cpanel1 and mail resolve to the same IP address.

[gnif]

Outage just now was caused by SMF attempting to "Optimize" the tables, I will need to adjust SMF to prevent this behavior.

Edit: SMF patched, this should not reoccur.

[EEVblog]

Outage just now was caused by SMF attempting to "Optimize" the tables, I will need to adjust SMF to prevent this behavior.
Edit: SMF patched, this should not reoccur.

Thanks.
I occasionally "optimise" the tables manually in the admin section option just to keep things tidy.
Can/should I still do this?

[gnif]

Outage just now was caused by SMF attempting to "Optimize" the tables, I will need to adjust SMF to prevent this behavior.
Edit: SMF patched, this should not reoccur.

Thanks.
I occasionally "optimise" the tables manually in the admin section option just to keep things tidy.
Can/should I still do this?

Previously this was fine but part of the move meant changing to a different storage engine and data format type, the optimize query literally rewrites each table in the entire database. The new format and highly optimized cluster configuration, as well as having enough ram to keep the entire data set in ram makes this an unnecessary step.

[Rerouter]

As server juggling is going on, felt I should point out there have been a few times tonight where i have had the eevblog server fail to return a page after posting a reply, Refreshing fixes it,

Edit: Exact response is "Server gave an empty response" and happened twice while i was trying to post this message,

[gnif]

Update: The Wiki is back

[BU508A]

Ok, I will have another dig though, it does seem very odd that it intermittent as everything is in sync.

Certainly not overloaded, perhaps there is a plugin still trying to use the old database configuration.

gnif, whatever you did, it seems that since yesterday the database error did not show up again on my iPad.
Thank you very much for resolving this.   

Andreas

[hwj-d]

Even with me this annoying database error is gone now.
Thanks too. 

But, what was it? I would be interested... 

[gnif]

But, what was it? I would be interested...

It was extremely simple, CloudFlare were caching the error pages from during the server migration and would not flush them. After discussion with Dave CF has been disabled and will only be re-enabled if we need to use it to help mitigate against an attack.

[gnif]

But, what was it? I would be interested...

It was extremely simple, CloudFlare were caching the error pages from during the server migration and would not flush them. After discussion with Dave CF has been disabled and will only be re-enabled if we need to use it to help mitigate against an attack.

When you say would not flush them do you mean they refused a request or the command you can issue for your site didn't work? What was the reason CF was enabled in the first place? Does the reason still exist with the new server setup?

CloudFlare would flush their cache (via the portal) but not globally, some of their nodes still (even today) cached the database error pages that occurred during the upgrade. CF was enabled to try to reduce load on the single server that Dave had early on.

I just posted on Patreon (no need to be a patron to read my posts) a write up on this entire move, the server configuration basics, etc. if anyone is interested.
https://www.patreon.com/posts/18456501

[frozenfrogz]

Thanks for the write up!
I do not understand half of the technical intricacies regarding web servers and network management, but it was a nice read none the less.

[hwj-d]

I just posted on Patreon (no need to be a patron to read my posts) a write up on this entire move, the server configuration basics, etc. if anyone is interested.
https://www.patreon.com/posts/18456501

Wow, what a story. Thanks for writing and sharing it all.   
And now, i think, i want to learn what puppet is and makes ...

Thanks again.

[jc101]

Since the update when I go to look in...

https://www.eevblog.com/forum/dodgy-technology/

I just get a blank page.  However if from the forum I click the icon next to the forum, ( https://www.eevblog.com/forum/dodgy-technology/?action=unread;children ) to get just the new posts, I do get to see the list.

I get the same behaviour on Safari, Chrome, and Firefox. Using http or https.

Is this a hangover from the server change?