Other SOTA sites: SOTAwatch | SOTA Home | Database | Video | Photos | Shop | Mapping | FAQs | Facebook | Contact SOTA

Database Log Entries Lost


#1

Once the database became accessable today, I started entering log data for 27 Jan 2018. It appears that all the entries I made from 22 Jan thru 26 Jan, which were successfully entered previously, have now disappeared based on the my total chaser point and unique summit totals which reverted back to 21 Jan status.

Has anyone else encountered a similar issue?

Rich N4EX


#2

Read Andy’s thread at the top of the Reflector Rich. That should explain it all

73, Gerald G4OIG


#3

I’d expect anything entered after 0600z - Jan 24th onwards and before 0812Z Jan 28th to be missing. I don’t know what stuff I have in backups I have here that can be extracted yet. I’ve take the outage as a chance to update/reinstall/reconfigure loads of things.

What does perplex me Rich is that you have missing data from a day or two before the problems. I have good, hard, kosher backups of everything for each day in January taken between 400Z & 420Z every morning. I still have a few more things to do but if you PM or email me in a day or so I can see what extra I may have to recover.


#4

FYI the database website is down again HTTP Error 404 site not found.

73 Ed.


#5

Same thing here Rich. Yesterday it was fine, showing 49,920 chaser points. Today I lost the January 24,25,26, and 27th. Lost 153 points. Should I try putting them back in or wait for some correction? de Scotty KG3W


#6

Did you run a " Down For Just Me " type checker? If not you are reporting a private issue not a public issue as it’s working fine for me right now.


#7

Hmm, very strange - I tried a cache refresh Ctrl+F5 and shift+reload and no page arrived.

If you are seeing it, it could be a DNS issue I guess, but as you know, I could see the page on the new server earlier today!

73 Ed.

Very Odd - probably my ISP - I can Ping the URL fine:
C:\Windows\system32>ping sotadata.org.uk

Pinging sotadata.org.uk [185.43.79.38] with 32 bytes of data:
Reply from 185.43.79.38: bytes=32 time=48ms TTL=118
Reply from 185.43.79.38: bytes=32 time=49ms TTL=118
Reply from 185.43.79.38: bytes=32 time=48ms TTL=118
Reply from 185.43.79.38: bytes=32 time=50ms TTL=118

Ping statistics for 185.43.79.38:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 48ms, Maximum = 50ms, Average = 48ms

C:\Windows\system32>

Just not get access to the webpage through my browser:

image

even using the IP address no go:
image

OK, presume it’s a Deutsche Telekom DNS issue for now… In any case I wont be entering any log entries until you give the go ahead.

73 Ed.


#8

What do you expect if you ignored the fine advice not to use the DB until you were told it was open again?


#9

You are seeing the old DNS values Ed. 87.117.226.153 is a good IP address.


#10

It’s currently giving a 404 error for me too - though it worked earlier.

“Is it just me” is telling me that it is just me, but my connection is OK, as I am posting this.

OK, I just tried Ed’s ping test and got the same result.

Then I changed my DNS setting to use nice Mr Google on 8.8.8.8, and that resolves the correct address.

Has been working with my ISP DHCP settings, so perhaps there is some DNS strangeness working through…


#11

You’re correct Andy. I didn’t read the top post. My bad. I will wait for a fix and WILL NOT PUT ANY INFO INTO THE DATABASE. THANKS!


#12

The DB that is running is good and running on new hardware, new DB engine a new OS. Once the dust has settled, I can mount a local copy of the DB and see what logs exist in it after the troubles started and extract them. But it’s only been up for 14hrs and there’s still a few niggles to resolve. Mail or PM in a day or so when I’ve had a chance to look.


#13

Thanks for the hard work Andy - migrating data isn’t usually straightforward, glad it isn’t on my list of weekend jobs! 73 Paul


#14

If you: ping www.sotadata.org.uk
And it goes to IP address: 185.43.79.38, this is the old INOP server. Expect: HTTP Error 404 if you try to connect.

87.117.226.153 is the new operational server. Connections return the usual SOTA DB login screen, etc.

Logs submitted by me on/before late on the 23rd UTC are all OK.

My recent logs which I Imported after about 1430z today using the new server are also all Ok.

I keep daily SOTA log files on my PC, and on a thumb drive. Importing a few days of logs takes a couple of minutes.

GL es 72,
Bruce W2SE


#15

Same thing here: Error 404
But i did read Andy’s advice and all my Sota qso’s including all the details are logged in my general log so it’s a good thing to have a personal backup. They will be transfered to Sotadata when the word is given out that everything is OK.


#16

I can access the net through several providers. Here’s how long it took for the DNS update to propagate

US access in LA, 1hr30
ISP in Scotland, 4hr30
UK Mobile ISP, 5hr
VPN provider in Austria 15hrs.

It’s possible that the update has yet to arrive at your ISP.

On top of this, some browsers and Windows, tend to have very sticky caches. I have a Linux PC and Win7 PC here on the desk. I could see the DNS change via my Linux PC, but despite telling my Win7 machine to flush and get new data, it knew better. I can’t remember how many times I had to issue the command before it did something. Then it took several attempts to make Firefox use the new data. I’d like to think I know how to do these things and it was painful for me. I sympathise if you just use a PC as a tool and don’t ever delve into the guts.


#17

My computer finally sees it. Is it ok to enter data for latest activations??

Malen
VE6VID


#18

Restarting my DSL Router helped to aquired the DNS update.
Thanks for the repair and system improvements done to the db server.

@MM0FMF: http://www.sota.org.uk/Associations gives an error. Looks like the db connections needs to be reconfigured? Or the webserver for this domain has also DNS update problems?

73 Joe


#19

I thought that might be the case, looks like something odd happened as the DNS values at Deutsche Telekom were being updated then.

It’s now visible again here. Thanks.


#20

The network troubleshooting haiku springs to mind